Requirements Analysis

I think because of the set hardware that development may go smoother. Companies tend to follow the pattern of preliminary graphical games, games with acceptable graphics, then last generation games that blow the mind, before the next system releases. Industry wise I think it's not any harder to develop for a game than to make application software. Especially with all the middleware companies have access to nowadays. Non game-development companies worry about ease-of-use and accessibility. Game development companies worry about entertainment and replay value. I think (from my limited knowledge) they are equal if not proportional to the amount of work done on a program.

Design requirements typically are handled when a feature is implemented. Part of the requirement specification should be the expected lifetime of a feature/implementation.

Depending on the company/individual, a feature which is title specific and easy to remove or replace probably does not need as much design as something meant to last several revs, so we may want to talk about what requirements are.

As an AI programmer, my requirements come from my level designers (who will be making use of most of my features), my animators (who are also clients -- and who are also producers for level designers), my game designer (who needs particular rules implemented) and my fellow engineers (who have memory use/performance/sytem dependency) issues.

Now, these people are going to be working with the systems I produce for at least 1 year, possibly longer. They will want changes over time, but they do have an initial idea of what they want to see. Requirements gathering is critical as it hopefully makes everyone thing about what they really want before anything is implemented. Change afterwards is fine, but that first implementation may lock out particular extensions.

If you can identify the areas likely to change, you can take them into account in design. This doesn't mean everything needs to be implemented/virtual/totally dynamic. The goal is to simply avoid design/implementation decisions which may bite you later.

Okay, time to get to work. Hopefully others have thoughts, as this is an area which is becoming more important as teams grow and games become more complex.

You pretty much have to fix your requirements and complete your project. Even if requirements don't change you still have to deal with changes as a result of coming up with better ways to do something. Most non-trivial software is thus evolutionary.

As long as information technology is treated as a competitive weapon by business then the non-entertainment software industry will have to contend with rapidly changing requirements. As long as multimedia technology is treated as a competitive weapon by game companies then the entertainment software industry will have to contend with rapidly changing requirements. In either world it's a good problem to have since the alternative is stagnation in a non-competitive economy.

I'm a bit odd in that I'm relatively new to the game development biz having spent the previous 15 years in non-entertainment software development. I've found that both industries deal with change management in different ways. In the non-entertainment biz rapid change is often (mis)handled by under-delivering product, either by delayed release or low quality or both, leaving a trail of dissatisfied customers. In the game biz rapid change is often (mis)handled by burning up the talent, resulting in bitterness and distrust among its hardest-working employees.

All said I don't know which is worse. Neither are healthy to the industries they serve so both ultimately fail the customer. I think the non-entertainment biz could learn a lot about quality and agility from the game biz. On the other hand I think the game biz has some growing up to do with regards to business maturity. At least non-entertainment companies don't chew their own limbs off when trapped by the unexpected.

Thank you seriousi. I have found your recent posts here quite insightful.