Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Today, 06:14 PM

#5176523 Spritesheet or single-sprite files?

Posted by Ravyne on 27 August 2014 - 04:12 PM

On thing here is that you're conflating content creation workflow issues and runtime issues.


For runtime performance, you want to minimize the number of draw-calls you have to issue, and a good way to do that is to collect together a bunch of small sprites that have the same or similar properties into a single, large texture -- then, you can feed a list of triangles with different texture coordinates to draw various sprites from it. Same idea with array textures, it just depends on what your hardware supports -- Sometimes you might know at build time what's best for a platform (say, on a console or other fixed platform), sometimes you might know at deploy time (say, from the AppStore where you know (IIRC) what device the package is being deployed to), and sometimes you might not know until runtime (say, on a PC). For best performance, you want to defer the decision of runtime formats until you know what your hardware supports, but you might just pick a good middle-ground like texture atlases, sacrificing some performance to regain some simplicity.


For your content creation workflow, you want to focus on what's the most efficient way for you to work with the art assets, and to get them into your work-in-progress builds. You might prefer to work with individual image files, or there might be technical reasons for doing so -- like image characteristics or version control. Sometimes you might prefer to work with sprite sheets containing tightly-related images -- like a single character, or even a single animation of a single character. How you or your artists work on your game's assets is about 75% preference, tempered with 25% technical considerations.


But the important take away is that these things don't have to be (and probably shouldn't be) the same. That is, just because your game might run best with a texture atlas doesn't mean you have to create your art assets in a texture atlas -- all you need is a little command-line tool to assemble the texture atlas (or, your game could do it on the fly, if you're willing to give up some load time) from smaller files containing fewer images, maybe just one. You can make this a part of your build system, so that the assets are assembled together when you build your game.


I like to think of code, assets, developers and artists as being "on the near side" of the build system, and software builds, "run-time", and end-users as being "on the far side" -- Often what's best for the near side is different from what's best for the far side. The build system is everything that automates the process of going from the near side to the far side.

#5175590 How are retro-style games like Papers Please and The Escapists made?

Posted by Ravyne on 22 August 2014 - 10:07 PM

You can do a relatively retro-looking game just by using low-res art assets, limiting your total on-screen and per-sprite colors, and by choosing an appropriate (smallish) color palette. For example, if you want a game to look distinctly like an NES title, the single biggest thing is using just the ~56 colors that the NES could display -- the NES palette is particularly distinctive because its not an RGB palette, and hence its a little odd (e.g. there's no really good 'orange'). That alone evokes the feeling of an NES game, but to really drive it home you would want to place further restrictions on yourself, like only using 3 colors + transparency in each tile making up the sprite (8x8 or 8x16 pixels), or in each 16x16 pixel area of the background -- these were hardware limitations of the NES hardware, other hardware had similar restrictions; it wasn't until the Saturn/Playstation era that only memory, not hardware, was the primary limit on 2D graphics.


Aside from that, just avoid doing things that would have been impractical or impossible on the old hardware -- no smooth sprite rotations on an NES, so use the same work-arounds the old games used. No alpha transparency either, again, use the same work-arounds the old games used.


Then, you can go a step further still and use the really neat hardware effects that systems like the NES and SNES could do -- change the color palette entires between frames or scanlines to perform palette animations, gradient effects, or to use more colors than is possible in the naive way; scale and shift the scanlines to create perspective in the same way that old racing games like Pole Position did them.


Basically, you imitate the limitations, quirks, and clever hacks that all the old games had to live with.

#5175159 Own ruleset - how likely do I violate others?

Posted by Ravyne on 20 August 2014 - 09:06 PM

I am not a lawyer, so do not take this as legal advice -- that being said, here's what I think about your question...


You're being paranoid.


Not just about yourself infringing on others, but of "protecting" your own ideas as well. This stems, bluntly, from a complete lack of understanding about what can even be protected and of how valuable or not something is, just because it's 'protected'. The symptoms are evident in the way that you think you're working around D&D rules by using different stat names, etc -- and in your being overly secretive about your own specific rules. If anything at all can be protected, its certainly not the generalities -- its the specifics, in concert. That is to say, using different stat names affords you none of the 'protection' you seem to think it does, and by not revealing your complete ruleset no one here can formulate any idea at all about how vulnerably you might or might not be to litigation. I'm not saying to never think about it -- certainly you can't just clone existing rules outright and get away with it unchallenged -- but protection of creative works doesn't typically afford each element in isolation (e.g. rules, archetypes, themes, a'la carte) protection, it generally protects the sum total of those things, possibly together with *specific* people, places, and things (that is, nouns that begin with capital letters.)


