Lifecycle and Duration of Game Design

Published July 16, 1999 by Francois Dominic Laramee, posted by GameDev.net
Do you see issues with this article? Let us know.
Advertisement
Lifecycle and duration of game design
from Usenet Posting on comp.games.development.design

>Recently instead of desiging 3d graphics technologies I found myself
>workingon a bona fide game design. Boy, it was/is a lot of work! I
>was surprisedat how much work it took.

Yep, that's usually the feeling. We designers can't get no respect in this industry ;-)

>I realize now that it's a position one could be paid to do fulltime,
>because it's that much work.

Not many companies are willing to do it, though, and I am not sure that I disagree entirely with their point of view. Although personally, I would like nothing more than to spend all of my time designing games, there are good reasons why a designer should take on another role. For example:

  1. Most of the design work takes place before production begins. Once the design doc is written, keeping it up to date, making the occasional judgment call and making sure that the product follows your vision nicely isn't really a full-time job. Two days a week, maybe three on a big project, but not much more. So, unless you are a consultant working part-time, either you lead the art or coding team, or you get to work on the *next* design project; and since that one is all new and exciting, you devote most of your effort to it, and you spend less and less time on the game in production. That means that the *producer* now has free reins ;-) and that the game is left without global creative direction. Not a good thing.
  2. Despite common misconceptions, design work can be quite exacting. Unless you are unusually versatile and resourceful, you will need some time to recharge your creative batteries after a large project. Otherwise, you may burn out, and turn out a Project N+1 which looks surprisingly like Project N.
  3. Sometimes, having a full-time designer on a project in production is a catastrophe waiting to happen, because he may get bored, and if so, he'll keep designing. He'll keep thinking of really cool new traps for the next level (which requires the level designers to re-write their floor plans and 3D models), or he'll have this great new idea for a monster's attack (which requires re-writing the character animations and changing the sound effects, and maybe adding a new feature to the level editor), etc.

At a rate of 2-3 full designs a year, plus however many dozens of failed treatments would be required to hit the 2-3 good ideas, you could justify a full-time designer easily; with an average product budget of 2 million bucks, the 25-50K the design will cost is insignificant from a financial standpoint. But to be a good full-time designer, you need to be very versatile, have lots of energy, be able to focus on several projects in parallel, and to know when to *let go* and stop tinkering with a product. Not many people I have met can do that.

>Does anyone have any keen insights into the lifecycle of the game design
>process? How long it'll take you?

I have spent 50-100 hours on trivia games and play-by-emails, 150 hours on action games (I can't draw, so that doesn't include actual mapping of levels, graphic bibles and stuff like that), about 200-250 on sports simulations, and I expect to spend about 300 on the online world I will be working on in the next few months (including a fair but limited number of scenarios for missions). I have also noted that 25 hours a week is about as much efficient design time as I have in me; the law of diminishing returns takes over in a big way at that point.

I have posted an article on my game design methodology on my web site at http://pages.infinit.net/idjy/games/designprocedure.html

Not very detailed, because it is based on a two-hour lecture I give at a local school, but it may give you a few insights.

>How you know when you're stuck, and how to overcome it?

In software engineering terms, game development is the stereotypical "exploratory prototyping" project. You may not understand the requirements of the project very well when you start out, so you design/prototype/playtest iteratively. The prototype may be code, cardboard, playing cards, or just a preliminary design doc, depending on the type of project.

>What are your favorite game design tools? Mine are pencil, paper, and
>modeling clay.

Mine are an iterative design methodology of which I have gathered parts here and there and which I am comfortable with, word processor, a well-stocked bookcase and lots of cardboard.

With all the games coming out with scripting languages these days, it might be a good idea to use an existing commercial product of the same genre as a prototyping tool for your own game; this way, you can try out a few things before writing a line of code, and you can keep experimenting as you go along. Never tried that one before, but I will probably do it in the future. Techniques I use include building a table-top board game as a prototype; works much better for trivia games and simulations than for FPS's, but can be done in a few hours. I also run through several versions of design docs, each with its own specific purpose (i.e., qualitative listing of functionality, scheduling priorities, describing major AI algorithms, etc.), and distribute them to as many competent designers as time and legal restrictions allow.

--
Francois Dominic Laramee
Game Designer and Artificial Intelligence Researcher
francoislaramee@DEATHTOSPAMMERS.videotron.ca
http://pages.infinit.net/idjy

Cancel Save
0 Likes 0 Comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement