Why we built our own tech for our indie game Future Unfolding

We often hear two things from people who see Future Unfolding for the first time: 1) They are surprised that we’re not using Unity. 2) They can’t figure out how we created the look of the game. These two things are directly related to each other.

Unity has become so popular among indie developers, it is often the default choice. However, when you’re using Unity, it’s easy to make a game that looks like it was made in Unity. The tools shape the things we make with them.

For Future Unfolding we decided to custom-build exactly the tech we need to match our creative vision. Our code is written in C/C++. We use OpenGL and SDL2, but everything is setup in a way that we can swap out these libraries with something else (e.g. DirectX) without too much effort. This leaves the door open for us to do ports inhouse. We reused a few parts here and there from our previous game Spirits, so we didn’t have to start completely from scratch.

With our own tech, we can work more efficiently with fewer creative limits, since we don’t have to spend countless hours trying to make an existing engine work the way we want to. Most other game engines are built around the idea of static level geometry and skinned 3D character animations. Everything in Future Unfolding is based on 2D animations. Our code is highly specialized and optimised to render all of the game’s world as dynamic objects in 2.5D. Even the ground is made up of dynamic particles. This is profoundly important for the painted art style of Future Unfolding, which does not rely on 3D geometry for shapes. As a bonus we get to have soft edges everywhere.

The world of Future Unfolding is composed out of thousands of dynamic objects

We sometimes call it a framework instead of an engine because it’s really not something you could give to someone else unless they want to do exactly the same thing: Draw quads in the XY-plane.

If something crashes, we can always debug at the source-code level because it’s our own code. We know from other developers that working around bug and problems in an third-party engine can take up a lot of time and be very frustrating.

Lastly, we don’t need to pay license fees for a game engine.

So, where’s the catch?

The hardest part for us is to figuring out how to get the performance out of OpenGL we need. Because of our unusual art style, we have a huge amount of alpha resulting in expensive overdraw. However, since we only use as little functionality as possible from OpenGL, its makes it easier to finetune and optimize our code.

If you want to roll your own tech, focus on functionality that is specific to the game you’re making. If you end up creating a general-purpose engine, you might have been better off using an existing engine instead. Only add features that you need for your game right now. Don’t implement things that you think you might need in the future. The design of your game and its tech requirements are likely going to change over time.

This is a repost from the Spaces of Play blog.