TL;DR
My love affair with the game engines. The story of all the gamers who have become developers, from fantasy to disillusion.
Full story
One upon a time…
My childhood was marked by several of the big names of video games:
If you want to know a little more about their work, go to Fabien Sanglard’s website.
All these creators made me dream and certainly contributed to becoming a developer, motivated by the desire to create games and understand how to do it.
For the record, independent developers became obsolete in the late 1990s with the advent of big game companies, the rise of 3D games and the overwhelming power of this market. This is later than people like Markus Person, Maddy Thorson or Lucas Pope have come back to the fore to offer us these incredible games with unique design.
From a personal point of view, therefore, I started my career as a developer when precisely this profession was no longer viable in video games, it was later, with the experience and the necessary time that I decided try to accomplish this old dream and throw myself into video games programming.
With ideas in mind, I studied the different market engines, behemoths like Unreal Engine, Unity which are powerful but totally oversized for my needs. Simpler engines like LibGDX, ImpactJS or Torque3D, incredible tools but which systematically do not meet all my requirements.
During my various tests, I also noticed my lack of knowledge in the field: OpenGL, entities, sound, physics…
So I decided to start from the beginning, open the hood and build my own engine.
As this post is not intended to tell the history of OpenGL, it is my personal experience, what I learned and understood.
OpenGL from scratch
In order to understand how 3D engines work, I decided to learn OpenGL. The idea being to port my games to mobile, it is therefore with OpenGL 1 that I have started my training (OpenGLES 2 support was limited then).
In my opinion, if this version of the API is totally obsolete today, it is a good entry point to understand how the OpenGL pipeline works, the different steps and especially matrices…
Matrices, my first nightmare!
If the notions of transposed matrix, cross and dot products have remained in a vague memory in your mind and the idea of programming a 3D engine comes to you, ask yourself this first question: Am I motivated enough to redo the entire high school math program?
If so, you will discover the joys of model or projection matrices. The magic of lighting with vector calculations and the hell of OpenGL debugging with endless black screens.
- Lighthouse3d - tutorials and resources,
- learnopengl.com - another set of tutorials,
- NeHe - step by step tutorials,
- Kronos - official OpenGL website.
At the end of this OpenGL 1 self-training, I understood the limits of this API, in particular the heavy programming inherent in the model and especially the scam of extensions. The OpenGL 1 model being so closed, it is this avalanche of non-standardized extensions with approximate support by manufacturers that allows to create advanced effects and optimize your renderings.
I decided to take a look at OpenGL 2 and the shaders. The rupture introduced by this second version is fundamental since it is still used in the latest versions of OpenGL and also in competing APIs like Direct3D. New APIs like Vulkan or Metal (Apple) are trying new approaches but are still little exploited (2020).
OpenGL 2 is the OpenGL 1 pipeline coupled with a new concept: shaders. Shaders are small programs that will define all your geometry and rasterization logic for your models. If you’ve suffered with math in OpenGL, prepare to die with these critters.
The cool part is the flexibility of programming, the power of rendering and the possibilities offered by this technology. I highly recommend you take a look at Shadertoy, an incredible showcase of shaders by great artists and programmers.
In the end, after weeks of training in math, OpenGL 1, OpenGL 2 and shaders (GLSL), it’s a minimalist engine that runs on my Android, the video below shows the few tests I was able to do with it:
When I got there, I realized that the performances were not good enough, the graphical glitches were numerous and the amount of work to achieve a full scene covering all lighting and shadow needs was way too big.
I left this first attempt aside, happy to have learned and understood the basics but aware of my mistake in wanting to start from scratch.
Mixed approach: forking
It was a few years later that the desire to get back to it came with the arrival of the Pixel Art fashion and 2D games.
This time, I put all my knowledge to work, leaving out that damn third dimension that ultimately makes things a little uglier (N64 games, really?).
Based on my first experience, I decided not to start from scratch but to use a proven 2D engine. First trial, choose it, there were many of them and the only way to make the right choice is to test them. Know if you are comfortable with the API, the programming paradigm, check performance, portability, functionalities. Once again, it’s a long job, but also more fun.
In the end, being a Java expert at the time and quite amazed by the performance of LibGDX, I chose this engine. If I can give a good advice to developers who want to code their own game engine, it’s to start from an existing one with an active community, check the quality of the code, fork and add new features.
So it’s a fork of this engine that I used, integrating a library full of potential, LiquidFun (thanks to the work of finnstr), which allowed effects on liquids and soft bodies.
In the end, I did a complete engine refactoring by modifying several aspects and adding features. The video below shows the different possibilities offered by my new version:
My first “game”
It was from this new base that I decided to create my first game: Softbuddy. The idea being to create a puzzle-oriented platform game based on a liquid character. The possibilities offered by LiquidFun allowing me to have a character that can divide, change shape and substance, ideas were arriving in large numbers and it was with a superb intro that I started this AAA:
Technically, it worked. Graphically, for a first try, it was rather encouraging but it was a list of impediments that totally discouraged me in this business.
Level design
If this first screen was motivating, the rest was a struggle. In order to organize myself and prepare the entire game, I decided to write a first storyboard. This task is complex, the writing of the different jigsaw puzzles, the overall consistency and especially making it interesting for the players is a real challenge.
I understood then that it was necessary to proceed step by step, to establish outlines, a framework and to produce screens and puzzles as they went along.
The storyboard is still a work in progress…
Graphical design
The first levels were specified, so I had to produce the graphics resources. Being of a very low level in drawing, it was towards a 3D approach projected on a 2D game that I tried to compensate for my shortcomings. I tested a few tools that are as expensive as they are complex:
- Blender, OK, it’s free but frankly, this interface, I fully respect the work done on this tool but use it is a torture,
- 3DSMax is finally the “PRO” version of Blender, it is powerful, beautiful and totally incomprehensible,
- Maya, a tool that I finally understood, more accessible but still expensive,
- ZBrush, a 2.5D editor, complex to use yet, requiring a powerful machine but quite incredible too.
All of these tools are excellent, powerful, and fitted my needs. I still had to understand that my lack of drawing skills would not be compensated by their usage. Mastering them and producing assets would consume all my time anyway without any real guarantee of results.
Sound design
Sound effects and music. Adapted to my game with a pleasant rendering and without copyright constraint. I knew from the start that this part would be a huge impediment. To be honest, I did not even broach the subject, I had already given up when I started Blender…
Obviously, the creative part of a video game might be more complex than I thought!
Last try: a framework
So, do we give up?
Not really, while the idea of making a game may have remained in the stage of teenage fantasies, my skills as a developer and the experience I gained over the years were not wasted time. On the contrary, it was following the discovery of Golang that I wanted to do a last game engine.
Based on my previous attempts, using existing libraries and frameworks to produce a new game engine written in Go.
The reason is simple, to have fun with the language which offers a real breath of fresh air and to improve my knowledge with it. In addition, the engines available at the time in Go all had a critical issue (lack of portability, missing functionalities, overall quality…).
So I decided to do a real painstaking job, start from an existing base with a good potential G3N, improve portability (Mobile and Web) and add features, try it below (Chrome & Firefox only):
This project motivated the original G3N team to improve the portability of their engine based on my work and the few stars awarded to my Github make up for the time spent reviewing my math basics and struggling with 3D authoring tools:
https://github.com/Thommil/tge
Conclusion
