Does my design document need to contain all the technical info on how the code should look? I'm not a good programmer myself, but I would like to know if it is neccessary or not. Is there anything else I should be including that is often looked over? Also, is it easy to make DS games? Just wondering.

Well, typically there's the Game Design Document (GDD) and the Technical Design Document (TDD). Basically, the GDD formalizes the ideas that have been floating around in the designer's head. The TDD then attempts to digest the GDD into a set of technical requirements and then layout the responsiblities and relationships on the code level.


GDDs shouldn't even mention code or other such technical matters, keeping itself to higher-level discussion of gameplay mechanics, level design, art & music requirements/descriptions. Basically, this is the document which describes the gameplay and artistic aspects of the game. Often times, the more monotonous details (exhaustive dialog, statistics tables) will be broken out into appendices or another document entirely to allow the GDD be less encumbered by details.

TDDs identify code required to impliment the gameplay as described by the TDD and also should strive to stay at a fairly high-level. The purpose of the TDD is to describe the necessary components to a competant programmer who then impliments it, for the most part, as he or she sees fit. TDDs tend to stay at a level of describing the interfaces and relationships of objects and might also include high-level suggestions for implimentation. For example, the path-finding function of an entity might say something like "impliments path-finding using the A* algorithm" rather than trying to specify the exact implimentation details. Sometimes very important structures or algorithms are laid out in more detail. In addition, this document also lays out file formats and documents target platform requirements (OS, Memory, video card requirements) - though the requirements will likely be a best-guess early on and revised as needed.


There's certainly a lot more that can go into either document, and there's probably some topics that I should have mentioned but missed, but I think I've written a decent over-view to get you started.

It's not necessary to know any programming languages to create a design document, but you should be able to accurately articulate your concepts with basic logic diagrams and flowcharts when needed. If you are dealing with relationships between several variables you should be able to mathematically express these relationships so that the programmers don't have to do their own research or infer what you are trying to accomplish.

Design documents are also rarely set and stone and evolve throughout the development of the game. So meticulously presenting every aspect of code in detail is usually not worth it unless it is describing an integral and impervious feature of the game that will not change with 100% certainty.

For small games that you're doing all by yourself, some notes scribbled on a few slices of paper may well be sufficient. For larger games that you'll be doing with multiple people, a design doc becomes usefull: it's how you tell them what game they'll be creating. In other words, a design doc should describe the game itself. Controls, levels, style, theme, goals, the idea's behind it, the why and how, and so on. Just to get the idea across, to get the team on one line. I believe this depends on the team somewhat: some people will grasp the idea much easier than others.
Oh, it may be usefull to document why you chose this and rejected that. It's easy to forget why you made certain decisions when time goes by.

Of course, you're not going to tell your programmer how he should do his job, because he's better in it than you are. Instead, ask him if he thinks your idea's are feasible and how much time and effort it would cost him to implement them. If you're working with multiple programmers, then a techical doc will become usefull, but I'd leave that up to the lead programmer.

As for DS games, mwa. Compared to similar PC games, it isn't really easier. Unless you've got a good background in C programming and embedded systems it will take some time to get familiar with the system. At least that's my experience so far, being a C++ programmer. ;)