Sign in to follow this  

The Modular Game Design Document

This topic is 3142 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, according to the [url=http://wiki.gamedev.net/index.php/Lone_developer]wiki[/url], 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! :)

Share this post


Link to post
Share on other sites
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 :-) )

Share this post


Link to post
Share on other sites
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. :>

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 3142 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this