More on making games cheaply

I only offered 6 points, but 3 of them are ones that people are wanting to argue about! 🙂 I suppose that is a pretty good hit rate…

A few folks took exception to my comment that “code doesn’t rot, our ability to read it does.”

The first objection is that most code is born rotten, that it is rare to find code written to the standards that allow it to be easily maintained. I can’t really argue with that, though of course there are plenty of practices that ameliorate this: code reviews, code standards, etc. I’d answer with “that’s just code where our ability to read it perished as it was being typed.”

The second objection is basically that platforms shift out from under code. This is absolutely true — but is also a sign that you’re not actively maintaining your codebase. Times of truly catastrophic platform shifts where everything you did is invalidated should be relatively rare these days, honestly.

That said, if the platform really does shift out from under you, I think it’s a great opportunity to ask yourself whether it’s time to port or rewrite. If the new platform offers new capabilities, then you should seriously consider rewriting and refactoring your architecture as you go.

My intent here was not to argue “never write new code” nor “never rewrite code.” For example, stringing together libraries is usually a bad idea. Then again, it sure does seem like most libraries turn into sander/screwdrivers over time! 🙂

Really, this was about fighting back the NIH syndrome, and the impulse to rewrite everything all the time. Heck — I myself actually prefer to have control over the tech base and the game design, because to me they are so intertwined… and virtually no engines do the specific things that I am asking for (say, procedural planet generation, for example). But then, I still look for a renderer that works “out of the box.” Keep the risks to the new stuff without which the product cannot exist, basically.

Ted Brown left a comment over on the BoingBoing article about the blog post, taking issue with two points I made:

…big design docs do have a time and place.  At the beginning of a project, it forces the team to eliminate as many assumptions as possible.  And when the team gets large or geographically distributed, concise and updated documentation is critical for production to run smoothly.  Obsolete docs that are not actively pruned are landmines, yes, but it’s a chore, and creative designers hate chores.  So they badmouth it instead of finding a better solution, like making it a job task for someone.

Building a big design doc at the start of the project is the worst time possible, IMHO. Paper docs do not contribute very well to eliminating assumptions — instead, they tend to compound them, because you are layering assumption on assumption. In Ted’s next point (quoted below), he makes the point that you can’t test interactivity, analog elements, and timing with paper prototypes. Well, you can’t test anything with a paper design doc. You can only describe. There’s value in the exhaustive working through of possibilities are careful thinking about contingencies, and it’s a valuable discipline to learn — but the problem with engaging in a long chain of logic on paper is that if any given step is wrong, you invalidate an awful lot of work.

I find it better to test at each assumption, which requires moving to working prototype as fast as possible. Documenting after that is fine with me…! But again, I prefer concise, bullet-pointed docs at that point, not paragraphs. One of my most painful professional memories is the amount of effort we put into making massive design bibles for first Privateer Online (which never saw the light of day) and then Star Wars Galaxies… they were gorgeous documents with piles of detail, and their ultimate relevance to the eventual product was fragmentary at best.

I fully agree that concise design docs are extraordinarily valuable as production proceeds. But they’re better when they document the prototypes, and are more like functional specs for implementation. I am actually all too prone to spend lots of time on documents myself, so I am not one that regards it as a chore. 🙂 Instead, I have to fight this tendency.

I commend to you all this excellent talk on visual design docs by Stone Librande: http://www.stonetronix.com/gdc-2010/OnePageDesigns.ppt . The video is also available on the GDC Vault under GDC 2010 — it’s members-only, though. I personally spend most of my design time these days in doing diagrams, checklists, and storyboards.

Two, binary mapping of game states — which is all you get when using dice and cutouts — is great for RPGs and strategy games, but wholly unsuitable for games involving analog states, such as timing (e.g. fighting games) or physics (e.g. anything with a bouncing object).  If you are making a game that can be completely described with dice and paper, you are not taking full advantage of the interactive medium.  System design is important, but interactivity is what makes a game a video game.

Paper prototype systems all you want.  But use code, animation, and art to prototype anything else.

I wasn’t saying only use paper and dice. I was emphasizing that prototypes can be very cheap. That said, I happen to know that lots of modern FPSes, to take on example, were in fact prototyped on paper — the mechanics being less important these days than the level design, given where FPSes are in their genre lifecycle.

I would argue with the implicit definition of interactivity as implying near-real-time feedback, and that being the defining quality of a video game as opposed to other sorts of games. But that’s a whole other post…