Besides that, you say it took you three years to develop -- so, either in those three years you've done something amazing with and around those rules, creatively, which serves as a moat around your castle (good); or, what you have isn't all that special and neither affords or deserves the protection you think it does (bad). Game mechanics of any kind, as a general rule, are difficult or impossible to justify protecting -- ideas alone are not afforded the benefit of protection out of hand, there are requirements that have to be satisfied first.


And even achieving your own special snowflake of a game, guess what? Anyone can sue you at any time for any perceived toe-stepping at all -- and to the degree that their allegations have any semblance of a reasonable reality at all, their charges will either be thrown out, force you to settle, or drag you through a trial. That's not just a threat, its a legal tactic that IP holders use *all the time* to keep would-be competitors out of their scrapyard -- sometimes the bark is just as effective as the bite.


Despite my hyperbolic tone -- there's no bad news for you here, unless by "not copying D&D" you actually meant "I'm TOTALLY copying D&D!" If you can put your game down in front of any role-playing group worth their salt and they don't immediately shout "Dude! This to totally F*cking D&D!", you're probably about as safe as you can expect to be.

#5175067 So... C++14 is done :O

Posted by Ravyne on 20 August 2014 - 11:38 AM

Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?

Seriously, that's practicality a different language, why keep calling it C++?


Thankfully -- nay, intentionally -- you're not the only one and its honestly the best thing that's happened to C++ since its original standardization (C++98).


