The Modular Game Design Document
Author
So, according to the wiki, a game's design document should be "as modular as possible". I've never really understood the concept of modules outside of the real world (modular power supplies, modular homes, etc.). What exactly does it mean to have a "modular" design document, and would one go about creating a modular structure?
Thanks for replies! :)
A modular design document is useful if you can do something like give one programmer the section on the combat system and say okay you program the combat system, and another the section on crafting and say ok you program the crafting system...
Here's a small example of non-modular game design:
GDD: PAC-MAN
now here's a more modular version
GDD: PAC-MAN(revised)
See how in the second example, all the details for one ghost are grouped together in one block? Now imagine this game design document has grown to 200 pages. In a real design document, that grouping of related information means you don't have to scan every page of the document to find every instance of "Color", "score" and "speed" if you want to add Pinky the game. It's all together, within a small range of pages, making it easier to add or remove ghosts later on.
(Also, what sunandshadow said :-) )
GDD: PAC-MAN
- Speed
- Blinky: speed = 10
- Clyde: speed = 5
- Graphic
- Blinky: color= red
- Clyde: color = orange
- score
- Blinky: score = 10
- Clyde: score = 7
now here's a more modular version
GDD: PAC-MAN(revised)
- Blinky
- speed = 10
- color= red
- score= 10
- Clyde
- speed = 5
- color= red
- score= 7
See how in the second example, all the details for one ghost are grouped together in one block? Now imagine this game design document has grown to 200 pages. In a real design document, that grouping of related information means you don't have to scan every page of the document to find every instance of "Color", "score" and "speed" if you want to add Pinky the game. It's all together, within a small range of pages, making it easier to add or remove ghosts later on.
(Also, what sunandshadow said :-) )
Author
Quote:Original post by sox
Here's a small example of non-modular game design:
GDD: PAC-MAN
- Speed
Blinky: speed = 10
Clyde: speed = 5
- Graphic
Blinky: color= red
Clyde: color = orange
- score
Blinky: score = 10
Clyde: score = 7
now here's a more modular version
GDD: PAC-MAN(revised)
- Blinky
speed = 10
color= red
score= 10
- Clyde
speed = 5
color= red
score= 7
See how in the second example, all the details for one ghost are grouped together in one block? Now imagine this game design document has grown to 200 pages. In a real design document, that grouping of related information means you don't have to scan every page of the document to find every instance of "Color", "score" and "speed" if you want to add Pinky the game. It's all together, within a small range of pages, making it easier to add or remove ghosts later on.
(Also, what sunandshadow said :-) )
Ooooohhhh, so it's like classifying. :D I understand abstraction really well. :>
Hi, it is as described, with the intention to minimize the number of places you need to edit if you need to change something.
For example, suppose you are designing a RTS where weather has an effect on the attack/defense stats of the units. Hypothetically you could include the effects as you describe the units in the units section. On the other hand, you could list the effects separately in a different section without referring to the specific unit name:
style 1:
Unit\Squid
The squids live in the sea. They eat submarines and battleships. When the weather is stormy they do not go near the surface and would not attack ships.
style 2:
Unit\Squid
The squids live in the sea. They eat submarines and battleships.
Weather\Storm
Units in the sea are afraid of lightning. During a storm, sea creatures will not surface to attack enemies on the ocean surface.
The point is that if during the development you decide that the game will not have weather effects, you could just X out the entire weather section without editing the weather effect corresponding to each unit. This style makes the concept of "Weather" a modular component of the design--a set of definitions that you could include or exclude at will without changing any other part of the design.
For example, suppose you are designing a RTS where weather has an effect on the attack/defense stats of the units. Hypothetically you could include the effects as you describe the units in the units section. On the other hand, you could list the effects separately in a different section without referring to the specific unit name:
style 1:
Unit\Squid
The squids live in the sea. They eat submarines and battleships. When the weather is stormy they do not go near the surface and would not attack ships.
style 2:
Unit\Squid
The squids live in the sea. They eat submarines and battleships.
Weather\Storm
Units in the sea are afraid of lightning. During a storm, sea creatures will not surface to attack enemies on the ocean surface.
The point is that if during the development you decide that the game will not have weather effects, you could just X out the entire weather section without editing the weather effect corresponding to each unit. This style makes the concept of "Weather" a modular component of the design--a set of definitions that you could include or exclude at will without changing any other part of the design.
Quote:Original post by partymetroid
Ooooohhhh, so it's like classifying. :D
Well... it's like classifying, and then writing separate documents for each class.
You ought to be breaking down (classifying, if you like) your design anyway, all "modularization" means is writing separate documents on each of those sections.
Note, though: when you start writing the design, you'll find a lot of interrelatedness that can sort of muddy up the neat dividing lines between your modules.
The section on the onscreen user interface (the HUD, the menus, the shell/front end) will inevitably have to reference the section on the controls. For instance.
The students in my design class inevitably run into this cross-contamination problem. I assign their design project into modules, and inevitably somebody winds up writing stuff in one module that ought to be in another.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
