Have you guys as a studio been trying to develop any studio-wide solutions for core teams or core tech that you can utilize in those cases? Or do you think that building it all per-game, is the right way to go?
SB: Core technology is so interesting, because it's always made so much sense in some ways, and yet it's been the hardest thing to ever really make happen. I've seen it come and go and ebb and flow over my entire career. Core libraries, everyone uses them, and one will go, "No. We're not using that, because it's not exactly right for what we're doing." And then the whole thing kind of falls apart.
It's a challenge to say, "We're going to have a central team that supports Need for Speed and their needs, and then Skate and our needs." That'd be tough, because they're totally different games. You sort of move through open-ended environments, and we always share as much as we can, but I think we've found that we make the best games when we let the teams decide, "What's right for me?"
There's a toolbox, but we don't all need to use a hammer. Maybe a hammer's right for your solution. Maybe I need a saw or a chisel or whatever. But I think when you force people to all use the same tools, you're going to get cookie-cutter games. It's a tough one.
Economically, it makes sense in a lot of ways, but I don't think anyone's perfected the, "Hey, we have the one solution for everybody," thing. Because when you go that way, teams aren't as motivated, because programmers, artists, and everyone wants to create their own stuff. They want to put their own personal stamp on what they do and tailor it to the genre. If it's like, "Here. Use this toolset and make a game around it," then that can be tougher.
That said, if you're making a shooter, I don't think I would go and create all of my own stuff from the ground up, because there's battle-tested stuff out there that gets you up and going right away. So different solutions for different games, I guess.
Do you have a proprietary engine that you've been using?
SB: I guess so. You could call it the Skate engine. It's a whole bunch of harvested technology put together in something that I guess you could call an engine. But we certainly begged, borrowed, or stole wherever we could, because we didn't want to spend more money than we had to making the game.
What I've always said is that you invest in your special sauce. So if physics is your special sauce and that's what's going to make or break your game, and you don't see anything out there that's going to get you to where you want it to be, build it yourself if you have to.
But don't go write your own renderer if there are great renderers out there, and so on and so forth. Pick a couple of things, if you have to, to build yourself, if you know you need it to knock your game out of the park. But then, for everything else, if there's something good out there, take it.
There were technical solutions, to a certain extent, that probably existed at your studio that were broadly applicable to the game that you envisioned at the beginning, I'm guessing. Like open-world stuff had been done by Need for Speed, potentially. I'm just wildly theorizing. There are places where you could and places where you couldn't.
SB: Definitely. There was a lot of stuff out there, and we took it. It was interesting. For almost the first year of Skate, we were a very small team, and I think we honestly only had two programmers that whole time. That forces you to really focus.
When you have two programmers, you'd better really focus. Don't go and write a renderer. We have great rendering technology, so we're not going to worry right now about rendering pixels on a screen. EA's never had a problem rendering pixels on a screen.
However, let's look at the things that we want to do that makes Skate special. And we did look. We looked everywhere for physics. We looked at a lot of different solutions. We looked at Havok and Endorphin and others, and either things are too expensive or they're not quite... if we could've paid a little bit of money and gotten an off-the-shelf solution that was exactly what we needed, we would've done it.
But there wasn't anything that did exactly what we needed it to do, so we built it. But we only built a few new components that really made Skate special. Everything else, we just took. There's lots of good stuff out there, so why rewrite it?