Its still C++ -- save for the old meaning of 'auto' and some difficulties with primitive sizes, all your old C++ code should mostly just compile. From that same source code, the object code generated today will be vastly superior to what would have been generated at the time of its writing. But writing non-trivial, well-engineered programs in C++ has always been something of an obtuse exercise -- the mechanics of lambdas, for instance, have always been there (I spent a solid month some years back 'back-porting' code with lambdas to a compiler that didn't yet offer support); building them into the language is so much better. For years, C++ has hobbled along with villainously-clever, mostly-working library implementations of what are language-features in other places (See: Boost). This has had an effect of making 'serious engineering' in C++ mostly a domain reserved for experts. There are several sub-themes to C++11/C++14, but the one unifying theme is making all that expert-level engineering stuff (simplifying call-backs with lambdas, simplifying template code with auto, decltype, variable templates, etc) accessible to the non-expert.


C++11 *is* a different language -- one better than previous incarnations of C++, but one that is (previous exceptions noted) basically a perfect superset of its older self.

#5174803 Weapon statistics visualization

Posted by Ravyne on 19 August 2014 - 12:57 PM

Don't make it an explicit and permanent part of the interface, or at the very least bury it under the pause screen somewhere.


The best possible way is to allow the game to demonstrate it to you -- perhaps because the first time you encounter it is in the hands of a friendly character or foe. Or, maybe you infiltrate a laboratory where the weapon is developed and the results of its tests are visible. It could be part of a cutscene, even. Be creative, and keep in mind you don't have to do it with 'standard-fare' weapons -- the machine gun, "bfg-9000", and shotgun/"spreads" are well-worn tropes.


If you are compelled to have a slick animation in game, have it interrupt gameplay with a modal dialog, but only the first time you pick up that weapon -- furthermore, as best you are able to within the confines of your design, try to ensure that this first time the weapon is picked up happens during a lull in the gameplay as to not break up the immediate flow or intense action.

#5174800 What game companies hire remote programmers?

Posted by Ravyne on 19 August 2014 - 12:49 PM

Remote positions at big studios are almost unheard of -- they will sometimes allow for existing employees to work remotely, but as a new hire this is pretty much limited to those with an especially high level of skill and an established track record. In general, game development at a scale of larger than a dozen or so people is a very collaborative process where daily face-to-face communication is a necessity. Complicating matters further are technological issues, wherein it might be very difficult for a remote worker to have a workable network connection for all the high-bandwidth things he needs to do -- a developer like yourself needs either the bandwidth to download regular, full builds (which could be in the 10s of GBs, daily or more) or needs to maintain a local copy of all in-progress art and code assets, along with a fully replicated build system. Even further complications arise if you do console development or must work under NDAs that prohibit documentation and/or physical dev-kits from being stored at non-commercial work-sites -- I'm not sure if its that way with the just-launched generation of consoles, many of the companies seem more open about it, but at least in past console generations none of the manufacturers allowed you to have a devkit if you worked from a home office.

Certain roles are more amenable to remote work -- Audio in particular, where the workflow permits and where few companies have enough demand to justify a fulltime composer or sound designer (even large ones). Most of that is contract work. I imagine art is the same, to a lesser extent.

Companies that work relatively exclusively on PC titles, or smaller indie studios are typically more amenable to remote situations -- many of the better known indies studios started as -- or still are -- largely remote affairs.


Small contract work is sometimes available, but it takes a lot to build up a reputation and unless you know someone, usually requires working your way up from the bottom. One of the best ways to fast-track your reputation is take on an open-source project to work on -- remember that any code you write under contract isn't something that you can just slap into your portfolio.

#5174793 So... C++14 is done :O

Posted by Ravyne on 19 August 2014 - 12:27 PM

My understanding is that range-for isn't strictly syntactic sugar, because iterators can fall down (or at the very least can be unwieldy, possibly requiring otherwise unnecessary specializations) under template code. It might be the case that std::begin / std::end alleviated those problems (IIRC, range for utilizes them), but I also believe it was the case that std::begin / std:: end were proposed after range-for had gained steam -- besides that, I like that range-for specifies intent exactly "visit each item in the container once, from front to back", yes the iterator idiom is common, but if the loop body is more than a few lines long I have to parse it to make sure there's no funny business going on with the iterator.

#5174534 So... C++14 is done :O

Posted by Ravyne on 18 August 2014 - 02:14 PM

You also missed extended constexpr Nevermind, no you didn't, but regardless -- for a complete rundown, see https://isocpp.org/wiki/faq/cpp14-language


The new auto return type is more than just extending it to functions, it also has more capability with respect to multiple return statements and recursive calls -- basically, as long as the first return statement's type can be deduced, you can now have subsequent return statements, including recursive calls, as long as they all agree on the type.


decltype(auto) is a new refinement of type deduction that is mostly useful to preserve the reference-ness where simple auto wouldn't -- My understanding is that it performs the same function as auto-with-trailing-return-type-of-decltype, but without the trailing part. It can be used anywhere a declaration can be used, which might be useful but early guidance is that this would be an anti-pattern. This is super important, but mostly for library-implementors.


There's also a new standard [[deprecated]] attribute to mark deprecated APIs, and you can now use the single quote (') character anywhere in numeric literals to separate digits to make them more readable, in any of the literal formats -- e.g. 0b0110'0011 to separate out the nybles in a byte.

#5174331 How to build a virtual machine

Posted by Ravyne on 17 August 2014 - 03:44 PM

Depends entirely how you define 'VM' -- I assume what you're talking about is "something like the Java Virtual Machine" -- and even within the context of something like the JVM, there are several distinct approaches. The easiest approach would be some kind of high-level language or byte-code interpretter -- In that approach, the JVM is not unlike the BASIC programming languages of yore, or many of the scripting languages popular today. Byte-code interpreters are basically the same function, but are attractive because of increased performance of applications running on the VM, and code-density/code-hiding -- but now you also need to write some kind of compiler, in addition to your VM, both of which are big tasks.

A state-of-the-art VM today uses just-in-time (or JIT) compilation to get best performance. In this setup, there's typically a compiler that takes a high-level language and translates it into Intermediate Language (or IL), a lower-level representation (which often, but not always, looks similar to assembly language of popular CPUs); this compiler only concerns itself with high-level, algorithmic optimizations. Then, the JIT-employing VM performs a final phase of compilation in which the VM IL is compiled down to actual machine code that can be run on the host processor directly, but still within the sandbox defined by the VM platform.


