🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Game Design Methods
Author
Hi
I am designing and writing a simple 3D game as my final year project at university. One of the things I have to write about is the analysis and design methodology that I am going to use. Does anyone know what methodologys (if any) are used to design develop comercial games. I don''t think that typical academic methods and practices relate to the design of game content in the same way that they would to say a database application but they could be applied to the design of a game or graphics engine which has set aims and requirements.
My question is; do games companys use standard structured methodologies or a more ad-hoc approch to designing their products.
- Reality
I''m sure it would depend on the house, but from what I''ve seen it''s pretty ad hoc. The most formality I''ve seen in a doc is layout. For example:
Introduction
Executive Summary
Backstory / Setting / Setup
Story (if any)
Gameplay
User Interface
Technical
etc.
The Technical Requirements doc tends to be more formal, and goes into the technical challenges of the engine, asset requirements, manpower, and maybe even a rough schedule (this is all from what I''ve seen, YMMV)
At one place I worked I tried to get competitive product analysis going in a formal fashion. But I found that the personalities that are into games (that I dealt with, anyway) normally weren''t into detailed analysis. It was considered boring.
--------------------
Just waiting for the mothership...
Introduction
Executive Summary
Backstory / Setting / Setup
Story (if any)
Gameplay
User Interface
Technical
etc.
The Technical Requirements doc tends to be more formal, and goes into the technical challenges of the engine, asset requirements, manpower, and maybe even a rough schedule (this is all from what I''ve seen, YMMV)
At one place I worked I tried to get competitive product analysis going in a formal fashion. But I found that the personalities that are into games (that I dealt with, anyway) normally weren''t into detailed analysis. It was considered boring.
--------------------
Just waiting for the mothership...
On the technical side you could look into the Unified Modeling Language (UML). It's great for the design of the source code and depending on the modeler can auto-create code. Check out Rational Rose for more info.
I am not sure that if UML is used in game development but it is certainly used in other large software development.
--------
Andrew
Edited by - acraig on October 25, 2000 3:25:19 PM
I am not sure that if UML is used in game development but it is certainly used in other large software development.
--------
Andrew
Edited by - acraig on October 25, 2000 3:25:19 PM
There are basically two methods, engineered and conceptual. The following is an except from a game designer constrasting them.
-------
And yes, many of the design axioms that made SC very successful are in fact applied to Strifeshadow, though the axioms I use are things like "make units have unique and non-redundant purposes"... "make each race different", "hold balance in high regard", "gameplay over reality" and other very broad reaching things that are virtually tautologies to my game design perspective when applied to RTS -- which is a style I call the engineered style, and which is followed by Valve, Blizzard, Looking Glass, and a lot of my other favorite companies.
Basically, engineered design is when you design everything for a reason, basically making artificial constructs to satisfy the gameplay you want to make, rather than making up some simulation and struggling to make it into a game. For instance, the Chaos Elemental got created by:
1) Determining that I do in fact need a unit of its gameplay characteristics
2) THEN artistically designing the unit
The style of design most in opposition is the conceptual style (as I call it), which is basically as follows:
1) Think of something that sounds/looks cool
2) implement it
3) Fiddle with things to try to make it part of a cohesive role
The first style is planned and reliable, the second is more of a crap shoot. Some of the most successful games of all time have used the second style, but seldom were the companies future games good... I won''t name anyone in particular. The engineered style consistantly produces good games, using engineering thought that has worked for ages on everything else, including software engineering.
The reason that engineered style is always better than conceptual is that you can always apply conceptual "smoothing" to the game after you design the function of game elements. For instance, give me a unit desc in terms of gameplay effect, and I''ll come up with a cool unit that matches the specifications. At least 3 or 4 hours per unit was spent on some of the harder ones where we had a good gameplay sketch, but no artistic vision to match it... The Dark Locust was one of those, so was the Chaos Elemental, so was the Tainted Wisp.... and some other units I won''t talk about.
-------
And yes, many of the design axioms that made SC very successful are in fact applied to Strifeshadow, though the axioms I use are things like "make units have unique and non-redundant purposes"... "make each race different", "hold balance in high regard", "gameplay over reality" and other very broad reaching things that are virtually tautologies to my game design perspective when applied to RTS -- which is a style I call the engineered style, and which is followed by Valve, Blizzard, Looking Glass, and a lot of my other favorite companies.
Basically, engineered design is when you design everything for a reason, basically making artificial constructs to satisfy the gameplay you want to make, rather than making up some simulation and struggling to make it into a game. For instance, the Chaos Elemental got created by:
1) Determining that I do in fact need a unit of its gameplay characteristics
2) THEN artistically designing the unit
The style of design most in opposition is the conceptual style (as I call it), which is basically as follows:
1) Think of something that sounds/looks cool
2) implement it
3) Fiddle with things to try to make it part of a cohesive role
The first style is planned and reliable, the second is more of a crap shoot. Some of the most successful games of all time have used the second style, but seldom were the companies future games good... I won''t name anyone in particular. The engineered style consistantly produces good games, using engineering thought that has worked for ages on everything else, including software engineering.
The reason that engineered style is always better than conceptual is that you can always apply conceptual "smoothing" to the game after you design the function of game elements. For instance, give me a unit desc in terms of gameplay effect, and I''ll come up with a cool unit that matches the specifications. At least 3 or 4 hours per unit was spent on some of the harder ones where we had a good gameplay sketch, but no artistic vision to match it... The Dark Locust was one of those, so was the Chaos Elemental, so was the Tainted Wisp.... and some other units I won''t talk about.
quote: Original post by Reality
My question is; do games companys use standard structured methodologies or a more ad-hoc approch to designing their products.
Digipen is a school which has a 4 year accredited degree program in game programming. Visit the digipen site and look at some of the student project pages, some contain very detailed design documents. Like this one.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
