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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.]
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.
Robertson, S. and Robertson, J. (2006), Mastering the Requirements Process, Addison-Wesley
http://www.12manage.com/methods_kano_customer_satisfaction_model.html
---
Photos by Alexander Boden, Andrew Bossi, and Semi Sweet, used under Creative Commons license.
Read more about:
FeaturesYou May Also Like
