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
http://www.12manage.com/methods_kano_customer_satisfaction_model.html
---
Photos by Alexander Boden, Andrew Bossi, and Semi Sweet, used under Creative Commons license.
|
Printer-Friendly Version
This has some really good observations on what a programmer can/should contribute to the design of a game. Many designers see programmers as a means to implement their ideas, rather than a means to find the best WAY to implement their ideas.
The underlying point that Tom gets across very well is that collaborative effort leads to the correct solution, instead of the first solution.
Starting with a solution instantly cuts off opportunities to explore what might have been better solutions. So insuring that your customer -- often a system designer -- sticks to specifying the "what" (including budget and time) while leaving the "how" to the programming team is a sound principle.
I'd also like to suggest that there's an important corollary to this principle: never expose data internals to the customer unless you expect that you will never change those internals.
Beyond the obvious security concern, the moment customers are allowed to see an internal data element, they will begin to depend on it always being there. Any exposed data element becomes untouchable, preventing you from considering new and improved ways to implement the internals of that system. This makes it much more expensive to change any system of which that data element is a part.
As long as the back-end internals are not exposed, programmers have the freedom to modify or even replace them completely while maintaining the front-end behaviors that are visible to the customer. Keeping internals invisible to the customer thus helps them focus on the "whats" -- the forms and functions -- when writing new requirements, rather than on the internal "hows."
Of course no one every hits 100% on this stuff. There's always some overlap between design and programming, particularly in smaller studios. But it's been my experience that distinguishing "whats" from "hows" helps both designers and programmers focus on what each is best at doing, getting maximum value from the developers in those roles.
What Mr. Hammersley seems to be saying is that the lead designer of an RTS should say, for instance, "Each faction should have a cost-effective way of countering airplanes" instead of what they currently do, which is to specify the list of units that each faction has. And then assume the programmer will figure out whether it is best to give one side anti-air fighter jets and another side a special "kill fighters in area" spell.
Well, that's obviously ridiculous. First off, it's not just a programming problem -- art and audio and level designers need to know which solution to the "countering airplanes" problem we are going to use. Moreover, the programmer has no more idea (probably less) than the designer in terms of which solution is going to be fun. And this is making the programmer into a designer.
Now, I don't think that's what Mr. Hammersley really means. But that is what he says -- designers should only focus on requirements and problems, not solutions to those problems. Unfortunately, that's what 90% pf design *IS* -- finding solutions to gameplay problems. To simply issue a blanket "designers shouldn't try to find solutions to problems" is vastly overreaching.
I'm sorry, but I think he needs to revisit this a bit and try to be clearer about what problems he thinks should and should not be solved by design (or art or audio or...)
I think Damion Schubert, speaking at the GDC a few years back, had an excellent speech on creating useful documentation and systems design requirements, a lot of those points being echoed here, and I agree whole-heartedly. But again, more examples would be greatly appreciated.
On the rest of the thread:
Ian - the user story for the designer might be 'As a Designer, I need to be able to control the fire rate, bullet power, movement speed...(etc) for the wheeled, ground-based AA cannons' - so you ask for what you need. Don't worry, with this system you should have more control over what you need, not less. The old school way of doing it is to write out loads of stats tables into design documents that you have no way of telling will work or not until you try them in the game.
B N - programmers should definitely play more games. : ) At our company, we've tried to make it as easy as possible for them to do so both at work and in their own time. It's worth making the investment.
The only real requirement for a business is "Make Money". Every thing after that is the solution to a problem. "How do we make money? Build an RTS" "What kind of RTS? A fun RTS." "How do we make the RTS fun? Make it balanced." etc. etc. etc.
So you are always being handed "solutions to problems". The author seems to object to certain kinds of solutions, but never states which solutions he has problems with.
In addition to specifying where we draw the line between problem spec and implementation spec I think it's just as important to make sure that all parties understand where this line is drawn. If the programmer is expecting a very tight spec and receives one that is open to interpretation it might seem vague and sloppy from his point of view. Similarly, a designer who delivers a very tight spec might get very annoyed when the programmer starts interpreting it in ways he hadn't intended.
I completely agree that tools development shouldn't be any different from development in other industries. This is perhaps hampered by the fact that tools development is often distributed throughout a team, meaning that programmers switch between working on tools and the game, and will use much the same mindset for both. Dedicated tools programmers ftw.
I think that is a fair middle-of-the-road compromise between the two schools of thought. I feel game development should be created in a modular way of thinking. Which allows for changes without becoming very expensive unless you are changing a basic principle of the original concept.
First thing: design vs. requirements. I think the key thing here is that requirements and design aren’t exclusive processes but rather they’re intertwined, complementary processes. Requirements formulate the problems we want to solve and the design goals, constraints and fit criteria for those problems. The design and/or programming processes follow on from this and produce specific solutions to solve the problems and achieve the desired outcomes.
I think the issue is that at the moment, we tend to practice this process quite implicitly. We mix the processes together, but we only keep the design – the solution. But we don’t have a record of what the motivating problems were. We don’t capture that knowledge explicitly – or it’s fragmented amongst several individuals. Requirements engineering can fill that gap. At a hierarchy of levels, we’d have descriptions of the problems and design goals we’re aiming to satisfy, the rationale for those, and the fit criterion for them to measure whether we’ve solved them.
We can see how these requirements fit together with others to achieve a particular goal. For each piece of implemented functionality, we could trace back where it came from, what it was attempting to solve and why it needs to do certain things. If we change some functionality, the requirements for those particular parts of functionality can tell us the related pieces of functionality so we can ensure we don’t break those, and of course we can refer back to the original problem and ensure we’re still solving that satisfactorily. It gives us a way to design tests for our solutions – or even test the design itself. It gives a way for later hires to a long-standing team a way to understand the nature and rationale of the product.
Arguably a good design could provide those benefits, but I think rather these issues are different sides of the same coin, and they're worth separating.
I don’t want to preclude or object any kind of design process that provides solutions. I’m trying to argue that there’s nothing about the nature of games development that precludes us from setting out what problems we want to solve and the requirements of a solution first, keeping those artifacts, and then hooking that up to a design process – and that there are benefits to doing so.
Chris and Dirk pick up on some of this – providing illustrations of how programmers, when implementing a solution, need to know and understand the original problem we’re trying to solve and the rationale of why and how we’re solving that problem.
Regarding user stories: this article was designed as two parts. Part 1, which gamasutra have published, was intended as an essay on the subject of requirements engineering in games, whether it is possible, and whether there is anything intrinsic in the nature of games that prevents it. I wanted to try and open the debate on the subject. The second part discusses some of the particular practices, such as user stories, and others, to implement this process.
Cheers
I've always been stunned at the general cluelessness of devleopers themselves and why publishers haven't figured out that they are doing engineering, and the worst thing they could possibly do is merely have dev teams pump out games, they specifically need people working R&D and developing prototypes constantly to find the solutions so that when the next big game comes around, it's already a well worn path and well understood.