GAME JOBS
Contents
Digital Bruckheimer: Cameron Brown On Mercenaries 2
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
June 7, 2013
 
Social Point
Senior Game Developer
 
Treyarch / Activision
Senior Environment Artist
 
Sony Computer Entertainment America - Santa Monica
Senior Staff Programmer
 
Sony Computer Entertainment America - Santa Monica
Sr Game Designer
 
Trendy Entertainment
Gameplay Producer
 
Trendy Entertainment
Technical Producer
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
June 7, 2013
 
Post-mortem: Game Oven's Bam fu
 
Tenets of Videodreams, Part 3: Musicality
 
Post Mortem: Minecraft Oakland
 
Free to Play: A Call for Games Lacking Challenge [2]
 
Cracking the Touchscreen Code [4]
spacer
About
spacer Editor-In-Chief:
Kris Graft
Blog Director:
Christian Nutt
Senior Contributing Editor:
Brandon Sheffield
News Editors:
Mike Rose, Kris Ligman
Editors-At-Large:
Leigh Alexander, Chris Morris
Advertising:
Jennifer Sulik
Recruitment:
Gina Gross
Education:
Gillian Crowley
 
Contact Gamasutra
 
Report a Problem
 
Submit News
 
Comment Guidelines
 
Blogging Guidelines
Sponsor
Features
  Digital Bruckheimer: Cameron Brown On Mercenaries 2
by Christian Nutt [Design, Production, Interview, PC, Console/PC, North America]
Post A Comment Share on Twitter Share on Facebook RSS
 
 
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
 
Top Stories

image
How Kinect's brute force strategy could make Xbox One a success
image
Microsoft's official stance on used games for Xbox One
image
Gearbox's Randy Pitchford on games and gun violence
image
Why you can't trade items in MMOs anymore
Comments


none
 
Comment:
 




UBM Tech