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
Planning For Fun In Game Programming - Part 1
View All     RSS
November 28, 2021
arrowPress Releases
November 28, 2021
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Planning For Fun In Game Programming - Part 1

May 20, 2009 Article Start Page 1 of 3 Next

[From a game programming and planning perspective, how do you legislate for... fun? Veteran game coder Hammersley discusses how you might split game technical planning into 'must-have' features and 'non-functional requirements' that enhance the game's fun factor.]

Development slippage is a key problem in the software industry. This is often because development time is wasted on developing features that are not needed, or attempting to determine what we need whilst we build it.

This is due to insufficient requirements engineering. There is a commonly encountered belief that requirements engineering for games is difficult, if not impossible.

I argue that this is not the case, and that we can succeed in requirements engineering in the games development industry. Requirements engineering provides us the cheapest and most effective way of determining what we need to build, saving development time and cost.

The first part of this article challenges the view that requirements engineering cannot be easily practiced in games development and discusses the surrounding issues; the second part will discuss requirements engineering best practices and how it fits into the development process.

Analysis of the Basic Argument

The common reasons for this belief are:

  • Confusion and misunderstanding between requirements and solutions.
  • The belief that games development is somehow different and incomparable to other industries.
  • You can't write requirements for fun.
  • The features being developed are cutting edge and novel, and are therefore not well understood enough to specify requirements.

I argue that this is not widely the case for a number of reasons.

Confusion Between Requirements and Solutions

Let me describe a typical development scenario. Firstly, the designer writes a detailed specification of the solution to a feature. The programmer attempts to slavishly implement the feature to the letter of that specification.

In doing so, he runs into many problems. He finds it difficult to solve problems that are not addressed by this solution, as only the solution is described, not the solution rationale or original problem.

A lot of time is then spent iterating on and refining the implemented solution. Subsequently, we conclude that requirements engineering is difficult or impractical and we are not convinced of the value.

The mistake we have made is that we have specified a solution, not a requirement. Whilst requirements and solutions appear superficially similar, there is an important difference that we must understand. A requirement states the problem to solve or a need that exists and why it exists; a solution tells us how to go about solving that problem or need.

It can be compelling to write solutions instead of requirements. It is tempting to design a solution to a requirement at the same time as writing the requirement -- especially the interesting ones! Writing solutions feels more authoritative, more formal, more precise and more accurate. But it is counterproductive.

We must ensure that we specify requirements for the features of the game, not solutions to those requirements. We need to specify the essence of the problem we must solve, and why we have to solve it, not a possible solution to it (Robertson & Robertson, p165).

By prescribing a given solution, we preclude any potential superior solutions. Prescribing solutions also limits our understanding of the problem domain and intent of the requirement.

We also rob ourselves of the opportunity to test whether we have solved the original problem; we can merely test whether we have implemented the prescribed solution satisfactorily.

Article Start Page 1 of 3 Next

Related Jobs

Graffiti Games
Graffiti Games — Remote, Remote, Remote

Mid/Senior Producer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior Environment Artist
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Character Artist
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Technical Animator

Loading Comments

loader image