Snail Trails | OpenGL | 2018

Snail Trails is a puzzle game made in a custom C++/OpenGL engine. You play as a snail, slow and steady, whilst painting the level in the color of your slime. The snail can’t go onto blocks which isn’t its color, the snail can however change color with the use color change tiles. There are also pressure plates in the levels, which you have to activate while being colored in the same color of the pressure plate.


Snail Trails was a university project in the third quarter of our second year and required the use of a custom C++/OpenGL engine. On top of that the programmers had to provide a custom Lua scripting API for the game designer to use. We were given four weeks of time for development with a team of four designers/artists and two programmers. In this project we tried to keep a simple yet interesting game concept and a handpainted artstyle inspired by Bastion.

Personal contribution

Unity Level Editor

In order to avoid hardcoding the levels into C++ and to enable a parallel workflow, I created a level editor for our game in Unity which would allow our game designers to specify the level mechanics as well as to select and preview models and textures in the editor mode. This was done by creating a couple editor scripts which would allow the designers to build their desired level by modifing individual tiles and placing the environmental models at the wanted positions. Eventually the level could be exported as an .xml file for our custom engine.


C++ Level Importer & Manager

After the game designer had created the levels and provided the needed models and textures I used the library TinyXML to read the level .xml files and generate a fitting instance of the level class in C++. This level instance would store all needed data and load all the speficied models and textures into an object pool so that those can just be reused on demand. I decided to load those levels and models at once at the start of the game and cache them, since we wanted to reduce loading time between levels to a minimum and we had no experience with async operations in C++ yet. After all levels were successfully instantiated, the level manager would allow us to dynamically switch between levels with almost no delay.


Lighting, Dynamic Shadows & Bloom Post Processing

At the start of the project we were unsure whether there was enough time to implement engine build-in lighting, shadows and some post processing effects so we assumed that we had to fake everything by baking lights and shadows into the textures. However we found out soon, that there was enough time for me to experiment a bit with shadow mapping and post processing. Since I already implemented lighting into the engine base before the project started, I tried to add the bloom post processing effect first. After succeeding relatively quickly, I also tried to integrate dynamic shadow mapping into the engine. Luckily I figured it out as well so our designers did not have to bake anything into the textures anymore which also eased their workflow. On top of that it helped me understanding the basics of OpenGL even further.


Audio & UI Lua Scripting API

Another requirement for this project was that the programmers had to provide a Lua scripting API for the game designers to enable a parallel workflow as well. Since we already handled the base mechanics and level creation in my Unity level editor, we decided to make the audio and UI scriptable. To do that I used the stack based Lua C library to push C++ functions to Lua and to call Lua functions in C++. Our game designer then used this API to tie certain sounds to predefined game events as well as to create the whole menu structure and system.