RFC on a simple game "FitBall"
by Paul Z · in Game Design and Creative Issues · 06/18/2004 (8:47 am) · 5 replies
Folks,
I would like to solicit your comments on a game idea. I've set up a project page at this address.. The project description contains the first verstion of the game design document (GDD).
Being a newbee at many aspects of game business, I have some broad and specific questions related to GDD. Starting with broad questions:
1. When enough is enough? Does the level of detail described in my project provides sufficient information about the game, the design, visuals, etc. Should it be more detailed, or less detailed.
2. What's next? Is there a "standard set" of documents for a game design and implementation? What are they, what's their structure, etc?
Questions specific to the design of the game.
1. Scoring system - any suggestions/comments would be appreciated, since I am not sure it's complete/clear
2. Some of the sections are not complete (GUI, music, sFX, etc). Again what is the level of detail should be provided.
3. Anything else should be covered by the GDD that I missed?
Thank you, Paul Z.
I would like to solicit your comments on a game idea. I've set up a project page at this address.. The project description contains the first verstion of the game design document (GDD).
Being a newbee at many aspects of game business, I have some broad and specific questions related to GDD. Starting with broad questions:
1. When enough is enough? Does the level of detail described in my project provides sufficient information about the game, the design, visuals, etc. Should it be more detailed, or less detailed.
2. What's next? Is there a "standard set" of documents for a game design and implementation? What are they, what's their structure, etc?
Questions specific to the design of the game.
1. Scoring system - any suggestions/comments would be appreciated, since I am not sure it's complete/clear
2. Some of the sections are not complete (GUI, music, sFX, etc). Again what is the level of detail should be provided.
3. Anything else should be covered by the GDD that I missed?
Thank you, Paul Z.
About the author
#2
I like the idea of the game too, it sounds eminently do-able, unlike a lot of the design docs that go up, and has some originality. Not really sure about the name though: "Fitball" doesn't really make me think of balls "fitting" in places. It actually makes me think of a game involving firing balls at hot women.
Hmm, that wasn't that much more use was it.
Ian
06/18/2004 (9:01 am)
Hmm, okay I'll try a more useful reply. The design doc is pretty comprehensive, I can't immediately see much that's missing.I like the idea of the game too, it sounds eminently do-able, unlike a lot of the design docs that go up, and has some originality. Not really sure about the name though: "Fitball" doesn't really make me think of balls "fitting" in places. It actually makes me think of a game involving firing balls at hot women.
Hmm, that wasn't that much more use was it.
Ian
#3
For a preliminary design doc, that's pretty good. I think the best suggestion I can make is that you should keep the design doc an iterative process. That is to say, at this stage you should not necessarily be locking things down as far as features and details. Keep a record of the big changes that you make in the document, and list those changes on a separate document which you attach to the front of your "final" design doc. I'd say lay out all the possible features you can cram in, then start prioritizing them, removing the ones that are extraneous, putting off the ones that could be "polish," and emphasizing the basics.
06/18/2004 (9:05 am)
If there was a "standard" design doc, I'm sure things would be much different, for better or worse, as far as developing a game goes.For a preliminary design doc, that's pretty good. I think the best suggestion I can make is that you should keep the design doc an iterative process. That is to say, at this stage you should not necessarily be locking things down as far as features and details. Keep a record of the big changes that you make in the document, and list those changes on a separate document which you attach to the front of your "final" design doc. I'd say lay out all the possible features you can cram in, then start prioritizing them, removing the ones that are extraneous, putting off the ones that could be "polish," and emphasizing the basics.
#4
@Ian: I agree, the "unique" feature is really not unique, although some elements of it (dynamic change of projected path as the player tilts the paddle at different angles) might qualify :-). The current title of the game is just a place holder, until I can come up with something better. But this is hard... I remember reading about Intel spending over $3M to come up with "Pentium" name.
@Axel: I understand that there is no standard design doc. I created FitBal doc based on several templates/example I found on the net. But there sould be as sort of a standard SET of docs that covers the entire process. What I am getting at is that I can see the GDD branching out into several separate functional sub/documents like:
1. Art - describes/specifies all of the game art.
2. Game Architecture - defines technical architecture, physics implementation, classes, interfaces, etc. It might branch out into server and client subdocuments with the same content, etc.
3. Music/SoundFX - describes/specifies music and sFX.
Obviously, one can and (should)go into tremendous level of detail in all of these topics, but do these details belong in GDD? my gut feeling is "no", but I've never seen a completed GDD, so I might be wrong.
Thanks, P.Z.
06/18/2004 (9:48 am)
Folks, thanks for the comment...@Ian: I agree, the "unique" feature is really not unique, although some elements of it (dynamic change of projected path as the player tilts the paddle at different angles) might qualify :-). The current title of the game is just a place holder, until I can come up with something better. But this is hard... I remember reading about Intel spending over $3M to come up with "Pentium" name.
@Axel: I understand that there is no standard design doc. I created FitBal doc based on several templates/example I found on the net. But there sould be as sort of a standard SET of docs that covers the entire process. What I am getting at is that I can see the GDD branching out into several separate functional sub/documents like:
1. Art - describes/specifies all of the game art.
2. Game Architecture - defines technical architecture, physics implementation, classes, interfaces, etc. It might branch out into server and client subdocuments with the same content, etc.
3. Music/SoundFX - describes/specifies music and sFX.
Obviously, one can and (should)go into tremendous level of detail in all of these topics, but do these details belong in GDD? my gut feeling is "no", but I've never seen a completed GDD, so I might be wrong.
Thanks, P.Z.
#5
What you want are several breakout documents that describe ONLY WHAT NEEDS TO BE DONE.
Let me explain a bit further.
Ok, so artists need to create art for the game. So they need:
1) A list of all items, including animations, polycounts etc.
2) Style guide for each item (concept drawings perhaps).
3) A brief synopsis of how it functions etc.
4) Maybe a reference back to the GDD if more info is needed.
Thats it. They dont need backstory, they dont need any sales waffle you might have used to sell the game idea to your bosses or publisher/public etc.
Programmers need a TDR (technical design requirements) style doc. Including:
1) A list of all objects
2) A list of the interactions between the objects in purely mechanical terms
3) A concrete description (including things like movement speeds, damage rates of weapons etc), of all the "configurable" data the game needs.
Now some of these things can be marked down as TBC (to be considered) initially, so dont think this is all at once. But at least they can get on with producing the game and NOT reading some game design "story" trying to figure it out for themselves.
Hope that helps a bit.
06/19/2004 (1:17 am)
No, you definitely DO NOT want too much detail in a game design document. That way, no-one but the author will read it (and even then its unlikely).What you want are several breakout documents that describe ONLY WHAT NEEDS TO BE DONE.
Let me explain a bit further.
Ok, so artists need to create art for the game. So they need:
1) A list of all items, including animations, polycounts etc.
2) Style guide for each item (concept drawings perhaps).
3) A brief synopsis of how it functions etc.
4) Maybe a reference back to the GDD if more info is needed.
Thats it. They dont need backstory, they dont need any sales waffle you might have used to sell the game idea to your bosses or publisher/public etc.
Programmers need a TDR (technical design requirements) style doc. Including:
1) A list of all objects
2) A list of the interactions between the objects in purely mechanical terms
3) A concrete description (including things like movement speeds, damage rates of weapons etc), of all the "configurable" data the game needs.
Now some of these things can be marked down as TBC (to be considered) initially, so dont think this is all at once. But at least they can get on with producing the game and NOT reading some game design "story" trying to figure it out for themselves.
Hope that helps a bit.
Associate Ian Omroth Hardingham
Mode 7 Games
Ahem. Only unique if you ignore pool games.
In other news, Terminator: Future Shock thinks it was the first fps to use mouse look. It is also mistaken.
Ian