Much of the job of writing a usable (professional) VM today is about security of the sandbox environment, things that enhance programmer productivity -- like garbage collection, and JIT performance. Within that sphere of influence, the part you probably think about as "the VM" is mostly about defining what the virtual hardware platform and IL look like -- things like whether the machine architecture is register-based/stack-based/direct-memory/something-else, to tedious and not-immediately-obvious concerns like what the threading model/shared-memory/message-passing/memory-coherence models are. That's for a 'production quality' kind of VM -- odds are, if you want to keep it simple, your VM will look more like a scripting language.

#5173669 Advise on Class structure

Posted by Ravyne on 14 August 2014 - 01:04 PM

Some criticisms:

  • Why is everything public?
  • Getters and Setters are often a code-smell or unnecessary java-ism.
  • Why is everything public and you also have many getters and setters?
  • Your naming conventions are all over the place, I see lowercase-underscore, PascalCase, and camelCase all mixed together.
  • Your naming choices for member functions and member variables are unintuitive and unclear.
  • I don't see 'const' used anywhere -- const-correctness is an integral part of maintaining the invariant state a class is supposed to maintain.
  • I don't see you passing parameters by reference anywhere except where it would be dictated by D3D convention -- I could be wrong about this, as I'm not familiar with all of these data structures you refer to, but my experience says that passing by const reference is usually more prevalent than what I can see here.
  • You have several cases of 'foo1(...)' and 'foo2(...)' that have the same parameter and return types. 1 and 2 doesn't tell me anything -- the function name should tell me what's different about them.
  • You mostly don't name your parameters -- while this is allowed and even sometimes useful, its more-often bad form for a public interface to not describe what its parameters are. When the class members are implemented in a non-header file, clients won't see the names you give them there.
  • It looks like some of your member functions shouldn't be members -- these should probably be non-member-non-friend functions. If they're part of the same logical interface, keep them in the same namespace, otherwise put them in another namespace. For example, 'void createSphere(  LPDIRECT3DDEVICE9&)'

#5172084 Does the interface of every graphic adventure game suck?

Posted by Ravyne on 07 August 2014 - 12:01 PM

I think part of the problem, as they say, is that a picture is worth a thousand words. In the old text-only adventure games the descriptions could be very rich but it was also very clear what the nouns were. In an image-based adventure game, literally every distinct thing on the screen is a potential noun, and that obscures which nouns are actually viable or interesting, which kind of gave rise to the sweep technique where you revert to sweeping the entire screen with the cursor when you're stuck on a puzzle. I don't know if its reasonable to implement a natural-language-like interface in an image-based adventure game, but there's certainly room for innovation.


If you want an example games with somewhat different takes on the genre interface, check out the more recent installations of Broken Sword from The Adventure Company, or Shadowgate 64 for a (admittedly, probably poor) example of a fully-3D, first-person adventure game.

#5168475 How to invent names (theory)?

Posted by Ravyne on 22 July 2014 - 03:58 PM

Also, keep in mind that with things like names of people or places, you're thinking in terms of lineange and legacy, not today. It seems obvious, I suppose, but at least in modern times, the actual people in question are removed from where their name might have come from -- A character might be Sam Baker because his great-great grandfather was a baker, not because he is. If everyone in your world carried the name of their profession that's going to start seeming lame very quickly.


Lots of places are named after important people or religious figures -- for example, Columbus Ohio, or San Francisco. Places are also sometimes given names to make their importance clear -- King's Landing in a Song of Ice and Fire, or historically to confuse in some cases -- Greenland is icy and inhospitable, Iceland is nicer, because the Vikings were trying to trick their enemies.


Most important though, is being consistent. In A Song of Ice and Fire, Bravos has a sort of Spanish flair, The Dolthraki (Spelling) are sort of Mongols.

#5167986 Linux development workflows?

Posted by Ravyne on 20 July 2014 - 01:25 PM

Honestly, my development experience on Linux is mostly as a kind of playground. That is, the kind of coding I do there is mostly recreational -- messing around with Arduinos or other embedded stuff who's tool chain runs best on *nix, exercising my more 'academic' language pursuits like Haskell, or playing with neat linux stuff like Docker. Because I'm not so concerned with efficiency then, that informs some of my other choices. I use Vim not because I find it to be instantly productive, but because leaning Vim is a goal in itself -- its simply useful to know at least one lightweight text editor that you can use even from a remote text console -- and because the long walk leads to becoming possibly more efficient than WYSIWYG editors and fancy IDEs.


