Fast and Light: Meet the Engine - April 3, 2013
Good afternoon from Andrew! Today’s Kickstarter update is a demo of some graphics tech. And it’s pretty neat, but more importantly it’s necessary. I want to talk a little about why that is. There’s a lot of good engine tech out there, so why roll our own?
First, to make something clear: We’re not going doing everything completely from scratch from the ground up! That’s would be, to put it mildly, suicidal. We’re using someone else’s physics engine. We’re using huge chunks of some very familiar open source for our UI. We’re using some industry-standard networking that allow us to run some well-known programs as part of our stack. We’re still evaluating our audio middleware, but we’re definitely using middleware.
So what are the parts that we need to do ourselves? Basically, anything that involves scaling up to a whole lot of players at once. There are a lot of engines out there that can do a great job drawing around 100 characters at once, but then they start to lag. I’ve worked with a bunch of engines and/or middleware pieces, and there’s a common reason for that limit. They’re general-purpose tech. They have a lot of flexibility in what you can do with those 100 characters. The trouble is that every bit of flexibility has a tradeoff. In programming, especially optimized game engine programming, building in flexibility adds a cost in performance. There’s a cost to figuring out what you don’t want to do. There’s a cost to every polymorphic virtual function call just to figure out that “no, we don’t need this thing on this character at this time”. There’s a cost to generic data structures that can represent any custom possibility.
For games with 50-100 characters, that’s the right tradeoff. You can spend that time. Flexibility to do what you need, right out of the box, is worth a millisecond or two every frame. But what happens when you multiply that by 10? We’re not going for 50-100 characters in this game; we want to be EPIC. That was something we struggled with in Warhammer Online, where we inherited a renderering system and licensed someone else’s animation system and used a completely stock effects system. They all had great artist-friendly tools to bring whatever vision you had into the game, but by the time you got 200 characters going at once, the total overhead meant the game wasn’t running nearly as well as I would have liked. As I mentioned in the Foundational Principles, none of the shinies mean anything if the gameplay isn’t slick. We. Can. Do. Better.
What that means for us is that we need something purpose-built. We need tech defined not by all the things it can do, but by what we can leave out for this particular game. Think of it as tossing things overboard to lighten a ship, or taking the back seats out of a race car. We’re going to do one thing, but if that’s the only thing we need to do then we can do it really, really well. One of the other programmers here saw the “Electra 10000” demo and said, “I really want to see the code for that!”
The truth is, there’s almost no code to see. But the code that’s there is the right code. It’s a small, clean, straight line that does exactly what’s needed and absolutely no more. That’s part of why it’s feasible to do this ourselves. We don’t need to spend months writing hundreds of thousands of lines of flexible code. We have a clear vision of what we are and aren’t using for this game, and we just need a few smart people to write the little bit of code that we’ll actually use. I’ve spent enough years doing this, and learned enough about the right (and wrong!) ways to put those things together, that I believe we can do that.
But that’s a bold statement to make, so we also made a demo and a video to prove it. There’ll be more of these to come over the next month.