Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Cutting the Long Chain of Change
by Jon Brown on 04/22/10 07:16:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

[Sick and tired of seeing your ideas get butchered? There is a solution, but you'll have to abandon the notion of them being solely your ideas...]

For many of us the process of game design (and I include level design in this) is one where we breathe the initial spark of life into a part of the whole, such as a creature, by specifying everything that needs to be known about it, except the details that other departments can or must contribute.

Once the spec is done, art must take your work and run with it, literally fleshing it out so that the beast can enter the game world. Code has many tiresome tasks, but there's also a considerable amount of craft that goes into making this monster roar and not rank. You can replace the creature in this example with any game element you choose, from a mechanic to a level, a character to a weapon.

Sadly, all too often, this process is somewhat fraught. Design seeks "sign off" from the other two disciplines and once that is gained they hand off the work. It then travels down the line, reaches the end and turns out to be sub-optimal in some way. Fingers are then pointed, work flows are disrupted and all relevant staff, from all departments, gather to figure out how to make the blighter awesome, rather than awful. Everyone sits down, discusses solutions, works out an action plan and, assuming time doesn't run out, makes the creature a compelling part of the game.

The problem here lies entirely in the work flow, and the problems start at the point where the designer places their last full stop and utters "my work here is done". At that point they must court the other departments to sign off on the detailed specification for implementing the game element.

When art and code sign off on something the theory is that they're rubber stamping it, asserting that they think it's something they can create (in the case of art) and implement (in the case of code) in the time available. But there's an assumption in this process that everyone takes the "sign off" seriously enough for it to work, and that simply is not the case.

Sign off was a problem when we all used waterfall methodologies, but it can, potentially, be even less genuine in agile development. With waterfall the sign off process is, notionally at least, taken very seriously and signing off on something is tantamount to scrawling your moniker in blood when Satan pops round for sponsorship - "I'm doing a fun run, everyone else has sponsored me a soul each so far. Yeah, if you can just open a vein and sign there."

It should bind like cheap underwear in hot, humid conditions. Even so, it doesn't work very well; people simply assume they will be able to revisit the broken things again at some point in the future, in epic tracts of post Alpha "bug fixing". But in these agile land there are some that sign off with their scrum fingers crossed behind their back - "Sign off? Yeah, whatever - if I find a problem later I'll just change it, cos I'm agile." This is not a conscious thought process, it's simply a by-product of the methodology. In reality, "sign off" is a flawed notion in agile because it doesn't belong there, it's purely a waterfall concept. 

Once the other departments sign off on a piece of work it's time to advance to the point of genuine separation and hand off your work. This is analogous to being a sea turtle. Working through the night you labour hard in a semi daze, building a nest, laying the eggs, which you then cover with perfect precision. Your offspring formed and packaged for success you are then on your way to other tasks. Your young hatch as perfect little turtles, they are amazing and they run free.

But you have handed them off to the world, you have left them to fend for themselves, and various fates will befall them in the absence of your attention. Some won't even get off the beach. Some will thrive, but these will be few. Some will be killed, often when they are young but some will be quite mature when a grizzly maw cleaves through their shell. Sometimes, the worst fate is reserved for those that are mutilated or perverted.

The next time you see one of these unfortunates they may be dressed in a bellboy uniform and being made to dance for Paris Hilton on a reality TV show. Or their shell may have been scooped of its flesh, polished and used as an ashtray on a luxury yacht. It's not a pretty sight. Some can be saved, but some cannot, for the wounds are too deep and too horrible to look at.

I don't want you to think that designers are innocent in all this, they can be complicit in the problem. When GM attempted to distribute its considerable learning from their their joint venture with Toyota at the NUMMI plant there were problems at every turn. One of these was the feedback of suggestions from the production lines of the various factories back up to the designers, be it of cars, tools, machines, anything.

At GM everyone was used to designing something and then, as Ernie Shaefer describes it, they would "throw it over the wall". Sometimes designers actively refuse to acknowledge suggestions and requests coming back up the line to them, but this is rare and should always be stamped on. However, design doesn't have to be actively obstinate to act like this, it's possible for it to be unresponsive simply because it is busy, diligently working on the next bit of information to throw over the wall. Whatever the reason, the result is always the same, the designs are handed off and any changes that have to be made are done without consultation, and bad decisions are made.

At the end of the long chain of change we get bad results and the remedial fix system must kick into action.

So, if sign offs and hand offs are doomed to fail, how do you proceed? Simple, don't have a sign off process between departments and never, ever hand anything off. Instead, work as a team from the beginning of first jottings, right the way through to the completed implementation and beyond to the tuning and bug fixing.

In the early stages this actually means less work for the designer, as the flow of ideas and definition of structures is much faster in brain storming sessions than it can ever be for one person sat there pondering... hmmm. Problems are solved in the design phase because there are no nasty surprises waiting for art and tech, there can't be, because they're sat right there with the designer, flagging them and felling them at the moment of conception. Any time saved in this gestation process naturally frees up time later, for iteration and fine tuning.

Of course, there will still be problems, but because all departments share ownership then none will ever move to change something without complete consultation of the others, which means that the solutions will be infinitely more robust. Nothing gets thrown over the wall, and no one gets hit on the head by someone else's decision.

In agile development this is called a cross-functional team, but Valve call it a Cabal, and they know what they're talking about. However, you don't need to apply this to building levels, as Valve do, you can apply it to anything which can't be done without support from another discipline. In an ideal world you'll be sat with the other creators, but even if you can't the weight of support for a piece of design that has multiple champions, each from different disciplines, is orders of magnitude more powerful than a lone lobber behind a wall.

I described this process in the second paragraph, but as a common tactic for fixing problems. So why not skip straight to the cross-functional team approach and do the job right the first time around?

You'll save on all the interdepartmental bickering, at least the nonconstructive 50% of it. You'll save time, not just in terms of raw work but in analysis and feedback overheads. You'll save face, because the results are more complete in the first place. And you'll have those liberated resources available to make a better game.


Related Jobs

DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada
[10.22.14]

Analytical Game Designer
University of Texas at Dallas
University of Texas at Dallas — Richardson, Texas, United States
[10.22.14]

Assistant/Associate Prof of Game Studies
Avalanche Studios
Avalanche Studios — New York, New York, United States
[10.22.14]

UI Artist/Designer
Bohemia Interactive Simulations
Bohemia Interactive Simulations — ORLANDO, Florida, United States
[10.22.14]

Game Designer






Comments


Bart Stewart
profile image
All of that sounds fine. Keeping designers actively involved in the other bits of production work is probably the Right Thing for achieving what they call “strategic alignment.”



The question I have concerns the organizational level *above* strategy: the vision. How does the vision for a game fit into the proposed continuous-design model of game development?



When designers are everywhere, who’s responsible for generating, articulating, and enforcing the single coherent vision of the game experience so that all the strategies generated for producing the game’s core elements reinforce each other and line up with The Vision?



I don’t ask this question in a negative way; it’s meant to be a bit of constructive poking at the concept to see how it adapts.

Jon Brown
profile image
My experience of development is that, although the idea of a singular vision holder is a good one, it's very rare that it's possible to actually have one. There are many reasons for this and I think I'll write a new post on the subject, although it will be a couple of weeks before I post it, so I advocate fostering a group vision. Don't get me wrong, there are all kinds of overheads in this approach but every step towards accomplishing it has productivity dividends.

Bart Stewart
profile image
I'll watch for that, then. Looking forward to it!

Matthew Woodward
profile image
It's probably partly a benefit of comparatively short release cycles, but the basic philosophy I've always stuck to is that, for a given feature, a designer's work is not "done" until the feature has shipped (and even then not always). This means that designers follow their feature the whole way through the production cycle, being on hand at all times to answer questions, fix issues that arise and make sure it stays on track.



This does obviously mean that you can't "finish" work on a given feature nearly so quickly and, in many cases, that you're context switching between different features at different stages of production. However, it also means that you're never in a situation where the feature that ships is a complete surprise to the designer, and it also allows you to write much lighter design docs - when you're there to answer the detail questions face-to-face, writing all the detail out in a doc is frequently wasted effort. As a bonus, this gives you leaner, easier-to-read designs, which programmers are more likely to actually read.



It's not a system without its flaws, obviously, but it does seem to work ok.

britney roberts
profile image
I love this informative data. Sometimes you wonder whatever happened to a source because you don't hear about it anymore. Please keep us in the loop. Thank you.

=======

BRITNEY

mobile phone

Tadhg Kelly
profile image
Conversely, the opposite problem with cross-functional teams is that the team members often have a poor understanding of what's required and no single person on the team wants to take ownership of that for fear of blame. It can very easily cut both ways.



I've come to the conclusion that, whatever methodology is used, what teams actually need is a competent decision-maker. Scrum use the concept of scrum masters in order to get decisions made. Agile development vests it in the product owner. The decision maker takes on the responsibility of making decisions, and in return the team takes on the responsibility of delivering on those decisions.



There are two parts to that: competence and decisiveness. Being decisive on its own but with unreal expectations is no way to get anything done. Likewise, being competent but unable to get clear and choose a path leads to a lot of hesitation and frustration. It is very hard to maintain a realistic perspective, while at the same time pushing for a vision.


none
 
Comment: