managing game development
Author
Hi!
I bought McConnells book "Code Complete" and have a question about it: Does his suggestions how to manage software development, that is,
system specification -> analysis -> architecture -> detailed design -> coding and debugging -> unit testing -> system testing -> maintenance,
also apply to game development (I''m talking about big, commercial games, not a 1k lines pong clone)? Isn''t game development less formal? And does construction really take only 40% of the whole?
I''m looking forward to reading your experiences.
cö
Poizon
It certainly does. A game is nothing more than a specific instance of a computer application. Just like writing a book, cooking food, constructing a house, or any large project (well cooking isn''t a large project but...) it takes a formal plan to be able to complete the project in due time and in good form.
I guess a game could be divided into the following parts:
- Invisible tools (memory/file managers, game data managers)
- Visible tools (editors, file format converters, media viewers)
- Performance monitors (profilers, net-watching utils)
- Game data, media (textures, models, sound, music)
- Game data, encompassing (game levels, maps)
- Game data, detailed (creatures, vehicles, buildings)
- Logic (AI, activity scripts / code)
- Game flow control (story scripts, dialogue, event handlers)
If you further broke these down into terms of code, how each section integrates and interacts with each other section, you would have a very good idea of what the game as a whole will be like. Images and drawings are important, because they not only give you a visual of the final product (intended or otherwise), but they let you express artistically what the game should be like, without hard-coding anything on a computer.
MatrixCubed
http://MatrixCubed.org
I guess a game could be divided into the following parts:
- Invisible tools (memory/file managers, game data managers)
- Visible tools (editors, file format converters, media viewers)
- Performance monitors (profilers, net-watching utils)
- Game data, media (textures, models, sound, music)
- Game data, encompassing (game levels, maps)
- Game data, detailed (creatures, vehicles, buildings)
- Logic (AI, activity scripts / code)
- Game flow control (story scripts, dialogue, event handlers)
If you further broke these down into terms of code, how each section integrates and interacts with each other section, you would have a very good idea of what the game as a whole will be like. Images and drawings are important, because they not only give you a visual of the final product (intended or otherwise), but they let you express artistically what the game should be like, without hard-coding anything on a computer.
MatrixCubed
http://MatrixCubed.org
It''s just a myth that game and application programming are two different beasts. Usually it''s spread by the same people that think writing generic, reusable, portable code should be avoided at all costs in games because "it''s too slow".
- Houdini
- Houdini
Every software can be categorized into the steps you have mentioned. It''s just that some steps are more important (and elaborate) depending on the application you work on. Also ... real software engineering is not as linear as the sequence you have given. What if you specify a system ... and in the detailed design you figure out, that the system is no good, because you can''t implement it ... then you have to ''go back'' to the system specification and change it. So, developing software is NOT a sequence of distinct steps, but rather an interaction of all the development phases with each other. Still, the phases themselves can be found in any software project ... even the 1k lines pong clone. Like:
- system specification ... I want pong
- analyis ... pong consists of two paddles ... blah blah
- architecture ... I''ll allow two players on the same computer, so I can use XXX architecture
- detailed desing .. class diagrams taking over (at least in your head you have some idea what your class structure will look like)
- coding ... do it
- testing ... find bugs (go back to coding)
- system testing ... actually installing your pong game on another maching
- maintenance ... your users find bugs, so you need to fix them
Just grabbing up Houdinis'' comment. I think it is extremely important to consider portable code ... in todays world you might get an edge, if you are capable of developing for several platforms. If you are building a good ''architecture'' then it should be easy to port your software (have an OS abstraction layer, for example). If your interface is good, then code will not be slower!!!
- MK42
- system specification ... I want pong
- analyis ... pong consists of two paddles ... blah blah
- architecture ... I''ll allow two players on the same computer, so I can use XXX architecture
- detailed desing .. class diagrams taking over (at least in your head you have some idea what your class structure will look like)
- coding ... do it
- testing ... find bugs (go back to coding)
- system testing ... actually installing your pong game on another maching
- maintenance ... your users find bugs, so you need to fix them
Just grabbing up Houdinis'' comment. I think it is extremely important to consider portable code ... in todays world you might get an edge, if you are capable of developing for several platforms. If you are building a good ''architecture'' then it should be easy to port your software (have an OS abstraction layer, for example). If your interface is good, then code will not be slower!!!
- MK42
Yes it does, but modern methods involve more sperate iterations and more prototyping. In the old days ... the whole system wouldn''t be integrated together till near the end.
Today, a game shell needs to be in place early ... with prototype front end (GUI and graphics) - this lets the client or designer have a frame of reference for refinement. There will also be a few side experiments to test different technical details like "how much throughput can we get from DirectPlay on a 56K modem".
Then .. stage two (or usually 3-4) ... a basic working program with many glossy and "would be nice" features left out. This is the stage where the artist and sound people start plugging in their work and seeing it operate in game. This is the stage where the game usually looks and feels largely like something already on the market ... it isn''t it''s own beast yet .. it''s just an engine.
Then .. successive reifinement and bringing the code in line with the artistic vision .. and more importantly ... PLAY testing .. to see if it''s fun. You will find that games are largely dependent on their TEMPO for their feel and fun factor ... so here you start doing things like "the tech tree is too shallow" and "act 2 doesn''t move the plot .. and is largely redundant ... should we axe it?" ... etc etc
Oh well ...
I''ve worked on production entertainment before (gambling games) but not the kind that users install and play for to beat ... so i don''t know much of the play testing details from experience ... just reading ... The development however is just like that ... in our case ... the designer (me) knew pretty well the first things needed to be built ... so the dev team began started work on the basic tools and framework while the designer and client fleshed out the smaller details. Then .. as the DirectX graphics and sound support, and config files, and high performance timing, and error loggin etc etc came online ... the artist began sending us stub graphics .... place holders for the final deal .... and from then on ... we ran the program every few hours for the next 6 months (our games we''re played in 1-5 inute series .. except when testing for overnight crahses) ... crazy huh.
Today, a game shell needs to be in place early ... with prototype front end (GUI and graphics) - this lets the client or designer have a frame of reference for refinement. There will also be a few side experiments to test different technical details like "how much throughput can we get from DirectPlay on a 56K modem".
Then .. stage two (or usually 3-4) ... a basic working program with many glossy and "would be nice" features left out. This is the stage where the artist and sound people start plugging in their work and seeing it operate in game. This is the stage where the game usually looks and feels largely like something already on the market ... it isn''t it''s own beast yet .. it''s just an engine.
Then .. successive reifinement and bringing the code in line with the artistic vision .. and more importantly ... PLAY testing .. to see if it''s fun. You will find that games are largely dependent on their TEMPO for their feel and fun factor ... so here you start doing things like "the tech tree is too shallow" and "act 2 doesn''t move the plot .. and is largely redundant ... should we axe it?" ... etc etc
Oh well ...
I''ve worked on production entertainment before (gambling games) but not the kind that users install and play for to beat ... so i don''t know much of the play testing details from experience ... just reading ... The development however is just like that ... in our case ... the designer (me) knew pretty well the first things needed to be built ... so the dev team began started work on the basic tools and framework while the designer and client fleshed out the smaller details. Then .. as the DirectX graphics and sound support, and config files, and high performance timing, and error loggin etc etc came online ... the artist began sending us stub graphics .... place holders for the final deal .... and from then on ... we ran the program every few hours for the next 6 months (our games we''re played in 1-5 inute series .. except when testing for overnight crahses) ... crazy huh.
Author
Thank you all for your informative answers.
I know that games are only a specific type of software and their development costs as much (or even more) skills and attention than others. I asked this quetion because of two things I''ve heard that were different:
1) Micheal Abrash said that when he worked at Quake and went to work in the mornings, he sometimes saw John Carmack still working at a new feature he got the idea of. That doesn''t seem to me like good planning, does it?
2) At Amazon, several people said that the suggestions how to manage game development that were mentioned in a book, were much too formal and "extreme programming" was much better.
I know that games are only a specific type of software and their development costs as much (or even more) skills and attention than others. I asked this quetion because of two things I''ve heard that were different:
1) Micheal Abrash said that when he worked at Quake and went to work in the mornings, he sometimes saw John Carmack still working at a new feature he got the idea of. That doesn''t seem to me like good planning, does it?
2) At Amazon, several people said that the suggestions how to manage game development that were mentioned in a book, were much too formal and "extreme programming" was much better.
Why should having a programmer still be in the office in the morning mean it is bad planning? John Carmack lives and breathes game programming. 90% of the time, he will be there in the morning because he personally wants to test some idea he had, not because of deadline pressures or poor foresight. (Of course, this may not be the same in other situations. And that is not to say Carmack et al are perfect either.)
As for whether ''traditional'' methods are too formal and ''extreme programming'' is better... this is debatable. There is no right or wrong way to carry out a software development project. There are just several methodologies that have been proven to work satisfactorily, and therefore following them reduces the chance of failure. It doesn''t mean that not following them means you''ll fail. Some methodologies are too rigid, and were developed in the days when software was written to last 10 years or so, where it was expected that the developer would "negotiate with the user" during the analysis stage in order to know exactly what to do. This all falls down a bit when issues arise such as competing technology superceding your own, or publisher pressures to produce prototypes or meet a new deadline. This doesn''t mean that the methodology as written in some book is worthless. It just means that it may not be perfect as a whole. Other methodologies are better suited to small groups of experts, whereas others suit larger groups of average programmers. Some suit certain languages better than others. Etc.
These really are questions that are difficult to answer until you''ve done a project and seen what applies and what doesn''t. However, I will give my personal opinion on the design model suggested in the first post - the ordering is correct, but you cannot simply divide everything up in to distinct phases like that unless you (a) can choose your deadline to suit you, or (b) can be sure that you will never need to add new features. Otherwise, you need to be aware that refinement of the design is going to happen during coding, debugging, and testing, and that therefore it is more of an iterative than a progressive process.
As for whether ''traditional'' methods are too formal and ''extreme programming'' is better... this is debatable. There is no right or wrong way to carry out a software development project. There are just several methodologies that have been proven to work satisfactorily, and therefore following them reduces the chance of failure. It doesn''t mean that not following them means you''ll fail. Some methodologies are too rigid, and were developed in the days when software was written to last 10 years or so, where it was expected that the developer would "negotiate with the user" during the analysis stage in order to know exactly what to do. This all falls down a bit when issues arise such as competing technology superceding your own, or publisher pressures to produce prototypes or meet a new deadline. This doesn''t mean that the methodology as written in some book is worthless. It just means that it may not be perfect as a whole. Other methodologies are better suited to small groups of experts, whereas others suit larger groups of average programmers. Some suit certain languages better than others. Etc.
These really are questions that are difficult to answer until you''ve done a project and seen what applies and what doesn''t. However, I will give my personal opinion on the design model suggested in the first post - the ordering is correct, but you cannot simply divide everything up in to distinct phases like that unless you (a) can choose your deadline to suit you, or (b) can be sure that you will never need to add new features. Otherwise, you need to be aware that refinement of the design is going to happen during coding, debugging, and testing, and that therefore it is more of an iterative than a progressive process.
Game programming is indeed different to other areas of programming. Those other areas of programming are also different to each other. If this were not true I''d be an expert in all fields of computer programming.
It is not that games programing on it''s own is unique, but it is just a different field of specialism. I would argue that there are some very unique things to deal with in games programming that do make it stand aside, but then again I could make similar comparision between two other quite distinct fields of programming.
I would also add that such formal planning as may be practiced in other areas is not widely used in the games programming field. However I am not arguing as to whether it shouldn''t.
As for other good programming practices such as writing portable code, etc. It is not that these don''t apply to some extent, but I''d be very interested in seeing portable code put onto a PS2 solely to have a laugh at the resulting efforts. Some of these games platforms are as similar as chalk and cheese. Portable code just doesn''t cut it on these.
But does this prove the point further? Portable code is indeed a good idea in many other programming areas, but that fact that it''s useful to a less extent in games programming is also not unique to the games field.
It''s crazy to compare fields of programming and classify then as the same. It''s no different to saying that all animals are that same. None of them are, but there are definately some common traits and some that are more closely related than others.
It is not that games programing on it''s own is unique, but it is just a different field of specialism. I would argue that there are some very unique things to deal with in games programming that do make it stand aside, but then again I could make similar comparision between two other quite distinct fields of programming.
I would also add that such formal planning as may be practiced in other areas is not widely used in the games programming field. However I am not arguing as to whether it shouldn''t.
As for other good programming practices such as writing portable code, etc. It is not that these don''t apply to some extent, but I''d be very interested in seeing portable code put onto a PS2 solely to have a laugh at the resulting efforts. Some of these games platforms are as similar as chalk and cheese. Portable code just doesn''t cut it on these.
But does this prove the point further? Portable code is indeed a good idea in many other programming areas, but that fact that it''s useful to a less extent in games programming is also not unique to the games field.
It''s crazy to compare fields of programming and classify then as the same. It''s no different to saying that all animals are that same. None of them are, but there are definately some common traits and some that are more closely related than others.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
