The jobs and tasks that a designer does on a day to day basis differs alot from one individual to another. Even design documents have no set standards, but I''ve been wondering exactly what do most of you cover (if you''ve written one) in your game design documents and what don''t you cover?
Is it a case of not stepping on the toes of others (lead artist, lead programmer etc.) or is it a case of, sticking your hand in anything and everything that you can and letting the others take care of what you can''t due to time and ability constraints?
I''m currently trying my hand at writing up a design document for a large scale RPG, but it occurs to me that I''ve got to detail alot of things, including setting, story, characters, in order to construct the scenarios that the player will be involved in - however to what detail do I go into the stuff?
Also, its common that designers are employed from within the company, so that a lead artist or a lead programmer becomes the lead designer - to what degree to these people keep the tasks of their previous title?
Zaptruder
Game designs...
Author
Most of us that frequent this board knows that the title of Game designer is an elusive and most importantly, confusing one The jobs and tasks that a designer does on a day to day basis differs alot from one individual to another. Even design documents have no set standards, but I''ve been wondering exactly what do most of you cover (if you''ve written one) in your game design documents and what don''t you cover?
Is it a case of not stepping on the toes of others (lead artist, lead programmer etc.) or is it a case of, sticking your hand in anything and everything that you can and letting the others take care of what you can''t due to time and ability constraints?
I''m currently trying my hand at writing up a design document for a large scale RPG, but it occurs to me that I''ve got to detail alot of things, including setting, story, characters, in order to construct the scenarios that the player will be involved in - however to what detail do I go into the stuff?
Also, its common that designers are employed from within the company, so that a lead artist or a lead programmer becomes the lead designer - to what degree to these people keep the tasks of their previous title?
Zaptruder
The jobs and tasks that a designer does on a day to day basis differs alot from one individual to another. Even design documents have no set standards, but I''ve been wondering exactly what do most of you cover (if you''ve written one) in your game design documents and what don''t you cover?
Is it a case of not stepping on the toes of others (lead artist, lead programmer etc.) or is it a case of, sticking your hand in anything and everything that you can and letting the others take care of what you can''t due to time and ability constraints?
I''m currently trying my hand at writing up a design document for a large scale RPG, but it occurs to me that I''ve got to detail alot of things, including setting, story, characters, in order to construct the scenarios that the player will be involved in - however to what detail do I go into the stuff?
Also, its common that designers are employed from within the company, so that a lead artist or a lead programmer becomes the lead designer - to what degree to these people keep the tasks of their previous title?
Zaptruder
Though the details of how far to go will vary from person to person, the general idea is that you should at least touch everything.
Myself, I typically try to do things in a recursive sort of fashion. Build up a high concept, then look at the different parts of that, and explain more about those. Then look at those different parts, and explain that.
For the most part, I put as much information into every section as I can. However, it''s not necessarrally me doing all the writing now. If I have access to a willing artist, I''ll confer with them (or even have them write) about the art sections. If I have access to a willing sound engineer, I''ll confer with them too.
I typically try not to delve into the technical specifications very much, as those should develop from the capabilities and resources of the team, and the technical lead (theoretically) has the best knowlege of that. Typically we''ll go back and fill those sections in later, after he reads over the design specs.
If there''s a tough section to puzzle out, go into more detail, sometimes technical levels of detail, but never CODE levels of detail. (If that makes sense)
And if you''re desiging a large scale RPG, you''ve got a lot of things you missed in there. Some stuff you also need to consider are your battle system mechanics, battle system disply, stats, equations used on those stats, monster AI, movement types, map styles (one continuous indoor map, overworld/town map), ways of eqipping stuff, how your stuff interacts with stats.
Ideally, with good content creation tools (unless you''re going to go the ultra CG/Special Animation route) you can rough out the story/characters/locales, and fill them in later. However, that''s not the best idea ever, especially if you''re going to be working in another position later. On these, go into detail in various levels, start light, and work your way to heavy(preferably with different sections on each. It''s hard to have too much detail, but make sure you have the big picture in mind first.
hope that helps
Myself, I typically try to do things in a recursive sort of fashion. Build up a high concept, then look at the different parts of that, and explain more about those. Then look at those different parts, and explain that.
For the most part, I put as much information into every section as I can. However, it''s not necessarrally me doing all the writing now. If I have access to a willing artist, I''ll confer with them (or even have them write) about the art sections. If I have access to a willing sound engineer, I''ll confer with them too.
I typically try not to delve into the technical specifications very much, as those should develop from the capabilities and resources of the team, and the technical lead (theoretically) has the best knowlege of that. Typically we''ll go back and fill those sections in later, after he reads over the design specs.
If there''s a tough section to puzzle out, go into more detail, sometimes technical levels of detail, but never CODE levels of detail. (If that makes sense)
And if you''re desiging a large scale RPG, you''ve got a lot of things you missed in there. Some stuff you also need to consider are your battle system mechanics, battle system disply, stats, equations used on those stats, monster AI, movement types, map styles (one continuous indoor map, overworld/town map), ways of eqipping stuff, how your stuff interacts with stats.
Ideally, with good content creation tools (unless you''re going to go the ultra CG/Special Animation route) you can rough out the story/characters/locales, and fill them in later. However, that''s not the best idea ever, especially if you''re going to be working in another position later. On these, go into detail in various levels, start light, and work your way to heavy(preferably with different sections on each. It''s hard to have too much detail, but make sure you have the big picture in mind first.
hope that helps
quote:Original post by Zaptrudr
Even design documents have no set standards, but I''ve been wondering exactly what do most of you cover (if you''ve written one) in your game design documents and what don''t you cover?
everything - as detailed as possible.
If this is going to be your first time writing a game design doc, I don''t know if you would want to start with this massive RPG. Not before you at least write one for a simple game. I used to try writing design docs for huge SquareSOFT like projects and things just quickly got out of hand. But after making up some simple small games and finishing those using design docs, I developed a better feel for the total development process of a design doc.
For these huge projects I usually turn to a design notebook. There you can scribe out every single aspect about the game without fear of being too formal or organized. then once your finished designing in the notebook, you can organize it and compile it all into a design doc. It''s just easier for me, don''t know if it will help you any.
peace
-Sage13
Watch in bewilderment as he proceeds to hump the wall.
-WGM
Find something you want to do in life, find out how to do it, and then do it.
~Sage13
For these huge projects I usually turn to a design notebook. There you can scribe out every single aspect about the game without fear of being too formal or organized. then once your finished designing in the notebook, you can organize it and compile it all into a design doc. It''s just easier for me, don''t know if it will help you any.
peace
-Sage13
/planetmorningstar.jpg)
~In "Sonic Adventure" (Dreamcast), select Knuckles. Jump on a wall and let him hang on it.
Watch in bewilderment as he proceeds to hump the wall.
-WGM
Find something you want to do in life, find out how to do it, and then do it.
~Sage13
Sage13: I think your sig may not be quite big enough. I'm running at 1600x1200 and it doesn't quite fill the screen. 
[edited by - Sandman on March 18, 2002 11:39:48 AM]
[edited by - Sandman on March 18, 2002 11:39:48 AM]
If you want some guidelines take a look at this url :
http://www.cs.ubc.ca/spider/forsey/448/UBCSyllabus_2001.html
Then look for the "Primers & Templates for Workshops & Project" section. You''ll find many template documents (WORD file format) that could help you to build your own design docs (that is how I''ve learnt to do with these templates)
http://www.cs.ubc.ca/spider/forsey/448/UBCSyllabus_2001.html
Then look for the "Primers & Templates for Workshops & Project" section. You''ll find many template documents (WORD file format) that could help you to build your own design docs (that is how I''ve learnt to do with these templates)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
