Archived

This topic is now archived and is closed to further replies.

What are some of the important factors of creating a design document?

This topic is 5480 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

(Off-Topic) Most of the time the lead game designer doesn''t make the engine. The lead programmer does. But when he writes a design document how is he able to describe how the game will playout? (On-Topic) In my humble oppinion. Gameplay and character development are the most important factors. You need to create a protagonist that will stick in the gamers head. A memorable protagonist usually gives the game a great deal of popularity. The characters abilities can fit right under the gameplay. In one of my ideas. The protagonist is an inter-galactic outlaw who is looking for some mysterious treasure locked away in the core of a giant planet. The protagonist is a bipedial brown dog who is equipped with a Mega Man-like suit which has a country-load of features. He can fly with it, shoot cannons, plant bombs, swim fast, etc. Hes an outlaw so he''ll be able to steal other people''s spaceships to get to his destination faster. "A programmer being told to ''''go to'''' hell sees the ''''go to'''' part of the sentence as the bad part."

Share this post


Link to post
Share on other sites
The Design Doc is an overview of the project that can sometimes go on for 15-30 pages but I dont really think thats what you''re after. The Design Doc is not what you want to present your dev team with and expect them to come up with what you are describing. Take the overview of the design Doc and then the design team (generally in a non-funded environment that means YOU heh) hammers out ever little detail of every engine, formula and database of the project breaking each down into micro projects with goals for pre-alpha, alpha,beta and then of course retail. These goals can be muddied together to cut down on paper work but if you even accomplish the pre-alpha stage of your project odds are the alpha/beta stages will be pretty self explanatory.

Good luck

Mark

Share this post


Link to post
Share on other sites
1. Gamplay is not one of the most important parts of a design because it is not something you put into a game but something you get out - if you put the right things in. You don''t design gameplay but instead focus on designing a number of other elements of the game, which if done correctly will result in the user experiencing good gameplay.

You can''t say to an artist "draw me some good gameplay" or to a programmer "you''re coding some gameplay today". You need to identify the elements that can actually be created, which when done well will result in good gameplay.

The following are all key elements of a design:
User interface
Depth of gameplay
Learning curve
Side with the player
Consistant design/environment

In addition to these (and others) your design must also include clear objectives for each element of the program. For example in an Indy Car racing game the 3D engine would need to render a larger number of cars. With a Rally game you only need one or two on screen at the same time. By setting specific objectives at the start it is much easier to measure your progress and make decisions in the heat of development.

Dan Marchant
Obscure Productions

Share this post


Link to post
Share on other sites
quote:
Original post by Obscure
1. Gamplay is not one of the most important parts of a design because it is not something you put into a game but something you get out - if you put the right things in. You don't design gameplay but instead focus on designing a number of other elements of the game, which if done correctly will result in the user experiencing good gameplay.


You're nitpicking. It's true that gameplay is largely an emergent phenomenon, but that doesn't mean that "gameplay is not one of the most important parts of a [game's] design". If gameplay is important and particular design elements are subordinated to the pursuit of good gameplay then designing those elements is designing for gameplay. That you have indirect control over gameplay doesn't mean that it's not intentionally controlled for.

[edited by - chronos on November 19, 2002 6:42:27 PM]

Share this post


Link to post
Share on other sites
In my newly broken in opinion (I used to be heavily supporting descriptions of gameplay and level layouts and everything but the kitchen sink), it depends on the audience, and where you are in the project.

At the beginning, it''s rough concepting and selling the concept. Get the parameters for the project and the ideas flowing. If it''s good enough to hype a publisher about making it, it''ll sure help the developers get pumped.

After that you need to specify out what it''s going to be doing. At this piont the design document starts turning more from motivation to an actual design document. Write in basic plot and guides to the characters, locations, gameplay and so forth. I''ve discovered you can''t hope to get everything. Sketch it in broad outlines, setup the patterns, so when the time comes decisions can be made logically and reasonably.

From there, keep expanding and embillishing on it. Go more accurately into features (and be sure you discuss this with the coders and producers to make sure it''s a ''good'' idea). Describe the levels in depth, build character bibles, and so on.

''Leastways that''s my new found view from the trenches.

Good luck.

Share this post


Link to post
Share on other sites
Loftyideals
"Side with the player" means that you code the game to favour the player, not the computer. Remember that they pay your wages, that they should enjoy the game and that the computer wont sulk if it loses.

A good example of this is MOHAA - A truely excellent game in all respects except one. The enemy AI is far too accurate. This is fine in most cases (standard firefights with MG or SMG) but on the level where you have to pass through a town full of snipers the game falls down badly. As soon as you stick your head around a corner you get hit by a sniper you can''t see. This would be acceptable with SMG fire but a sniper rifle is often fatal with one shot so we are talking about an instant death situation, which is never a good game design feature. The AI should have been tweaked to miss or wing you on the first shot to at least warn you that there is a sniper ahead (you have a medic with you who can heal you if you suffer a non-fatal shot).

