|
[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.
|
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