While working on my game''s design I thought it might be useful to make a draft of the user''s manual before starting work on the game itself. This is done after completing the design document and is a way to look at the game from the user''s perspective. It forces you to explain the game as you''d explain it to the player. It forces you to think of the game''s background, the game''s goals and the game''s interface. If you can''t properly explain these elements your design is probably lacking. Have any of you ever done this? Is it worth the effort? Can you think of negative side effects to this approach?

interesting idea, but shouldnt your design document cover this?

The design document will be weighted down with intricacies which are required for the dev team but not for the end user. I think it would be a good way to truly be forced to view things from the user''s point of view.

I don''t see any disadvantages of this, because good planning is good planning, and if it''s done well it will help you.

true, it depends on the people and not on whether you label it User manual or Design document

regards
Jindrich kolman

koom,

The design document is written for developers. It includes many things not directly relevant to the user and will offer a schematic presentation, obfuscating certain details which the user might see differently. If the design document is like a blueprint the manual is like a virtual tour of the house.

The design document should include as much information as possible, unlike the user's manual which is more narrow in focus. That's why I label it "user's manual" instead of "design document". This user's manual is used as a supplementary design tool, simply to see things from a fresh perspective. Of course, because the game has not been finished the actual user's manual will be different.

Edited by - chronos on June 23, 2001 3:53:55 PM

EXCELLENT IDEA!

Just last night I was thinking about this, funny enough. This is great because as you said it forces you into a different perspective. I find that any time you have to explain an idea to other people, you get an added benefit of clarity and focus. Even a design doc can be insular, filled with concepts only you and your team really understand. Writing the manual can help you be aware of this.

The only drawback would be that the manual wouldn''t be final. Likely as you test, you''ll tweak. But normally the design doc would need to be revised anyway, so it''s just added documentation.

--------------------
Just waiting for the mothership...

For a game, the "user''s manual" actually comes down to a "user requirements document", which is used often in software development. Normally, in the Software Engineering cycle, you need the user requirements BEFORE you do the software requirements (the "design doc"), so I think this is DEFINATELY a good idea.
I had never thought about doing it like this, but I think it would be a large step forward in game design. It would also shift focus immediately from technology into gameplay, as you''d need to define the gameplay before getting into the nitty gritty...

A good idea, I will apply this to the "Laser Squad Tribute"...


People might not remember what you said, or what you did, but they will always remember how you made them feel.
Mad Keith the V.

Didnt GA&A say something about this? Something about the initial treatment document being roughly what you expect to see in the user manual. After all, both need to contain the following...

Background story and basic game concepts.
General overview of the different tokens in the game and how they relate to each other. Specifics of hit points/damage values are not really needed, although they may be useful for comparison purposes.
Description of how the player interacts with the game (user interface)

Since the user's manual usually contains information which depends on significant planning I felt it might be better to work on the manual after completing the design document. For instance, the Sim City 2000 manual contains details about the game's nature and objectives, tutorials providing a walkthrough of the game, and a reference section explaining every object and interface element in the game. A manual as extensive as this calls for careful planning and would benefit greatly from a detailed design document.

Perhaps it's best to work on the user's manual in stages. Start work on the manual once you have a good idea of what you want for the game (never before sketching out the basics), revise or rewrite the manual as you work on the design document, and finally rewrite the manual when the game is finished. With such an iterative revision process work on the user's manual might better enhance the game's design.

Edited by - chronos on June 25, 2001 9:38:52 PM