GDC08: Building a successful production process

Summary

Speaker: Lesley Matthieson, High Impact

I didn’t find this talk at all useful, not because it was badly given (it wasn’t) but because the speaker seemed to be coming from such a rarefied environment that the ideas and suggestions would only work for a narrow set of people/projects that didn’t include me.

Also, I was hoping for a talk about good things to do in your production process, maybe even get a clear, concise plan – perhaps compare and contrast different production processes.

What we got was a talk vaguely documenting what a small studio does, and glossing over the problems that their practices would cause, rarely giving any more concrete justification for their approach than “it works for us”. The speaker was fluent and entertaining, but the content was unstructured, jumped around a lot, and didn’t cover anything I would call actual production process (everything they do is just a variation on “let programmers do all the design work” and “talk to people instead of having formal process”).

Sounds to me like High Impact is a nice studio to work at, a very sociable and friendly place, and the perfect place for programmers who are frustrated game-designers ;), as they get to do a lot of the work that is normally done by game designers in other companies. I’m not sure if that’s good or bad, but it isn’t what I was expecting to learn from the title and topic description.

My own commentary in [ square brackets ], any mistakes/misunderstandings my own fault :).

Introduction

Your production process absolutely affects your design process and in fact every head of department needs to be involved in making sure its good.

Ratchet and Clank (PSP)

Started with no technology, tools, code, ec. Only some art assets: models, aniumations, sounds. No build tools, no pipeline stuff. Timeline from start to gold master was approx 18 months.

1 project manager / 3 x design / 16 x art / 15 x code / 1 x tester / 1 x office-manager

Asked all incoming gameplay programmers to draw a gopher. This tested the flexibility of the person – would they outright refuse, or have a go even if terrible? We aim to hire lead designers who are planners. Ideal designer has a perfect balance of left and right brain.

Boyd-cycles

the dominance of flexibility, the ability to change and adapt to any given incoming (changing) situation. Observe > orient > decide > act > … Observe.

Game-version: Observe > Analyze > Decide > Implement

Better tools lead to more iteration, and hence better game. Ultimately, the speed of the tools fundamentally caps the effective productivity rate of all your talent.

Focussed on making sure no-one can end up delaying other people from doing work

From military research: anyone who has some extra knowledge of the overarching plan, the higher-level planning of the rank or two ranks above them, tends to make better decisions at their own level, because they know the context.

Gameplay tests help hugely with scheduling: they provide an intermediary deadline that demands much more honest, accurately-close-to-gold, code/art/design. Also, knowing that people are going to see what they’ve done makes people work harder.

[Adam: I suspect this partiularly makes people start to mentally integrate their own work into the bigger picture, so for poor teams who struggle and omit things that are blatantly necessary as part of the overall picture get a major helping hand with thinking in a holistic way, at least temporarily]

QA and testers shouldn’t be your primary playtesters day to day, it should be the designers. So, take work away from your designers so they have time for this.

e.g. Level designers design initially a printed paper top-down map for each level. Then artists do the actual construction. What the designers are NOT doing is hacking away on their own PC trying to make stuff work while waiting for programmers to improve the tools for them.

Designers should be “Level Producers”.

[Adam: this is old-school game-design: the visionaries making cool designs out of their own heads, complete things. This doesn’t work when you need narrow-focus individuals doing individual parts, especially doesn’t work when you need to scale-up the quantity of work being produced (more levels, greater detail in assets, deeper gameplay, etc). Maybe I’m poisoned by MMO development where the magnitude of what needs to be produced is so great, but it seems to me that High Impact gets away with an awful lot of the things in this talk only because of the small scale of the games they do]

Q: how do you balance things when designers don’t understand how difficult things are to implement?

We just get them to talk to the programmers whenever they have an idea. The programmers also understand that they’re only trying to implement the spirit of what the designer wants.

[Adam: nice idea, and something you should always be trying to do – but as an actual solution to the probable problems, it sucks. Hope is not a strategy.]

Q: Do you have a procedure for accountability for getting work done?

It’s self-obvious who’s responsible for a thing because there’s few enough people working on it that everyone knows who did what.

Every level you work on, you know you’re responsible for making it work well.

Q: PM’s need to ensure balance between art, tech, and design. Did you have problems with bias of the PM’s because your PM is reporting into the design team?

I don’t think PM’s should always report to design, that’s just a feature of our studio, I just think that it’s usually a good way of doing it.

[Adam: this sounds reminiscent of the early days of EA where they claimed aspirationally to blur PM with lead designer?]

The PM at our company doesn’t make any decisions, he’s just a facilitator [i.e. basically an AP]

Q: Did you have stages of development: pre-production, production, final, etc?

Yes. Pre-prod was a first-playable level. Length of pre-prod has varied a lot between projects.

No end-phase though. We go to “Focus-ready” (ready for focus testing). We have some pad-time between that and alpha/beta/gold which is mostly fixing bugs or implementing things involved with gameplay.

Q: how do you handle dropping features as a necessity on the schedule in this creativity-driven project-management?

Well, we’ve never yet had to drop features. We’d probably just sit down and talk about it, and see if we could find shortcuts, negotiate to reduce the volume of work, etc.

[Adam: That strikes me as an extremely revealing answer, both positively and negatively]

Q: what’s the relationship between written and oral communication in your company?

Most of the time people are encouraged to just walk over and talk to each other.

Q: how do you decide what’s implemented by programmer vs. designer?

For the majority, we just assume that a level is being done almost entirely by the programmer. Designers will do tiny easy things sometimes if it’s sure they won’t be going beyond the small complexity stuff they can handle.

Q: who’s hooking up triggers in levels etc?

Pretty much everything that’s happening in a level is done by the programmers.

They work both in code and in level editors, and 3D art packages (maya) etc.

[Adam: Power to the programmers!]

Q: what’s the ratio of number of gameplay programmers to designers?

[didn’t really get the answer to this]

Leave a Reply

Your email address will not be published. Required fields are marked *