Could someone please review my game design doc and let me know what I need to add to it? I'm constantly working on this and I'm always adding/detracting things from it. ***A few places to note is the camera, character rendering, and engine details. I know these are incomplete so if you could provide some general suggestions of what I should include, that would be fantastic.** http://tortustudios.com/wp-content/uploads/2006/02/tsdesign.doc

It is fairly well formatted, though personally I would move many of the technical/implimentation details to their own document. Granted, my first doc is a few threads down, so my opinion maybe shouldn't account for much :]

Looks like you're using the Chris Taylor template as well [smile].

I've only skimmed through the document quickly at the moment (because I'm meant to be working on something else), but it's an okay start. Personally, I'd think there's a lot of detail missing that I'd want to put in there before considering the document close to complete. In particular, I notice that while you state that the game will be played in a variety of locations (from LA to Shanghai?) you haven't put anything about them in the "Game World" section. You've also not got that much in the "Game Character" section as well.

Personally, I'd also think about putting something a little more concrete in the "Philosophy" section. I'm also using Chris Taylor's template for the game philosophy, but I think it works best if you aim for a more specific target than "this game will be awesome!" [grin]. A vague target is a lot harder to get a feel of how you think your game should play; I had to read several pages before I could even figure out anything about the gameplay.

If you'd like, I'll skim through the document a bit more later on if you want some more specific advice (I like reviewing documents [grin]). I could also post some bits from my (woefully incomplete) design doc for comparison, although like Telastyn I'm also a beginner at the whole writing game design document thing myself. I'm also probably a bit more of a completist when it comes to specifications than most people; that might be a personal preference thing for how much detail you put in your docs [smile].

Thanks you two... I'm working on adding more detail to everuthing but it's coming out of my head quite slowly. I'm not sure if the game will expand all the way around the world...seems like a bit much but you'll be able to play in different countries... I'm also a completionist but I like to get feedback so I can make it better to what people think the game should be like. I'll add more detail about game play and the character...

Also, sure, post something you have so I can see how other people do it...I like to strive to make mine better when comparing...:)

Quote:

Original post by kidd175 Also, sure, post something you have so I can see how other people do it...I like to strive to make mine better when comparing...:)

It seems that I don't actually have a copy of my present design document with me at the moment (I'll have to remember to update the backups on my zip drive!). I do have a copy of the woefully unfinished design document for my old project from last year though. Most of it is fairly incoherent, incomplete and confusing, so I've stripped it down to just the relevant introduction section which was reasonably complete. Here's a link to the file (PDF format).

To clarify what I thought was the big problem with the intro as it stands; at the moment it reads as "I want to make the best game ever", which is a bit too vague to really nail down exactly what you want to do. I'd change the tone of the intro to something more specific, such as "I want to make the best game combination of FPS action with go-kart racing" (or whatever's appropriate to your game [smile]). That way, when you write the rest of the design document you can consider each prospective element carefully for whether it satifies your intended goal.

Looks to me your using the chris taylor template. its very well written although if anyone wanted to write a differnt genre say a MMO it would be hard, but your game sames well thought out. We havnt got onto the Design document stage although we just finished our research on a MMO, next we got Egyptian research to do then the design document so hopefully pre production done by May 2006 :P but with a MMO you cant count on it :P

heres our research page if anyone wanted to take a look

Its mostly gamedev.net and gamesutra design articles, except chapter 1 & 4 thats ours, but its free infomation and all rights are reserved to tthe rightful authors.

http://www.solarsystemstudios.com/Egypt00232123/Egyptmmo19131311_13123_00_211212.html

In your doc I see myself 7-8 years ago. Don't get me wrong if I criticize a lot, I try to do it for your own improvement. :)

If I may proceed...

1. Keep engine technical specs in one document and game design document into another one.

2. Let the lead programmer fill the tech document. For example C++ is a language and DirectX is a library :). I suppose you have little knowledge about programming. You focus about engine requirements (describe in SPECIFIC terms what the engine should do).

For example:
Minimal requirements:
- Dx9 compatible video card, 128Mb memory

The rendering module of engine should support:
- 100k triangles in view per second at 30 fps at 800x600, no AA
- manage geometry of 1,000,000 triangles
- decals on walls
- motion blur for certain objects
- 1000 particles per frame
- directional and omni lighting for terrain, max 3 sources
- directional and omni lighting for characters, max 2 sources
- simple 3D shapes physics (cilinder, cube, whatever you want)
- OPTIONAL - physics for complex objects

Don't dream these numbers. Estimate how your world should look like, take some peep inside existing games and see how much triangles they use and what sort of special effects.

