Foundational Principle #12 – Speed Matters

We interrupt your normal Mark-a-thon for a post from Andrew. I’m the technical director and co-founder of City State Entertainment, and while I normally prefer writing in C++ (and HLSL, and C#, and JavaScript, and three dialects of assembly language, and occasionally some F#…), Mark’s lured me out into the sunlight to write about Camelot Unchained. Let’s hope I don’t burst into flames.

Today I want to talk about graphics, and gameplay, and performance. They’re all connected, so it’s hard to talk about any one of them in isolation — and if you do, you’ll end up rendering yourself into a corner. Everyone wants all three, all the time, but what happens when you have to choose?

It all starts with gameplay, but what does “gameplay” really mean? For some games, the graphics are the core of the gameplay. For those games, the thrill is exploring a gorgeously rendered, immersive new world. You may compromise on performance to create that, but for some people, tuning their system for the best possible experience becomes its own meta-game. You may compromise on certain aspects of gameplay — precomputing the world’s lighting gives you a prettier world and better performance, but to lock down the world’s lighting you have to lock down all the objects in the world. But if the main hook of a game is how pretty it looks, that’s all fine. I’ve played games for how beautiful they were, and I’ve enjoyed every perfect hand-crafted scene around every new corner. There’s not a tradeoff between graphics and gameplay when the graphics are the gameplay.

On the other hand, for technology purposes Camelot Unchained’s gameplay pitch is simple: a whole lot of player-controlled characters, interacting together in a world that they affect dynamically. Performance is the primary pillar supporting that — but rather than going for the highest frame rate, our benchmark is the number of players on-screen while running smoothly at our target frame rate. Gameplay and Performance are the two top-level goals of the engineering team, and if we achieve them, we’re good.

But unlike a Big-Publisher game, we don’t have pressure to look good in order to be good. It’s the other way around. That’s not to say we want to look bad! We’ve got a great art team here at City State, and triangle for triangle they can pack more style and personality into a model than just about anyone. But when it comes down to the sheer number of those triangles, any time we have to choose between that and delivering on our core gameplay, we’re going to choose the gameplay. That requires certain sacrifices. Every scene has to support the possibility that a few hundred of your friends might show up there, even if they usually won’t. We know that we’re building a world for characters to live in, not a theme park for tourists to visit.

We may not get as many tourists on opening day if we’re not the shiniest park around. The trouble with tourists, though, is that when they’re done with their tour they go home — or on to the next shiny thing. We want to create something here that lasts, and that means we’re catering to the kind of players who’ll stick around. No matter how good a game’s graphics are, after you’ve seen them a hundred times you get used to them. The thing that matters after that is whether you’re having a fun experience. For us, a good experience means running really, really well with a lot of players in a battle. It also means allowing the world to change in ways we didn’t exactly plan, as players homestead on the frontier or open shops in a capital city.

There’s one advantage we get from our small size, too. Because we’re not starting with a fully-staffed MMO-size art team, we don’t have to find a use for a dozens of artists from day one. That’s happened to me before; the end result was a game that had environments built before we knew exactly what our gameplay was or what the performance requirements of that gameplay were. Here we’re building gameplay first. If you’re in one of our Alpha-access Kickstarter tiers, the very first technology demo/preview release is going to have some seriously sparse environments. Depending on how early we open it up, it may even take place on a flat grass-colored plane. At that stage, we (and hopefully you) will be concentrating on perfecting our combat mechanics first. Once we let artists loose to build out the world, we’ll have that gameplay as a baseline. We’ll know how much headroom is left, and what lines we need to stay inside to preserve that gameplay — always. It’s easier to win the race when you’re starting ahead instead of behind.

Over the next few weeks I’ll be writing more about the tech plans for Camelot Unchained, both the things we’re bringing in from outside and the special bits we’re going to make in-house. But the one thing that’ll remain constant is the focus on what players need to turn the world we made into a home for themselves.


Next up : Foundational Principle #13 – Chaos Goes Boing!