Gamasutra: The Art & Business of Making Gamesspacer
Digital Bruckheimer: Cameron Brown On Mercenaries 2
View All     RSS
March 21, 2018
arrowPress Releases
March 21, 2018
Games Press
View All     RSS

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


Digital Bruckheimer: Cameron Brown On Mercenaries 2

April 17, 2008 Article Start Previous Page 3 of 9 Next

So, one thing you just touched on, briefly, was that you said you spent about a year working on engine and tools and stuff, as you transitioned off of the original Mercenaries.

CB: Yeah, exactly.

Do you have a full home-grown suite? You have your own engine that you're using for this game, and...

CB: Yeah, that's right. We have the Mercs engine for next-gen. We have written it pretty much from scratch, to make this game on next-gen. And we've got a completely upgraded tool chain that was designed to handle the just hair raising number of gigabytes of data that we throw around every day. Frankly, terabytes of data that we throw around at this point.

So yeah, we've got a full home-grown technology suite that runs the game, and has really developed into a really flexible game engine. And that's another part of the interesting stuff for next year: once we ship this game -- which is in the very near future -- it's going to be really interesting to look at this engine and say, "OK, what can we do with this tech? Now that we've invested this time and effort into building it, what's next?"

The nature of Mercs -- I'm not sure how familiar you are with Mercs 1, and the gameplay style of it, but -- it's a very open-ended, very flexible game, that gives the player a lot of options. You've got your flying around, you're blowing stuff up... So, the engine's got a lot of capabilities, so I'm really interested to see where we can take it next.

Are you using it on other projects at Pandemic right now? Or is it specifically Mercs right now?

CB: It's specifically Mercs. The way we work at Pandemic is, we don't do tech sharing in the traditional sense of keeping everyone on the same engine and try and pool the tech.

What we do is, we definitely share tech, but in the sense of branching off, so we have an unannounced title in development that kind of took a drop of our code at an earlier state, and then they've moved forward with it. There has been a little bit of sharing back and forth when it makes sense, but it's not like we have a central tech group and everyone uses that engine, or anything like that. Typically we tailor the technology to the game pretty specifically.

So you think that presents an advantage? Developing technology that supports a specific, let's say game type, rather than...

CB: Yeah, yeah, exactly. Well, you know, the capabilities that a game needs. I think so; that's been my experience. I'm cautious about saying "that's the only way to do it" -- I certainly wouldn't make that claim -- but in my experience, that's been a better way to do it. I think there's a lot of inefficiency around trying to keep that sharing going.

And I think, at the end of the day, what you're trying to do is move pixels in response to what the player wants to do, and I think it's easy to get distracted and really consumed by the principles of technology, and a more theoretical or abstract idea of what you're trying to do.

Whereas, at the end of the day, we're really trying to stay focused on, "It's about the game." There's no point having an engine if you don't have a game that people want to play, and want to buy, and want to enjoy on top of it.

When you branch off with the engine -- when other teams might take and branch -- it's difficult, potentially, to merge back in, if they have tech that they develop, that you might want to use.

CB: Oh yeah, sure. It can be. Yeah, but in my experience -- and again, I want to be really explicit with the caveat that I don't pretend that my experience is necessarily the be-all and end-all -- but in my experience, it's easy to overstate the difficulty of kind of reuniting the technology.

You know, programmers are very smart, and they can usually figure it out, and particularly if the code has the same DNA -- even if, let's say they took a drop nine months or a year ago, fundamentally a lot of the architectural decisions are going to be similar. Things might have changed off of that, but as a general rule, I think it's not too difficult.

Sometimes you've got to be willing to invest weeks or months into reintegrating, but that's still better than starting from scratch and taking years, or potentially spending millions to license the tech, or whatever your other options are.

Article Start Previous Page 3 of 9 Next

Related Jobs

Magic Leap
Magic Leap — Plantation, Florida, United States

Audio Programmer
Sony PlayStation
Sony PlayStation — San Mateo, California, United States

Lead UX Researcher (Games)
Starfall Education Foundation
Starfall Education Foundation — San Francisco, California, United States

Senior Game Designer for Educational Games
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Mission Designer

Loading Comments

loader image