Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun
View All     RSS
June 14, 2021
arrowPress Releases
June 14, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun


August 6, 2009 Article Start Previous Page 2 of 5 Next
 

Manage Requirements

Many projects fail simply because the system solves the wrong problem, meaning that 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 fundamental to 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.

It is however important to stress that in an iterative project there is no dedicated "requirements phase". Neither does there exist a set of people (separate from the developers) which handles the requirements management tasks. Such a division is bound to create requirements that are never read or understood by the developers actually responsible for building the game. Instead, requirements management is an almost daily task for every team member.

Traditional Requirements Management

In traditional game development requirements come from the (lead) game designer, 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. The consequence of realizing this is that the big bible game design document is a waste of time and resources and a more lightweight and agile approach is needed.

Iterative Requirements Management

Typically the game designer evaluates the latest iteration together with the 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, as opposed to being completed before production actually begins. In essence we suggest the game designer move 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.

Prioritization of the "Requirement Backlog"

As a typical project starts off with more requirements and feature requests than can be implement during a single iteration, a "backlog" of requirements immediately exists at the end of the first iteration. Also, the evaluation of each iteration will invariably invalidate or change existing requirements, as well as creating new ones.

In our experience a good prioritization of this ever increasing "pile" of requirements is critical to the quality of the game. This is because most of the time you are in a situation where there a far more requirements than there is time to implement, given the entire project time frame and budget. As a result, it is critical that the most important requirements get done first; ordering is significant.

This kind of prioritization (as is that of any significant "to-do" list) is a daunting task without good tool support, but nevertheless one of the most important tasks faced by the project leaders and game designers. Constant intelligent prioritization of requirements, based on customer expectations and risk, is a must if a quality game is to be created.

Vision

At the foundation of iterative requirement management is the game vision. The vision is a short but information packed artifact focusing on the whats, whys and whos of the game. The vision answers questions: what the game is about, what the player actually does most of the time, why the player is doing these things, what the surrounding game universe is, what feelings the game should convey to the player, etc. These are described as top-level features. All other requirements are meant to support one or several of these features, creating a logical hierarchy.

As the vision is a very short artifact it can easily be read and understood by everyone on the team. It should be a major focus of the early iterations to establish a shared vision of the project. Everyone from business to development must have a clear, shared and unambiguous vision of the project. Failing to establish a concise vision is a sure sign that the project should be reevaluated and possibly even canceled as it is simply too unfocused, and hence risky, to continue.

Quality Requirements

Quality requirements have special weight in the vision. Games are especially ripe with interesting quality requirements. Not only technical quality requirements like performance and platform independence, but in particular softer, more intangible quality requirements like fun-factor, replayability, and feelings of the player should play a major part. In the book 'A Theory of Fun for Game Design' Raph Koster describes a number of fun-factors to be considered. In a recent Gamasutra feature, Tom Hammersley also discusses quality requirements in the context of games.

Business and Organizational Goals

It is also important that the organization has a clear picture of what business goals the game has. This can be described in various ways from units sold for a given period of time, net income, and other economical measurements. It can also be focused towards business development. A new developer could for example have a business goal of getting the game published by a certain set of publishers, getting a certain amount of media coverage or getting a certain minimum review score. Thirdly, you can also have organizational goals, like introducing a new technology or project practice; like learning to work truly iteratively.

Business and organization goals form high level evaluation criteria for the project.

User Personas

It is very important to have a clear picture of who the person playing the game actually is. You should form one or several personas and look into questions like; when is the game played, where is the game played, for how long is the game played, is the game played together with friends, family, kids, spouse etc., what other games does the persona play, why does the persona play games. You should dig as deep as possible and not only answer basic questions like gender, age and level of education.

Getting into the head of your gamer and having a clear unambiguous vision will make it easier to evaluate high level changes and requirements by simply deciding if they support the vision and goals of your personas. Investigating personas carefully could also yield business opportunities where you can find niches that are not addressed by current products. For example:

"a real-time strategy game played at the office on lunch breaks in ten minute sessions..."


Article Start Previous Page 2 of 5 Next

Related Jobs

Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Programmer
Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Senior Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

Technical Artist - Pipeline





Loading Comments

loader image