Summer is ending, and to start things off here comes the third best practice of software engieering, as always with a game development point of view. I will try to get the rest of the article out there at a somewhat higher pace now I hope

Manage Requirements

Many projects fail simply because the system solves the wrong problem, when the software is finally delivered it fails to provide any benefit to the customer. Requirements need to be collected, analyzed, documented, tracked and organized. This is a fundament of any organization wishing to deliver on time and within budget. Good requirements should be a major driving force behind the project. Requirements need to be handled with care and respect. Failing to do this means almost certain project failure, even if all other practices are observed and practiced.

In game development the requirements come from the game designer, traditionally described in a big bible called the "game design document". This is the same as the "grocery lists" of old time software development and will almost certainly not produce a fun game. The "fun-ness" of a game is something that is very hard to nail down completely on a piece of paper, you simply need a working game to be able to evaluate, iterate and refine the requirements.

Typically the game designer evaluates the latest iteration, optimally using real customer feedback but at the very least with a focus group. This yields a number of new requirements, requirements that are no longer needed, requirements that need to be altered. Ideally these are put in a tool and then prioritized, analyzed, etc in the beginning of the iteration. This also means that the game design is finished when the project is ended and the game is shipped. In essence the game designer moves away from having the role of the "game creator" using a word processor or spreadsheet, to becoming the person that makes sure that the project gets sufficient feedback from the iterations to be able to move in the right direction.

To be continued...