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.
[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.
Is Games Development Different to Other Industries?
We frequently encounter the argument that games development
is somehow fundamentally different from mainstream IT development, though it is
often unclear why.
The industry is different, but not to the extent we like to
believe.
Mainstream IT developments typically involve providing a
software solution to a problem in a given real-world domain. There is
frequently some existing work or process that we can study and understand. Even
if we are creating a new product or type of product, we have an established
domain to work in.
The difference in the games industry is that we are aiming
to build products for entertainment purposes. Not only must a product be fit
for purpose but it must be entertaining, too.
Furthermore, we create and invent
the domain we develop for, with only the established practices of a genre to
serve as guidance. Even those titles implementing real world activities such as
sports involve some interpretation and modification of the real-world domain.
But what portion of our development work is spent on
producing entertainment? Games engineering teams typically serve two customers
with wildly varying needs: external retail consumers purchasing the
shrink-wrapped product, and internal developers requiring tools and support.
After all, we do not create entertainment alone; we also construct tools,
processes, architectures, servers and other software to support the final
retail product. And is the development of that software really so different
from mainstream IT fields?
Two Types of Development
We need to understand, differentiate and partition our work
into that which is focused on creating fuzzy, uncertain entertainment software
in an artificial domain, and that which is focused on creating the supporting
infrastructure and tools. The latter is equivalent to the work done in other
industries.
Communication Through Requirements
If we are to build a game constructed from our own ideas, we
need to have a solid, unambiguous, clear method of communicating those ideas
and visions. Developing software to solve real-world needs also needs a means
of communicating the understanding of the real-world domain and the needs of
the users to developers.
Requirements fill this need. Just as requirements can
communicate understanding of a real-world problem domain to developers, they
can communicate a game designer's ideas and vision to a developer.
What About Fun?
Fun is a challenging concept for design and requirements. It
is very difficult to prescribe how to make a feature fun.
Experience may
provide a reasonable guide but is no guarantee. It is very difficult to
describe how to make a feature fun by description of its behavior alone. We
need another dimension.
Functional vs.
Non-functional requirements
To illustrate how we can address this challenge of making
products fun, firstly I want to explain the concepts of functional and
non-functional requirements. Functional requirements describe things that a
product must be able to do, such as a Non-Player Character having the ability
to throw grenades at a player.
Non-functional requirements describe qualities
or properties that the product must have such as ease of use, performance, or
human aspects. They are the characteristics of the implementation, not what the
implementation achieves.
Functional requirements are what a product does, and
non-functional requirements are the way and manner in which the product goes
about doing them (Robertson & Robertson p9).
This separation of "what
we do" versus "how we do it" is key; we can consider multiple
different ways of doing the same thing, each with different characteristics. It
is possible that we can faithfully implement the required functionality, but
fail because we haven't satisfied the non-functional requirements.
I argue that fun is a non-functional requirement, or a
product of non-functional requirements. We want to develop a set of functional
requirements to describe how a feature works, and non-functional requirements
describing how to make that feature fun, or challenging, or easy-to-use.
Clearly we cannot simply state, "This feature must be fun". We can,
however, describe the particular aspects of how a feature works that will make
it fun.
Customer Satisfaction
The second concept I want to discuss is Noriaki Kano's model
of customer satisfaction. This model divides the features of any product and
therefore the requirements into one of three categories:
1. Basic
features. These are features that people expect to be in a product. These
features are not discussed, as they are not considered worth discussion. They
are simply assumed to be present, and of a given quality. Unsatisfactory or
absent basic features fundamentally undermine a customer's satisfaction in a
product.
2. Performance
features. These are features that users understand and care about, and
differentiate a product from its competitors. As these are well-understood and
important, they are frequently discussed. These features contribute to general
customer satisfaction.
3. Excitement
features. These are features that users did not expect or believe possible
to implement. Discovery of these features brings great user satisfaction. As
these features are not expected to be present, and poorly understood, they are
rarely, if ever discussed by users. However, as developers, we still understand
and can document them!
I suggest that when attempting to make a game fun, we are in
some part attempting to create the third class of features.
We frequently
strive to introduce novel features, or push a genre beyond its current limits,
creating experiences the player did not expect. Some dimension of fun is
novelty -- of experiencing things that are new and unfamiliar.
Creating such
features is difficult. There is no established ground to build upon and no
established basis for communication. It is consequently difficult to accurately
specify requirements or design for these features.
But we must be careful not to tar all features with the same
brush. The desire to produce class three features, and the observation that it
is difficult to accurately specify requirements for these features leads us to
apply that thinking throughout the project.
Radical vs. Normal Engineering
In games engineering we seek to push the boundaries of what
is currently possible on our target platforms. We strive to build bigger and
more complex worlds and introduce new ideas and concepts to a genre.
To build these kinds of games and features, we often employ
new or novel implementation techniques. Consequently, these techniques are not
fully understood. It is tempting to conclude that if we do not understand how a
solution works, we cannot develop requirements for it.
However paradoxical as it may sound, we can still fully
specify requirements for these solutions. Whilst we may not fully understand
the novel solution we are implementing, or even know what solution we may
choose, we can still specify what that solution should be able to do, and what
properties it should have.
What we may not be able to do is describe in detail
how this novel solution may work. But that would not be appropriate; we would
be describing a specific solution, rather than the requirements for the
solution. Our goal is to describe what functionality we need to build, and what
that functionality should achieve, not how.
Conclusion
The commonly encountered view has some basis -- but not to
the extent we believe it to be so.
The first observation is that we need division. Games
development is a dichotomy: the development of new, creative features from our
own vision, versus creating tools and processes to support real-world user
work.
Secondly, requirements provide a means of communication. We
need to choose requirements techniques tailored to the type of communication we
are attempting: are we attempting to communicate vision of design, or
understanding of problem domain?
Thirdly we need to think how we are using requirements to
frame our resulting design and implementation. Describing a given feature
requires both functional and non-functional requirements.
There is every reason we can practice successful
requirements engineering for games. Requirements engineering helps us determine
what functionality we need to build to make the best product we can. This can
save us a great deal of otherwise wasted development effort.
The second part of this article discusses how to practice
requirements engineering and how this fits into development.
[The second part of this feature can be found here.]
Acknowledgements
Trevor Williams, Ian Flatt, Jon Attfield and Fred Gill for
reviewing this article and their helpful comments and discussion. Julian
Widdows for interesting and insightful conversation and discussion on this
subject.
References
Robertson, S. and Robertson, J. (2006), Mastering the Requirements Process, Addison-Wesley
