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