The Great Tech Changeover

I promised I’d write about some of our upcoming challenges regarding Chase Ace technology.


Ever since Space Time Foam – in it’s recent incarnation – started working on the new Chase Ace, it was created with engine technology that is not owned by the company. We were using a proprietary rendering engine from a small company, and on top of that was our own scripting engine and a good deal of gameplay code.

As time went on, it became clear that it was – and increasingly would be – problematic that we were not in control of the development path of the core engine tech. The core engine is not primarily developed for games, and we kept having odd and game-specific needs that needed to be catered to.

One thing was clear: This problem would only compound, and we needed to change the tech to something else.
We considered a lot of different options, from switching the entire development to Unity and other reasonably priced engines, to swapping out the rendering engine with Ogre and many other things.
When these talks began, I was sharing office space with Space Time Foam, but was not yet a part of the company. I was often part of the tech discussions, due to my background.

After discussing it for a long time, we came up with a couple of core facts about our tech needs:

We have a relatively limited set of needs for Chase Ace (e.g. we don’t need a fancy character animation system, ragdolls and many other things)
Some of the needs we do have are esoteric and non-negotiable (e.g. we want to be able to create total and utter explosion mayhem without dropping frames)
We would benefit from being able to aggressively optimize our workflow and small toolset towards making this exact game
We want the freedom to bring our games to new platforms
At this point, I was working on finishing my third game on my own cross platform 3D engine. I was making 2D games with it, but the entire engine was originally built to be ported to many platforms, and making 3D games.

Over the course of many talks (over about a year), we ended up deciding that I would join the company and become the core tech guy, and that we’d build my engine into the next generation of Chase Ace tech, owned and developed by Space Time Foam.
Since then, we’ve revisited the decision many times, but it always ends up the same place:

We need to migrate to a new technology base, and the tech needs to be developed and controlled by Space Time Foam.

The history of game development is littered with companies that have killed their own projects by migrating their project to new and (supposedly better) tech.
Daikatana and Duke Nukem Forever are both famously epic disasters in the annals of game project management, and both projects made the insane choice of changing tech multiple times during the projects, practically restarting the project every time.
Because we know many stories like these, and because we are not rookies, we are painfully aware that our decision to change tech has all the unfortunate trademarks of a naive and dangerous decision. But it’s not. It’s the only path that makes sense.
The big difference is that our choice is not about getting a fancier and shinier engine (it’s not, right now) – it’s all about gaining better control of our future development, and being able to move forward much more rapidly. Fortunately, there are also examples in software development lore where this was the kind of decision that made all the difference (the script language PHP, for example, took off ).



So, for the last two months, we’ve been working on two tracks of Chase Ace development.

Track 1: Old Tech
We’ve finished our NDS demo and have a somewhat complete vertical slice of the game on the old tech.
Track 2: New Tech, Codename “Peyote”
We’re pushing the new engine forward to a point where we can start migrating content and game code over to the new engine.
Over the next months, we’ll continue to push the new engine forward, and start making experiments in migrating Chase Ace content onto the new tech base.
It’ll be quite a bit of sideways development, where some parts of the new engine will need to play catch-up to the old engine, and things will generally be in disarray for a while. But when we’re done, we’ll be able to move forward at a much greater pace.

We hope you’ll be patient while we make this transition, and will help us test the new tech when we’re ready.

Karmeck, all the videos essentially will be obsolete, but aren't right now. Ideally the new tech itself shouldn't change the fundamental look very much. Only improve on it by introducing more advanced rendering possibilities.

One of the shortcomings of our existing rendering pipeline is the lack of solid support for modern lighting techniques (using shaders), so the light on all the videos you've seen has been essentially non-existent. Most of them have no lighting, or at best vertex light.

Peyote (codename for the new engine), right now, is equal or worse in the rendering department to the current engine, functionality wise, but it has a lot of other things going for it.

I'm planning to write a brand new shiny DX11 renderer for the engine, entirely based on shaders, so the visuals should suddenly be able to take a giant leap forward.

It'll take a while to get Peyote up to level with the tech we're using now, but we'll let you see how it's going during the development, so you can observe how it closes the gap, and then overtakes the old tech.

I'll write some geeky progress reports on what I'm doing and how it's going now and then.