gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Writting a Design spec

#13195 - Omega81 - Sun Dec 07, 2003 11:41 pm

Hello guys/gals

I was wondering if anyone know how you write a design spec. Please no obvious things like doing UML digrams or flowchart diagrams. I am more concerned with the format, I mean do you just put in peudocode and diagrams or is it filled with detailed discription of all modules involved. Please any ideas are welcome.

thanks

Charles
_________________
Keep it real, keep it Free, Keep it GNU

#13196 - yaustar - Mon Dec 08, 2003 12:06 am

Every company will have their own way of doing a design spec. I would have personally though that a game design spec would be how it would look and feel as well as a short abstract of the game content. Try going to www.gamasutra.com for this kind of thing.
_________________
[Blog] [Portfolio]

#13203 - poslundc - Mon Dec 08, 2003 2:56 am

I think it largely depends on the size and type of the group you are working with.

In my case, I am programming pretty much on my own, so my primary concern with documentation is making sure I'll be able to go back and understand all of my code later on. To achieve this, effective inline commenting of code as well as a couple of other text documents where I jot down module behaviour specifications, pseudocode for algorithms, etc. are sufficient. I also try to be consistent with my naming patterns for variables, constants, etc. and use prefixes (aka namespaces) to identify where everything belongs.

At the opposite end of the scale, you could code a game with a fully modularized structure that uses information hiding to encapsulate and insulate each major element of the game's code from the rest of the project. Each module could have a formalized MIS (Module Interface Specification) and MID (Module Internal Design) so that different programmers can just plug their modules into each other without worrying about the code. I do not think that this level of rigor is very well suited to a game on an embedded platform, though, which rarely has more than a few programmers working on it.

I think most teams find an effective balance between the two. The litmus test is to have your code and documentation reviewed by another team member to make sure they can understand and follow it.

I do not believe anything like UML is necessary for designing a GBA game. These are games we're designing, not nuclear reactors - design documentation is great, but far more important is effective communication between the coders.

Dan.