Hello, My name is Grant Moran and I am currently a website/graphic designer. I have been dabbling in game design off and on for the last year and ahalf. It has not been until the last few months that I have seriusly taken up the task to start designing my first game. So far I have completed about 60% of my game design doc, aswell as compiling my visual doc. However I have had afew nagging questions. (that probably come from a lack of epirience and study) So if some of you more expeirenced designers could take afew mins to help me find the answer to my questions I would greatly appreiciate it. Although I understand the different elements of game design from a surface level perspective, I was wondering if someone could give a brief run down of how game production flows. What I mean is like, from concept to 3d model to animations to programming. And typically, what kind of conflicts can arise that a new designer should watch for? Hopefully this makes alittle sense. thanks Grant [edited by - BlueSamurai on May 10, 2004 8:07:09 PM]

IME, alot of what you''ll run into depends on what you''re trying to do. The basic cycle that I''ve seen in shops I''ve been in works something like this:

• Overall concept, gameplay sketches, story / character roughs
  
• Concept Art, Storyboards, Puzzle / Challenge Sketches, Gameplay Spec, marketing analysis
  
• Initial sell to VPs, producers (this may come later depending on budget & development freedom)
  
• Some iterations for design doc including peer review
  
• Technical spec, with technology and development risks; data specs, tools that will be used vs. need to be developed
  
• Prototype, peer review (several iterations)
  
• Green light, permission for full development
  
• Tools development, core code
  
• Alpha, start adding features, art, gameplay
  
• Preliminary QA, refining (this is where gameplay theory hits the fan)
  
• Sound design starts
  
• Beta, stable, QA pounds on it
  
• Gold, ship it
  

There are many things to watch out for that will be specific to the product you''re trying to do, but here are some generic bits of advice:

• Know your limits as soon as possible. What''s your polygon budget, how many actors per scene, interface limitations, etc.
  
• Try to get everyone on the same page in terms of tools. A 3D program that spits out normals in a format that another doesn''t like, for instance, can be a simple thing that causes grief
  
• Design a consistent asset format and naming scheme that both artists and programmers will follow. Artists I''ve encountered tend to be less rigorous with something as simple as naming files and changing data, and this can cause stupid little errors that may misdirect programmers (especially those that write brittle code).
  
• Programmers should aim to get art into the product as soon as possible so artists can refine how things look and know what to work around
  

It''s been a few years since I worked in games, so some of this may have changed, but in general these are a few of the things I encountered.

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