This problem was highlighted in most of the reviews and info on the Spearhead add-on is that the AI has been tweaked in this respect.

Dan Marchant
Obscure Productions

Share this post


Link to post
Share on other sites
Chronos,

The original poster was asking what the important elements of "the design document" are - "document" being the important word. My response was aim specifically at that.

The purpose of the design document is to give as much *useful* information to the development team in the most *efficient* method. So it should describe in detail how features should be implemented and those descriptions should be set out logically so that they are easy to find. There is no useful information that can be listed under the heading of gameplay that could not be more accurately or efficiently listed under another heading.

As I mentioned in my previous post learning curve is something that has a specific impact on gameplay. You are right that designing the learning curve is designing for gameplay but you are still designing the learning curve and not the gameplay.

A well structured design doc would be splits into programming, art, audio, story/script, level design. Nothing that fits under one of those headings would be more efficiently placed under the heading of gameplay. The best place for learning curve within such a structure would be level design>level list>learning curve - the section on level one would have its own specification/objective for the learning curve and might cross reference to level two. Level two would have the same and may cross reference those sections for level one and level three so that the designer of level two could see how their level fits into the overal design.




Dan Marchant
Obscure Productions

Share this post


Link to post
Share on other sites
More and more, as I do these design documents, I find (and this kind of sucks) that THE MOST important feature of a design/technical document is the budget. If you have acceptable numbers, that could make or break your game ever seeing the light of day.

All of the other features vary in importance from game to game. A tycoon game will need to spend a lot of time and resources on the UI, so that would be emphasized in the document, where a first person shooter needs much less in the way of interface.

I also try not to describe gameplay, but describe in detail elements that will produce gameplay.

**Dan: Thanks for the explanation.

Dev

Share this post


Link to post
Share on other sites
quote:
Original post by loftyideals
I find [...] that THE MOST important feature of a design/technical document is the budget. If you have acceptable numbers, that could make or break your game ever seeing the light of day.



welcome to the real world . seriously, especially if you´re in europe, money is everything right now. try and be as minimalistic as possible, leaving room for additions should the extra cash come in. and then when you´re done and ready to get going, try and see if you can bring the cost down by another 20%. Then you can start negotiations.

Share this post


Link to post
Share on other sites
quote:
Original post by Obscure
The original poster was asking what the important elements of "the design document" are - "document" being the important word. My response was aim specifically at that.


Okay, I see what you meant now. I agree, gameplay is not something you address explicitly in your design document; it is instead a product of your design choices and emerges out of the interactions of all the relevant parts.

[edited by - chronos on November 20, 2002 5:51:04 PM]

Share this post


Link to post
Share on other sites
if you´re using your design doc in a presentation (say to a publisher) then you´ll have to have sections describing how the game will play and feel (preferably right at the top, you can never know how much of your doc will actually get read).

Share this post


Link to post
Share on other sites
Hase,
You are confussing the design doc with the concept/pitch document. The non-technical people at the publishers would get the story as part of a pitch document but you would only need to supply the design to the development staff.

Dan Marchant
Obscure Productions

Share this post


Link to post
Share on other sites
@Obscure:

Not really, from my experience most publishers want to see full design docs, that usually means that the non-game guys will have at least skim it before handing it down to be reviewed. And for these instances you have to include some general overview and gameplay descriptions in the design doc.
If you have requests for a technical design then it´s a different story entirely, but so far most publishers have wanted "the" design doc (which doesn´t mean that they won´t get all the marketing stuff as well), in which case it´s good to provide an overview as well - it doesn´t hurt to do it, the extra effort is negligable and if you can hold your readers attention for a few pages more then you´ve already taken a big step towards securing a contract.

Share this post


Link to post
Share on other sites
I don''t know about you guys. But I''m able to design gameplay. In one of my design documents I gave an in-depth descriptive of how the character moves, how the controls would be, and the fighting system of the RPG(that I was working on).

I''m not sure why you guys said, "You can''t design gameplay."

.....Well, it just hit my head. I was describing gameplay mechanics wasn''t I? Isn''t that the samething?

"A programmer being told to ''''go to'''' hell sees the ''''go to'''' part of the sentence as the bad part."

Share this post


Link to post
Share on other sites
Obscure - I noticed that your first post in this thread, after saying that gameplay is not an element of the design document, then goes on to say:

quote:

The following are all key elements of a design:
User interface
Depth of gameplay
Learning curve
Side with the player
Consistant design/environment



So, how do you fit "depth of gameplay" into your design document?

[edited by - rmsgrey on December 11, 2002 7:00:37 AM]

Share this post


Link to post
Share on other sites