Thus far, this column has been entirely focused on the conceptual side of game design. We’ve answered questions such as how to decide what gets included, and how to lay that information out in an easily readable way.

    Unfortunately, there is far more to creating a computer game than simply coming up with an idea. If that’s all it took, we would be so inundated with computer games, both good and bad, that we wouldn’t know what to do with them. Once the game has been designed, it must be created.

    This is where the coders finally get to shine. Almost anybody can come up with an idea, it’s the so-called “men of action” who make those ideas work. Einstein came up with the idea for the atomic bomb, but it took American scientists to create it. When creating a computer game, the designers are Einstein, and the coders are the scientists.

    If there’s one coding concept I’ve been pushing thus far, it’s that you should never ever start coding before the design document is done. This is the single most overlooked truth in the programming industry, and it’s also the one that gets the most people in trouble. Let’s take a look at how the design process should go, and then how it often works in practice.

    The Ideal Design and Coding Process

    [*]Concept meets for 3-6 months to design the game
    [*]Coding and Concept meet for about a week to figure out what’s possible and what’s not
    [*]Concept spends two weeks revising the design document given their new information
    [*]The design document is handed off to Coding (and the other departments)
    [*]Coding spends 6-12 months creating the code for the game
    [*]6 months of testing
    [*]Product is released, basically bug-free
    Total time: 15-24 months

    This is a very solid timetable. The designers have time to fully flesh out the game world, the coders have plenty of time to create the game from the design they’ve been given, and there’s ample time for testing. Too bad this almost never happens. Here’s what’s more likely to happen when designing a computer game: The Usual Design and Coding Process

    [*]1. Concept meets to start designing a game
    [*]2. Coding starts on the engine before having a single piece of paper from Concept
    [*]3. After a month, Concept has the basic theme of the game done, and is starting to work on the specifics
    [*]4. Management orders what Concept has thus far in to the coders’ hands
    [*]5. Coding works with what they’ve got and designs the skeleton for the game
    [*]6. After another month, Concept has more specific details outlined
    [*]7. Management orders what Concept has thus far in to the coders’ hands
    [*]8. Coding discovers they need to rewrite significant portions of the existing code in order to make what they need to include work
    [*]9. Coding gets way ahead of Concept, forcing Concept to go back and rewrite what they already have
    [*]10. This continues for the 9-12 months of the conceptual design process
    [*]11. Coding and Concept meet for about a week to figure out what’s possible and what’s not. Because code has already been written, the arguments and debates are very, very heated, between Concept’s “vision” and Coding’s work to date
    [*]12. Concept spends a month revising the design document
    [*]13. Coding tries desperately to unwind the spaghetti code they’ve written
    [*]14. The finished Design Document is handed off to Coding
    [*]15. Coding reads the revised document and spends three months trying to write it given the pre-existing code they’ve already written
    [*]16. After 4 months, Coding gives up on their previously written code and starts over again from scratch. Due to low morale, coding takes longer and is more buggy
    [*]17. 24 months in to the design process, the game is half written
    [*]18. Coding realizes they need to change the engine in order to include more of the dictated feature set
    [*]19. 34 months in to the design process, management is tired of waiting and orders the game to be released in 2 months
    [*]20. Coding spends the next two months scrambling to finish the features that are supposed to be included, and fails miserably. Features are cut in order to reach the release date
    [*]21. 12-24 months late and millions of dollars over budget, a buggy, nearly featureless game is shipped. Coders are still working to fix the hundreds of known bugs for the game
    [*]22. The consumer purchases the game and has to download a patch before anything works
    Total time: 36-48 months

    Sounds unreal, right? Unfortunately, it’s more the norm than it is the exception. Management is so eager to get the game finished that they think they can overlap the design and coding sides of the project and save time, when in reality it makes the game come out much later and at a much lower quality. Something just like this happened with a major MMORPG that I can’t name, but you can read about it on pages 81 and 82 of Developing Online Games: An Insider’s Guide, which I recommended in a previous column. The polite term for this turn of events is Premature Coding.

    Premature coding is what happens when management and/or the programmers think they can safely start working on the game before it’s been fully designed. It’s analogous to writing an essay. You can either do your research and then use it as the basis for your paper, or you can write down what you think you already know, then go do research, try to edit in your new information, and realize you need to rewrite the entire paper anyway.

    One way or the other you’re going to do your research before writing the essay, so why not do it right the first time? Similarly, you will be unable to properly program your game until you know what’s supposed to be in it, so you should always wait until that precious design document is finished before starting to code.

    The main cause of premature coding is anxiety, so curbing it is all about confidence in the concept team’s ability to finish when they’re supposed to. Everyone needs to realize that for the game is to ship on time, everyone needs to stick to their schedules.

    Of course, premature coding isn’t the only potential coding problem. Next time, we’ll look at Cool Stuff Syndrome.

    [B]Disclaimer:[/B] Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.


    You may also like