Disclosure: The organizers of the Siggraph Business Symposium covered part of my expenses to Anaheim. Our coverage remains objective.
Every game company needs a super geek like Scott Cronce. As vice president of technology at Electronic Arts, the publisher of series like the first-person shooter Battlefield and city-builder SimCity, Cronce has to look at the newest technologies and figure out what strategy EA should pursue in terms of spending its own R&D dollars. He has to be a seer, finding the path through the icebergs so that EA doesn’t become the Titanic, blindsided by technological change.
As new platforms emerge and new consoles like the upcoming Microsoft Xbox One and Sony PlayStation 4 debut, Cronce has to evaluate them and advise the executive team about the geek details. Cronce has done this in various tech roles for more than 24 years at EA. He joined in 1988 as technical director in the simulations group and has worked on dozens of games.
We caught up with him at the Siggraph Business Symposium. Here’s an edited transcript of our interview.
GamesBeat: Let’s start with something basic. If you’re a developer, what does a game engine actually do for you?
Scott Cronce: We have two now, Frostbite and Ignite, and they come in various flavors depending on what you’re doing. As a developer, what that means is that you already have something to start with that’s owned by EA. It doesn’t mean you have everything. If you’re trying to stretch that engine beyond what it was intended for, or add a new feature to it, you still have some work to do. But at least you’re building on something that was already successful.
If you were going to do a startup and buy an engine, the one thing I would recommend is that you never buy an engine that hasn’t shipped a game. That proves out everything related to whether the engine works.
GamesBeat: That’s the old lesson that EA got from buying Criterion, right? But that actually did work with some games.
Cronce: That was a tactic that was a bad idea. Don’t try to converge onto an engine during a console transition and make it just the one for the entire company.
Over the years we’ve gone from a game engine per title to two large game engines that are used and supported across the entire company. One for Sports and one for Games. But that has to happen from the strength of the engine.
Above: Scott Cronce
GamesBeat: If you have the engine, are you halfway there?
Cronce: It’s not so much that. What it means is that you have the runtime engine and all the pipelines associated with it. It’s like starting with all the rigging ready to go.
GamesBeat: You set the boundaries of the game by choosing your engine.
Cronce: Right. But at the same time, you can also decide to do something that extends it beyond them. You make sure that’s where you put your engineering dollars. Depending on what that is, it may be a branch from that engine specifically for a genre of games. Or it may be something that will fold back into the main engine so everybody can benefit from that feature.
Cost, of course, is always a consideration. Often that doesn’t mean you’re going to make a cheaper game, though. You’re going to spend the dollars someplace else, on the content in the game itself. That’s a good thing.
The other obvious benefit it that now you have a lot of people who know how to use the same pipeline. If you can get multiple people and teams using the pipeline, you can have a much more fluid movement of people back and forth, with very little startup time.
GamesBeat: A valuable asset, then, becomes something like a team that has worked with an engine before and shipped a game. That’s far more valuable an asset than what startups have.
Cronce: Much more. If you want to speed something up or slow something down, you can do that now. Instead of the normal month or two of startup time—If someone’s done this before on another game team, and you need to get a game out on time or ship it quicker, you have the freedom to add those people to it without the startup time.
GamesBeat: At Sony, Mark Cerny did a backward-looking analysis on the PlayStation 3 and what they learned for the PlayStation 4. He said that the time to prototype had gone from one or two months on the PlayStation to six months or a year with the Cell processor on PS3. Until the prototypes of the console itself shipped, there was no way to get started on games.
Above: PS 4
Cronce: During that last console transition, the trick of being able to just increase the clock speed to get more power didn’t work anymore. Both Sony and Microsoft had to break that cycle if they wanted to have a sub-$500 machine with a lot of power. Intel too, right? We’d hit the heat to performance barrier on the chips. We had to do multiple cores.
The entire industry was going through this at the same time. How do you break up a game, which is typically a very linear processing issue, into multiple CPUs? The Cell was just a little bit further away from what people were used to. It did take us a couple of years to figure out how to properly get performance out of it. That’s the problem everybody had in the last generation of games. It turns out that everybody was going to have to go through it at some point in time.
GamesBeat: He said that this time around, with x86, the tools are out there. Everyone knows how to make PC games already. The time to prototype should be nearly instantaneous. The part before you can start iterating on things has gone away. So his argument is that, theoretically, it’s much easier to make games in this generation. Your starting point may set a very high bar that becomes a difficult game to make, I guess, but your starting point is better than it was before.
Cronce: You’ve got Xbox, PlayStation, PC, and they all have identical x86-style architecture. Wii U is just a little different. That means it’s familiar. I would say it slightly differently than Mark does. It’s not so much that the architecture itself implies that it’s easy to do. It’s just that because everyone has so many years now with multiple cores and with x86 PC architecture, it’s well-known. It’s not this massive learning curve for getting a game engine running on an alien piece of hardware.