I have written a design document for my game Kriege. It is an RTT, top-view, tile-based tank game. I would greatly appreciate feedback on the game, the design, and the design document itself. Please advise me on what to add to the game, what to change, and what to take out. I would also like to know about any reorganization, clarification, etc. needed in the design document. The document is several pages long, so I have posted it in both HTML and RTF formats. HTML Kriege Design Document 1.0 RTF Kriege Design Document 1.0 Thank you for your feedback and help! Neg negcx@pacbell.net [edited by - Neg on July 31, 2002 3:29:31 AM]

First, it´s not a design document yet - what you have there I´d call a treatment (a design doc is supposed to include everything, including scribbles, etc.).

A few points:

How is unit building limited? If a unit is destroyed, does the ammount of food used get returned to the pool to be invested in new units? Or is it gone?

You don´t have any USPs listed - you should make a chapter for that somewhere near the beginning of your document.

Scribbles please - game screens, build screens and general interface.

A lot of areas are briefly mentioned but not described in any detail (such as upgrading, formations, etc.)

from the overall impression I though that you might wanna take a look at these games: Z (Bitmap Bros. I think), Mechcommander2 (Microsoft), Warfare (not sure about this one)

Simplicity of interface can detract from gameplay. Consider "worms" style targeting.

I''d say it is a good start. In order to impress publishers or developers I think you need to remove all the warcraft pointers. In my eyes that spells out "clone"...

A RTT game relies heavily on the different types of units. You should definately consider a section describing the units more in depth together with any possible upgrades.



::aggression is the result of fear::

Ok, it''s a good start, but needs a little bit of touch up, here are some suggestions:

Shorten the "Game Overview"

Generally the game overview should try to capture the essence of what the game is about in as little text as possible. You got into a lot of detail about the gameplay that would have been better placed in the gameplay/ game mechanics section. Hit the key points in your game with a brief sentence and then expand on them later in the document. The first 2 sentences did a good job of introducing the concept, but then all the details began to boggle me down before I could get a clear image of the game. Little more was needed , but the game objectives.

AI and Multi-player sections look good.

The first sentence in the Game Progression would be best put in the Game Overview, and then repeated or re-emphasized at this point.

VISUALS!!!

Yes! They are a must! Show mock up screens of everything I understand if you just came looking for feedback on the document, but it is harder to review a concept without a clear idea of what the designer has in mind.

Last question for you... How exactly is this differnt from any other RTT? What makes your game unique over Warcraft that would make people buy your game? Who''s your audience?

Just stuff you might want to add in the game overview section.

OK, hope I''ve helped. Good luck on your project.

peace

-Sage13



Liquid Moon Team

Project X2

Thanks for the great feedback guys. This is my first game design. I''ll get working on those items and post another revision soon.

Thanks,

Neg
negcx@pacbell.net

I would make one big suggestion. DUMB DOWN your writting style. If your planning to ever mass market this game, you should not ASSUME that your speaking to an advance player or even an experianced computer users. You shouldn''t use acronyms like RTS or RTT nor even GUI. And never mention other games in your documentation, as you did with War Craft. Not only for legal reasons but because you have to speak to the lowest common denominator. You have to assume your audiance has never even seen another RTS let alone played one. Trust me if you don''t dumb down the documentation your customer service email and/or phone lines will be jammed with newbies, then you''ll start loosing your audiance. Be cause they can''t understand the game, and they cant understand the manuel. Well hope this helps.
-Nef

PS this is ok for an IN-HOUSE design document. but dont expect to show it to out side investors or use it as an instruction manuel for players.

Well, surely when someone says "design document" they mean "design document", not "user documentation" or "proposal for publishers"...

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]