GDC08 Q&A: Bungie’s Chris Butcher

Butcher is one of the five lead engineers that decides technical direction for the newly independent studio – he’s also one if the nine people managing the studio as part of the new partnership the studio established when it returned to independence. Who better to ask, then, about Bungie’s next-gen engine development, what it has learned about team sizes, and how the future of technology means enabling people to be creative.

How has Bungie’s strategy towards technology changed throughout its work on different games platforms and now its move to independence?

Bungie has always invested heavily in technology – our founders are computer scientists, so we’ve had a strong focus on engineering. The interesting thing is that Bungie’s creative side has grown and grown as well, and as game development matures we’re actually capable now of supporting people who are purely creative or artistic, without having to need them have a technical grounding. Back in 1991 or so, everyone on development team would be considered a technologist in some respect. Now we can have pure artists at the studio who’s contribution is purely creative. That means we’re being more specialised now.

But our overall approach to technology has been to invest heavily. We build our own engine – although that’s a position we examine every once in a while – and that investment pays off because the engine you build is designed specifically to get the results you want to achieve.

What interests me about that is that some of the other big first party IPs, such as Gears of War or Crackdown, have been built with middleware, unlike Halo.

Yeah, it’s interesting – you can look at Unreal Engine 3 and see all the work they have done a lot of work in generalising it to make it work across a lot of things, but really it is the Gears of War engine, and it supports a very specific purpose. I think Gears in many ways proves Bungie’s principle in that it has been designed to sit on top of technolgy which has been designed to suit a specific purpose. Now, it’s also very repurposable to other development efforts, but the strategy is similar. I really admire what Epic does, because now they’re supporting something like 150 licensees. Although it’s not a model we’d plan to pursue – but you can really admire it as a technological effort.

You mentioned the diversifying of roles in game development, does that mean new people can get into the industry these days? Could Bungie take on a great artist who didn’t know about games, or a great engineer who didn’t know games that well but was a brilliant computer scientist?

As team sizes grows there’s a pressure towards increasing specialisation, but I’m not a massive fan of specialisation myself – Robert Heinlein once said that ‘specialisation is for insects’. What’s great about game development is that we get to cross-train. So one of the things we look for in an engineer is not pure engineering power but an appreciation for the group effort. It’s ok for someone to be specialised, but we always look at anybody with a view to how they understand if their work fits with everyone else. Because without that you get factionalisation, and then the people who are responsible for holding it together have to run around and work much harder. And if there’s one guiding principle Bungie has it’s that ‘the game is the thing’ – it’s the game that matters, not your technology or the art. There are other ways to show off those things outside of the game itself, like an Art of Halo book for your designs or a GDC talk for the smart way you’re loading data off a disc.

So what was the biggest engineering challenge for Halo 3?

There were a variety. What’s interesting about the game is that it’s this mix of a variety of technological components that come together to make the whole experience. Really serious challenges in loading data off the DVD drive is one thing that jumps out. Halo 2 was all about loading a ton of data off the hard drive, but on the 360 we couldn’t rely on it being there – we’d never shipped a game on a machine that didn’t have a hard drive in it. Halo 3 was our first 360 game, although it arrived in year three of the hardware life cycle. So we we’re trying to catch up a little and had to adapt to the platform much quicker than those who were say working on a launch title and were really making an original Xbox game.

I think it all plays into the bigger issue we faced that which was that game development has gotten so big, with more assets, more technology. But for Bungie we wanted to keep the team as small as we can – it’s really painful for any studio to add more and more and more people just to solve those problems because increasing the number of bodies on a project doesn’t necessarily increase the number of creative ideas you can put into it. Growing team sizes means individual creativity is lessened with every person you add to a project. It was important for us that we didn’t focus on manpower – that’s why we invested so much in tools and pipeline because that meant people had more time to be productive. So really the challenge was coming up with all those force multiplyers as we have so we don’t have to scale up as much.

You’ve seen the team size issue balloon across generations from before Xbox when working on Halo’s original iteration to 360 – can you see a point where the growth of team sizes might slow down or plateau, or will the industry need to accept it’s a requirement as technology progresses and becomes more complex?

It’s very hard to look forward and predict things – but it’s definitely the case that we’re at a bit of a tipping point. There are processes in game development which work for team sizes of up to 30 people. And there are processes that work for team sizes of up to say 80 people. And processes that work for 200 to 300 people. Bungie hasn’t tipped into that last category yet, and it’s only the big teams at EA or Ubisoft, such as The Godfather or Assassin’s Creed team, that have proven they can do it with a sheer number of bodies on a project. And we’re not interested in going there at the moment.

But in the absence of that massive scale of content production there are hard limits on how big a team can get – if you exceed those limits you pay for it in pain, slipped schedules and quality of the final product. It’s just too hard to manage that many creative people focused on one creative vision. That’s one thing I think will curb team sizes a little – even EA has admitted they aren’t interested in big team sizes anymore, because it hits their bottom line. They’ve probably also realised that it has impacted their Metacritic scores as well.

I wonder what the those big publishers think is better: to have 200 people working one year on a game, like with Assassin’s Creed, or 100 people working for two years to finish a title, like with Halo 3? Might there be a correlation that says the latter gets higher review scores – Bungie and people like Valve seem to prove that is the point.

Well, it’s hard to say, and I wouldn’t want to dictate to those teams – I for one played and loved Assassin’s Creed – but I think there is a lot of tension there. And that’s a big focus for our next-gen engine. The number one thing that we are looking at is saying ‘how are we going to be able to scale up for the future?’. Because we don’t want to get into playing the game of increasing staff size to match the decreasing time between releases and the increasing amount of content creation. If you look at what people get for paying sixty bucks for a game, they get more and more content all the time – Halo 3 has way more in it than the first Halo in terms of features, but was released at the same price. That’s only been possible because the industry is growing and growing, but the revenues per game don’t necessarily grow – that’s where all the tension comes from.

We look at that as an independent studio and understand that we have to operate more efficiently; we realise we have to work out how to take something that’s efficient and magnify that efficiency; how are we going to turn around something that is for fast-prototyping; how can we make something that puts the content creators in a situation where they are empowered to create content confidently without having to rely on a bunch of engineers to build the pipeline. All of those are things that we want to solve through technology – because I am a big believer in using the power of technology to aid the creative process. That’s our mandate when it comes to building our internal engine.

And are you working on an engine that will also be investment in other platforms, generations and future games?

Well currently we’re looking at how it worked in Halo 3 and seeing what worked best for us and how it will help our next game – whatever it may be.

There was a great piece in Wired about the intensive playtesting for Halo 3 and user-research – that sounds like a great piece of evidence supporting how the technology has improved the development and the gameplay experience.

Yes, it’s a great example – and that’s come from technology we’ve designed as part of the play testing experience. There are two big technological pieces which make that possible. The first is the ability in the game to make a replay of a game and save it out, play it back, pause it – that lets us analyse player behaviour in great detail.

The other is that in the build of the game – the development build, not the retail version – we have something called data mining and it lets you generate a whole bunch of events from the source code, which you can then run on a server with structured queries against those events. So you can say ‘for this session show me all the user that was playign and show all the data points where they lost health and plot them on a graph’ – because it is all recorded in the database.

So during the development of Halo 3, on a two-weekly timeframe, the designers would great a build every two weeks and track what the ‘fun rating’ of a level is and they can correlate where everyone died and what they died from.

It’s a great example of how single technologies can catalyse he creative process.