Create your own game engine but don't ever use it

Table of Contents

• Introduction
• Benefits of making your own engine
• Why we didn’t use our own engine to create our first game
• Our first published game in Unity
• Conclusion

Introduction

We are the Blind Mystics, a pair of indie game devs from Australia which have been working on starting a (very) small game development business for over 3 years, having published our first game - Lonely Cube (https://www.blindmystics.com/) earlier this year. This is the story behind a year-long attempt at creating a game engine from scratch (within reason).

We began with an idea to create a game engine and a goal to publish a game made with it. With this in mind, our first task was obvious but not simple, create this game engine. Our main consideration at the time was to have the engine support the big three desktop OSes, Windows MacOS and Linux. Our language and OpenGL wrapper of choice ended up being Java/LWGJL (https://www.lwjgl.org/); for reference, this is the same setup which was used by Notch to create Minecraft. We started strong and with the help of various tutorials from LWJGL, we created an efficient rendering engine which could run phenomenally on all three aforementioned desktop OSes as well as Android. We dubbed it ‘Mystic Engine’.

It had all the best features:

• 3D and 2D Graphics
• Interfaces
• Keyboard and mouse input
• Data storage
• Networking

It only took us a year…

Benefits of making your own engine

Now, I wouldn’t say that all this work was a waste of time; in fact, I believe that there were many benefits to this endeavour:

1. If you’ve ever wanted to know what happens behind the scenes of a game engine, this is a great way to do it. We learned about the rendering pipeline, CPU to GPU bottleneck, multi-threading and how graphics are rendered on the GPU.

2. We learned a number of tips & tricks on how to optimize graphics systems for high frame rates. For example, how it is best to render all objects with the same model at once or even combine many objects into one and render only sub sections of the larger model – techniques that are usually already implemented in most game engines and behind the scenes.

3. We learned some fundamental limitations with 3D rendering with real-time graphics pipelines like OpenGL and DirectX. For example, you must render transparent models from back to front and it is literally impossible to render intersecting transparent faces without subdividing them. (Again most existing game engines will take care of this for you).

4. Lastly, we learned which features were most important for us in a game engine – these requirements would later influence our decision to use the Unity Engine.

Here’s some screenshots of games that we started in our game engine, but were abandoned:

“Minecart Game”

A puzzle game for mobile requiring the user to solve puzzles before the mine cart reached them. Failing to solve the puzzle in time would cause the mine cart to crash as it travelled down each level.

“Strongholdaria” A multiplayer game with Dwarf Fortress style gameplay and Terraria style graphics:

Why we didn’t use our own engine to create our first game

After all this work, you might wonder why we dropped it all and moved to a commercial game engine. Although it’s not entirely true that we dropped the engine all together (Discussed later), we have moved most of our development to the Unity Engine. This decision is primarily due to two main problems: high overheads & cross compatibility.

1. High overheads / development time – It took us over a year to create our game engine, and even then, it had only a fraction of the features available in an existing engine such as Unity, Unreal or CryEngine. Each time we wanted to add a new feature for a game, we had to create that feature from scratch. This meant determining where best to factor this into our stack. Once this new feature was finished, it was likely the other prototypes would need to be updated depending on how much rearranging had to be done. We found it took an unreasonable amount of time to get anything done.

2. Cross compatibility – Although by the end of the development of our engine, we had support for Windows, Linux, MacOS and Android. We still lacked iOS and console support which would require an enormous amount of work to implement and quite a lot of maintenance as Java isn’t supported natively, we would have to use at least two languages and different OpenGL wrappers for each. You can imagine as just two devs, this would take a big chunk of our time - drawing out the budget for our games twofold or more.

All in all, it was a great experience to create our own game engine and our team learned a lot about how these enormous systems are designed, but also how costly developing game engines can be. We came to the conclusion that we needed to speed up our development process and moved to the commercial Unity Engine for our first game.

Did anything come from the Game Engine?

At the time of writing, yes… for one of us, and it wasn’t a game.

One of our co-founders participated in the 2016 RobotX competition. To give his team a faster testing environment, he created a simulator for robotic boats (pictured above) which was used by team QUT in the international RobotX competition. The benefit of using our own engine for this task is that it was possible to use 3D rendering techniques for graphics accelerated sensor simulation. It was immensely helpful to have full access to the engine source code to create an efficient simulator. The team used the simulator to great effect and achieved high standing in the competition.

Our first published game in Unity

Lonely Cube is an easy to learn, hard to master puzzle game out now for iOS and Android. Play as the titular cube and make all the tiles in each level disappear before falling into the next level. The game features over 100 levels, many of which are sure to have you pulling your hair out. Keep an eye out for secrets to find some extra content.

Impress your friends and family with your unbounded mental capabilities by playing Lonely Cube today! Drop in at https://www.blindmystics.com for the store links.

Conclusion

Should you create your own game engine from scratch? We’d say that it’s a great experience if you want to expand you knowledge on how game engines work from a fundamental level. When using one of these monolithic pieces of software, it is often helpful to understand the quirks with real-time rendering to understand how best to design your games and graphics to achieve high framerates. Don’t however start creating a game engine with the expectation that it can compete with commercial engines. If an engine exists out there that has all the functionality you desire, it’s probably best to use that instead.

Thanks for reading and happy coding. Come and find us if you have any questions on Facebook and Twitter - @BlindMystics

The Blind Mystics (P3TE and Chootin).