Take WoW. Let's say a "terrain tile" has 5x5 meters and we can see 100 meters far. This means we see 20 tiles ahead. If you know some geometry, you know the height of "viewport triangle" and you can estimate how many tiles you see at a moment. Let's say 100 tiles in view which means 100 x 4 = 400 triangles. They are multi textured and if the video card (and there a LOT of DIFFERENT video cards out there with different specs) cannot render them in one pass you have to draw the terrain with more passes (let's say 4 - lightmap for shadows, tex 1, tex2 and tex3) = 400 x 4 = 1600 triangles. How many objects you see in 100 tiles? 30 trees, 10 animated characters = a number of triangles. Now count sky and all and you get an estimated number. Think about worst case or your game will sometime drop fps like crazy. The idea is not to dream these numbers but know what you expect from engine. Don't dream at Unreal 3 engine (with extra detail realistic lighting). This is more of producer's work and it is done with artists, designers and programmers together but you have to take it into account.


Now let's get back at creation part :)

3. "Crimson Moon is attempting to revolutionize the way PC games and hopefully console games will be played. With never before utilized features, Crimson Moon dreams of setting the standard for PC games and console games to come."

Everyone wants to achieve this. Nobody is stupid in the industry (I mean stupid enough :) ). The biggest mistake for a project is setting unrealistic goals which leads to certain failure. Worst thing ever...

4. You describe too much WHAT you want to achieve and almost nothing at all about HOW you intend to accomplish that. It has been pointed out by other readers as well. Take this into account, think about ways and describe them.

For example in puzzles section (which you said there will big some hard problems players have to face and solve) you may describe something like (inspired from Dungeon Siege II) "considering a web of links between points and a starting point the player can light on or off a <link> by touching a nearby point. The goal is to light on all links". In fact this is a "graph problem" from programming. I found it very interesting and intuitive while playing. The points can be pillars and the links can be pipes or else...

BTW, hardness of a puzzle does not assure player's interest for your game. In fact a hard game will not appeal to most of people. The puzzles must be interesting and simple enough.

5. "This game and engine will take off and be a success because of the tireless dedication from the people who are building it. They believe, like I do, that we can make a really worthwhile game that will appeal to all gamers, casual and core, allowing us to define the PC and console gaming developments to come."

Take a pause, play a game, read a book. "Theory of Fun for Game Design" and "Rules of Play". The last one is written by Zimmerman. The first one I forgot but you can find links on amazon or google. Two very good books which will channel your creation energy onto very well defined paths.

6. Think clear. Express all ideas in a RELEVANT way, don't suppose people know what you are thinking about. EXERCISE a lot. Read articles about game design. Play games and try to apply what you read in articles in that game. See patterns. See how others implemented theory. Think about your own. This is how the things are done and improved.

Don't get that big from the beginning, I know the illusion of a "grand game" shines nicely but start always with what you can manage at current skill level. It is like RPGs ;).

Here are two subjects for your homework:
- design a jump'a'run game (side perspective) with one character. Restrictions: 3 types of tiles, 3 abilities for your character (attack is an ability, jump and movement are avaible actions).

- design a "car washer" game which the player should play at least 15 minutes without getting bored. Restrictions: describe everything is needed for the concept in one page and a half.

These are real-life tests and not jokes.

Hope to hear a word from you soon,
Cod.

Thank you very much for critiquing this horrid DD. I do have programming knowledge, it's just that I haven't done something like this before. Or anything this big. So yeah, things are going to be a little...turse. I'll write the second assignment this weekend while I write more about the storyline and the DD. I will go back to the writing block and chip away on the specifics of how this game will change certain aspects of gaming and so on and so forth. I have my ideas but putting them down in words that others will understand is a problem...I'll figure it out.

Thanks to all who've taken time out to read my design and guide me to a better path.

I'm not making an RPG, just to inform you. I'm not sure how people are gleaning that from the document. I'm re-writing it now to adhere to the suggestions you all have offered and I'll post an update soon containing all of the fixed parts. I am indeed trying to "sell" the game so I'll sell it. You will all be proud of the improvement that this DD will contain. Also, I talked to my Lead Programmer and my #2 Lead Programmer and they understand that they need to begin writing th TD as we program and we'll worry about that also.

Brandon

Original post by kidd175: "I am indeed trying to "sell" the game so I'll sell it. You will all be proud of the improvement that this DD will contain."

I think what they were saying is 'first' you need to sell it to the publisher (if applicable) and your team leaders and mates. Once you have sold it to them then of course you work on developing the game content. Finally, when you have something worthwhile to show for, then you create/use a marketing plan (possibly team) to find where the most/signifigant amounts of the people who would be interetested in your project(as players) frequent, then come up with a plan on how to present it to them. As you're presenting it to them, then you can make it feel like the 'coolest game ever' if you want, just don't overdo it :D

Its good to see that you are improving on your DD, just remember your most beneficial audience at all times, the developers. They need to be on the same page to create as little confusion/miscommunicatio nas possible, and also work together more efficiently.


Original post by kidd175: "Also, I talked to my Lead Programmer and my #2 Lead Programmer and they understand that they need to begin writing th TD as we program and we'll worry about that also."

I haven't worked on any large project personally... but I think the whole point of a technical document is to get a good portion, or as much of as possible of the technical decisions made "before" hand. Such as what graphics API, physics library if applipcable, what kind of 3d module format, texture formats. Then also object details, like what data they hold and their methods. Custom file formats which can be modified of course later if your needs change. Another major decision is what scripting language you will want to use, such as Lua, Python or AngelScript as some examples. Hardcoding is bad in many cases, especially in larger games.

This is my 'view' of a tech document and what I think is in it. Anyone care to confirm/deny my belief. Also give how much needs to be done at least roughly before starting to program. Also what other things may be in it.

Edit: Reworded some areas and elaborated a few points.