In general I like Linux because its a more 'orthogonal' environment in some sense of the word. The trend on Windows (and old-world Macs, the trend has reversed since OS X) has been towards more monolithic, swiss-army-knife applications, or to largely independent 'kingdoms' of apps that inter-operate nicely. The trend on *nix has always been towards a more inter-operable ecosystem of smaller and more focused tools that do one thing very well. It goes beyond the apps themselves though -- even where windows has functional equivalents (say grep vs. findstr) the command-line apps on Windows all use wildly-different argument formats, and not every app necessarily supports piping in ways it ought to. The *nix world largely has that problem sorted.

#5167708 Classes and OOP

Posted by Ravyne on 18 July 2014 - 06:58 PM

Single-Responsibility Principle.


Stated another way, functions, classes and modules should strive to this mantra: "Do very little, very well."


You get into a very philosophical question of "What is a single responsibility?" pretty quickly, and it depends on the level on which that element operates. For two numbers, adding and subtracting are each single responsibilities. For a string, a single responsibility might be concatenating two strings together, or finding the first occurrence of a character. For a database, a single responsibility might be inserting a row of data atomically.


A simple rule of thumb is this -- describe in some detail the essence of what the function, class, or module does in just one sentence. If you can do it without using a conjunction -- usually "and", but sometimes "or" -- you're probably golden. If you struggle to fit it into a sentence or can't do so without reaching for a conjunction, then it's a sign that it might do too much -- that it might have more than one responsibility. It doesn't *always* mean that, strictly speaking, and sometimes you just have to accept it for practical reasons (preferably late in the game, you should be less willing to compromise early on), but it should always make you cast a suspicious eye towards it.

#5167707 why c++ is the most widely used language for professional game development?

Posted by Ravyne on 18 July 2014 - 06:44 PM

Inertia plays a big part, but the other reason is simply that C++ is currently the best, most-widely-available language we have at our disposal when you need to touch the hardware. At the lowest levels, doing the kinds of things that runtimes, drivers, and operating systems do, basically everyone speaks C or C++ -- there are other systems-languages with pockets of support, but in consumer software and consumer electronics, C and C++ are it. Then, it stands to reason that if you're writing any kind of high-performance app that needs to get the most of of those runtimes, drivers, and operating systems, using the same language will give you fastest and most authentic, transparent path. Stepping back one space, to achieve high-performance in code that isn't so much touching those underlying elements, you still need to employ the same kinds of low-level techniques that those elements use themselves -- for example, you might write a memory manager, or you might implement certain parts of the code using intrinsic or inline assembly, perhaps making use of instructions like SSE or AVX that aren't available to the VM models of languages like Java or C# -- and again C and C++ are the natural choice.


I think ultimately, it comes down to the fact that C and C++ are one of very few languages, and by far the most popular, that give full trust and confidence to the programmer that they are doing precisely what you want. C and C++ will let you shoot yourself in the foot, sure, but when you pull a gun, point to the ground and shout "Watch this!" C and C++ will almost never second guess that you know what you're doing unless you ask it to -- and even when it thinks better of it and objects, its not hard to convince it that you do, in fact, know what you're doing. This is a perilous but powerful relationship to have with a compiler, other languages are such hypochondriacs that not only will they prevent you from shooting yourself in the foot, they will also stand in your way when you want to undertake all kinds of unorthodox but supremely mundane activities, regardless of how well thought out of a plan you want to try to convince it you have.


That said, those other do-gooder languages are often enough fast enough and flexible enough for a great many things -- used well, and combined with a little arcane knowledge of their supporting run-times, they're even suitable for games. At some level underneath, there's a hidden sea of C and C++ doing all the things that C and C++ do to make stuff go fast, but those other languages are suited well enough for directing its current.


C++ is popular in games because it started doing a job that needed to be done before anyone else was ready to do it, and because no one since can do, or do such a better job at to make the switch worthwhile. There are other interesting systems languages available that are aimed at the consumer software space, D and Rust come to mind, but they don't now are aren't likely to have the necessary industrial support to turn the tide any time soon.