It''s been my experience outside the gaming industry... Many people seem to think they can''t afford to design, or think it''s a waste of time.

The cheesily named "eXtreme programming" method is probably best suited to game development.

There''s the "water-fall" way of doing things, but you''d have to be lethally optimistic (or blinded by the view of your colon) to beleive that works.

Though their self-righteous (and sometimes contrived) examples detract from the work, "Game Architecture and Design" by Andrew Rollings & Dave Morris is the land-mark work (i.e. the only one in print) on this topic, AFAIK. Despite the way its presented, there are good ideas in there.

Magmai Kai Holmlor
- Not For Rent

I wouldn''t call the waterfall or extreme programming models as something pertaining to design and analysis techniques..

Those models are lifecycles and pertain to the order and process an organization follows during development.

In any case, to answer thos, I''ve tried talking to people to find the same answer, and then some other answers, regarding software engineering methodologies (including design/analysis, processes, planning, management, architecture, etc). What I''m finding is that nobody can give me a straight answer to anything related to software engineering in the gaming industry. Well, one person has told me how it is, but he''s an exception.

IMO, this is a problem of the industry. I know it''s not limited to the game industry, but if the game industry wants to start maturing like the rest of the software industry is starting to, it needs to look into some SE methodologies and techniques.

Kevin

I feel every program that serves a useful purpose has a design. The only real question is whether it is in the code or in a seperate document. That is assuming it wasn''t created through shear chance by having a monkey type randomly on a keyboard

I detect a bit of disillusionment in someone. The best advice I can give is that when you have problems that a methodology could solve, but no methodology it is a management problem. It isn''t enough to simply declare that we have a methodology. Rather it needs to be applied. The goal is really to prevent mistakes. It is a means to an end. It is easy to lose sight of that. A design document might help a programmer to work out the design, but a more important purpose is to make sure he writes the right program. Who needs he said, she said, we said, they all said. I don''t care whether it is technical, functional, a project proposal or a post-implementation review. The ultimate goal is to prevent mistakes and when you fail at that to track down what went wrong so that you can prevent it from happening again. Remembering who said what three months ago is a joke.

The ONE thing that has pissed me off for centuries is "why is there so much source code out there and so VERY VERY VERY little documentation". source to me is USElEss, i don''t want to sift through pages of code to find out what a function does, I want to flip to a page and say "ahhhh so that''s what it does and owwwhhh that''s how it does it". I wanna create an open documentation standard. I''m gonna give away my documentation to my Brix! as an example, should show people what they should have before they even start coding.

What I''ve been finding is that nobody seems to have a defined development process that they follow. If they do, they''re not telling. The processes that a developer uses to go about doing things is just as important as, say, documenting the design. Just look at the Capability Maturity Model..

If you can''t go about doing things effectively, then how are you supposed to develop an effective product? I again am interested in what process people follow. I''ve yet to get a straight answer.

Kevin

Requirements Analysis
Research
Proof of Concept
Business Proposal
Design
Implement
Document
Sell

Well I''m more interested in the gaming industry processes.

Kevin

There is only one book i''ve ever read which directly discusses game development from a non-programming point of view. it''s called "game architechture and design" by Andrew Rollings et. al. publish by Coriolis, this is the book in my opinion people should be reading before jumping into starting a game. It discusses the processes, very insightful. I disagree with some of Rolling''s methods and techniques but still they''re very useful.
Personally I prefer the evolutionary maturity model, things are always changing.

Khawk, interested in writing a process fit for games?

I have GA&D as well, but there are certain things I don''t think he goes into enough detail about regarding this topic. I would recommend it to someone who is new to the topic and just trying to get an idea of where to start.

As for writing a process fit for game development...that''s why I''ve been asking known game developers for the processes that their companies use. Unfortunately, it doesn''t seem to extend beyond a little bit of planning to get a schedule, the game''s main design (while programmers develop tools), a little bit of high level design, and then jump in for implementation. There seems to be some unit testing going on, as well, along with the periodic system-wide build. This is just a general overview, though. I haven''t found anyone (yet) that incorporates risk management and some sort of size estimation (to estimate effort), among other things.

Kevin