>Recently instead of desiging 3d graphics technologies I found myself
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,
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:
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
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
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. --
Discuss this article in the forums
See Also: © 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
|