game design, code, writing, art and music

English По-русски

Why I'm using my own 3D game engine

In 2017 I created a 3D game engine called YUME and shipped a game with it called Speebot. Today, I am still using the same engine to make my next game.

I originally wrote the engine partly as a learning experience, partly as an experiment. People sometimes ask me why do I keep using it, instead of switching to something popular like Unity or Unreal. I mentioned some of my reasons in the past, but thought that I should write a concise post answering that question.

Efficient workflow

I created my tools to help me design games faster. YUME supports what I call "asset hotloading" - an ability to update and test maps, models, scripts, textures, sounds and other assets while the game is running. This basically means that I can make the game as I'm playing it.

My engine has its own scripting language, which makes designing and testing game scenarios a quick and painless process.

The engine itself is written in Haxe, so when I need to make changes to the code, it only takes a few seconds to rebuild the project.

Great documentation

All the technologies I use are very well documented. There are countless resources and communities centered around OpenGL, Haxe, SDL, C++ and game design in general.

No dependency hell

Game engines are complex software, which understandably have bugs. When a bug in a third-party engine affects the developer, all they can do is report the problem and wait for the engine's creators to fix it. This also applies to any plugins the game might be using.

This is less of a problem with open source engines, which let anyone dive into the source code and fix the bug themselves.

In some cases, upgrading a game engine's version can introduce new problems, which can be very frustrating and painful to deal with.

Easier to debug and modify

Writing a program from scratch results in good understanding of every component. Extending and debugging such programs is much easier than navigating around someone else's code (if that code is even accessible at all).


Most popular engines tend to be universal, which results in a lot of overhead for features that the game doesn't need. This is a design decision that naturally results in bloated code and slower performance.

Developers often dismiss this problem, saying that computer hardware is getting more powerful and thus software optimization is no longer important. I think this mindset is unfortunate.

The current version of YUME is tailored specifically for the game I'm making. Since I only need to focus on the features that my game needs, it ends up outperforming general-use engines in resource consumption. This means I can add more moving stuff to my game levels, and also support older hardware.

No licensing

I don't have to deal with additional licenses, fees, royalties, contracts and terms of service.

I only had to do it once

Aside from bugfixes, improvements and new features, the core of my engine is already there, and I don't need to implement it again. All I do now is create game content. Switching to a different engine at this point would only slow me down.


A project of this complexity is a big engineering challenge. It's pretty satisfying to create and improve a tool that I'm using every day.

Right now I'm close to finishing my second project powered by this engine - a story-driven puzzle adventure game called Phantom Path:

If you like what you see, consider adding Phantom Path to your wishlist on Steam.

There is also a free demo of the game available. Enjoy!

Next Article

Phantom Path release date


Receive a notification on your device whenever there's a new blog post available, in order to:

Follow the development process of my next game.

Get notified of articles about the art and tech of designing games and engines.

Receive updates about changes to my games.

Subscription is free and takes just one click!