In Pursuit of Awesomeness
It has been a while since my last blog post.
Back in 2011, having switched from a custom internal engine to a custom engine, we did have some setbacks during the transition. Especially in light of the fact that, well, the game uses various middleware engines; all of which do various things. And all the content – include the world scenes – had to be ported over.
Our new custom game engine based on Havok Vision (they bought and rebranded Trinigy which we were using) engine, does the brunt work of tying it all together.
Then we tied in Havok AI for exactly what it implies. Havok Physics for all things dynamics related. Sundog’s Silverlining and Triton for all those glorious atmospheric (sky, cloud, light scattering, crepuscular rays etc) and water masses you see in the shots. Iggy for our Flash based UI, SpeedTree for vegetation, RakNet (which we switched to from ReplicaNet due to Trinigy’s built-in support for it) for networking etc. And a bunch of others (e.g. LUA, FMOD) which do various things such as scripting, networking, audio, web etc. Yes – and they all have to work together or else very bad things happen. Very bad things indeed.
Tweaking, customization and performance improvements as always, have been touch and go for the most part. Heck, we had one specific scene, Gulge (the canyon scene) which would make a grown man weep (Nick, my art director, complained enough, though I’m certain that he wept too) in his cornflakes while waiting for it to load. And for a game of this size and which sports such a large seamlessly connected universe, optimization is everything. And it’s a massive game.
A game of this scope, even with the more powerful machines of today, compromises still have to be made. These include areas of visual fidelity, dynamics, scale, scope etc. The art style we chose for the game, while not of very high visual fidelity, works for the game because that sacrifice had to be made in order to retain the scope. You simply cannot have massive worlds like this, in which lots of players are going to exist at any one time, and expect decent results. Especially for a large scale multiplayer game.
To put this into perspective, within the scope of the game, here are all the engine interfaces which exist, and which have to work with each other seamlessly.
- First person perspective. This allows you to walk around on the planet, inside stations etc. This also includes the various animations, all of which have to be tweaked for each of the ten characters in the game. They also have to match the weapons, items etc. Think about this: this is pretty much an entire fps game all by itself. Here, it’s just part of a sub-set within a larger game engine.
- Player character physics, inventory and weapons handling. There are over 40 weapons in the game, and over a dozen attachments for some of them.
- Vehicle physics and dynamics. All the vehicles have to be done, tested etc. Things like vehicles getting stuck in the world etc. Some vehicles have weapons which have to be setup, tested etc. There are 14 vehicles in the game.
- Aircraft physics and dynamics for both space and planetary flight. Same thing as vehicles. There are 21 aircraft in the game.
- Space Traversal Engine. This is the world (scene) in space which contains the planets, stations, asteroid belts etc. The game engine has to render the entire thing – in real time – and update it for every single player in the game world, regardless of where they are in it.
- Planetary Traversal Engine. Similar to the STE, this is for the planet. And it’s even more complex because we’re dealing with terrain surfaces that have air, ground, water masses – all of which have to be rendered and handled as players, vehicles, aircraft, weapons fire, all move across it.
- Interior Rendering Engine. Again, this is a completely separate interface that deals with interiors. When you run around inside stations, the carrier, this is what handles that.
- Then for autonomous assets (orbital defense systems, planetary defense systems, androids), Havok AI has to be plugged in to handle things like pathfinding, state machines etc. And those path meshes have to be generated manually for each of the four planetary bases, four stations, one carrier.
All of the above are just the most important and prominent interfaces. I don’t even have to point out things like weapon, explosions and atmospheric effects, damage and state handling, communications, UI interfaces, cockpits etc.
Critical to all of the above, the server has to keep track of a game world consisting of thirteen (4 planetary bases on 1 populated planet, 4 space regions, 4 stations, 1 multi-deck carrier) regions – all of which have to be updated in real-time for all clients connected to a server cluster. In contrast, the previous Battlecruiser / Universal Combat games, have a world with over 140 space regions, containing over 250 planets and moons – all updated in real-time.
In a game whereby, at any moment in time players could be in space flying around in combat, inside a station or carrier doing combat, on a planet flying, driving, swimming, running around etc – all the while probably in active combat, keeping it all in sync is monumental, and not trivial.
That’s the game we’re building. And there are only seven (including myself) of us on the core permanent team. We were over a dozen at one point during asset creation when I had contractors building stuff.
It is my hope that the compromises made, and the decision to scrap our internal engines and go with off-the-shelf solutions in building our own custom game engine, pans out in the coming years to the game’s final release.
Additional reading on the game’s engine, visual art style etc