OOM-Engine – The Making-of

This devlog will be the story of the development of the game engine. It will be split in 2 or maybe 3 devlogs.

At the beginning of the jam I started to check If I couldn’t’ use an existing engine.  Obviously Unity 5 and Unreal Engine 4 were out of race. Actually they generate huge binaries. Game maker was a great candidate but the generated games were still too large. After some researches, I started looking at SDL and SFML. It was not yet satisfactory. In reality these libraries are (in practice) dynamically linked and they have a lot of dependencies (OpenAL, libjepg, libvorbis etc.). The problem is still the same, I can’t have a 2 MB dll with the game. That’s why I decided to create my own game engine for this jam. The hard constraint of 1.44 MB was a good justification to pretend to re-create a game engine.

I decided to use OpenGL 3.3, which is old but supported by most GPUs  and CPUs. I used GLEW to load OpenGL functions and extensions and GLFW3 to create the context and manage the Window. This is not the optimal solution but we don’t have the time to write a top notch engine in only 15 days. I rushed the first render to be able to iterate quickly and efficiently. This is important to visualize things even if the code is not very clean at the beginning. Going to deeply into the architecture without a single render for a week can be dangerous (not enough time for the game for example). The first render ?
A really basic colorful triangle


And after ? A basic 3D cube


Once you can display 3D, you can even add a camera to watch your 3D models from every angles

That’s a good start but there is a terrible lack of movement. We need the ability to transform object in space otherwise it will be difficult to have interactions. I decided to create a class Transform that will store all required information : translation, scale, rotation. This class will be attached to all game objects to describe their transformation in the 3D space. The first implementation of the Transform used Euler angles. This is the naive way to represent an orientation in space. You store 3 components, x, y, z and each of these components store its respective rotation on its own axis. If you want to rotate your object of 90 degrees on the x axis, just add 90 to the x component. Easy to do, pretty straight forward but not sufficient at all. I quickly encountered a lot of issues with this method like the Gimbal lock or imprecision. After some hours struggling with matrices, I ended up to choose quaternions. They are elegant, fast and they are not candidate to the Gimbal lock singularity. I updated the transform class and… working transformations

This is the end of this first part of the making of the engine. Stay tuned for the next part!
Thanks for reading

 

Original post here.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2018 Vincent STEHLY--CALISTO. All Rights Reserved.

Up ↑