Project Summary

Godling is an RTS presenting the struggles of a norse-inspired god.

The sixth game project during my time at The Game Assembly game education school, a genre I have never played; Realtime strategy.
Details on what the game needed to include wasn't that specific, allowing us to create anything from a game like Bastion and Diablo, to Starcraft and other alike RTS games.



  • 16-bit Terrain generation, rendering and creation pipeline
  • Scriptable objectives
  • Terrain Raycasting
  • Player GUI Minimap
  • World scripting editor & implementation
  • Modulation-blending
  • Advanced text rendering with inline text style-tags
  • Game Launcher written in C# .NET

Landscapes o' plenty

My main focus during most of the development was the terrain engine. Together with our level designers, we decided very early we wanted the pipeline to look, to get the terrain that they create into the game.

It was decided that we were to create the basic world in Unity, our level editor of choise, and then export it to WorldMachine, which were to mainly erode the terrain, and create the splatmap for texturing in game. From a programming standpoint it worked well, and I created macro nodes within WorldMachine to make it easier for our level designers to use.

We tried the workflow for a good week or so, but finally felt that there wasn't enough control in that pipeline due to our limited knowledge over WorldMachine and no time to remedy that. We altered our process to skip the WorldMachine erosion entirely and instead focus on getting the tools we wanted in Unity to be able to export the terrains as close to the editor as possible.

Advanced texture blending

During the second iteration of the terrain creation pipeline, about 2 weeks into the project, after a lecture in Modulation Blending(heightmap-based blending), we quickly decided that it was something we wanted in the game. With some help from the lecturer, it was swiftly added.

Similarly, Triplanar texture mapping was wanted, but was cut due to time shortage.

After working with this type of blending for a while, it's workflow turned out to be different enough to get good results with the texture creation process we currently had. To avoid having to make and learn a new workflow to get it working properly, we reverted back to linearly interpolated texture blending. As an added bonus, we got the ability to utilize more textures on each terrain, from the previous 5 to 8. It was something we couldn't add due to the Unity shader not supporting it, so previewing was not possible.

To get a bit of additional details in the terrain texturing, I changed the limit of textures that could be used from 5 to 8. The old limit was there mainly due to the custom Unity shader I wrote not supporting any more textures, and it was important to me that it looked almost exactly the same in Unity and our game. But with going back to linearly interpolated blending, we could completely remove that limit since it was Unity's default blend mode, but I kept it at 8 to keep some performance.

The terrain engine already took a while to draw with .5 million vertices and 8 * 4 full PBR-based textures, and I did not want to add more.

World event scripting

As an addition to our Lua-based scripting system, our level designers were interested in a way to add scripted events in the world at locations of their choise. I took on the task, deciding to implement a simple editor into Unity first.

Something that is important to me is the usability of what I create. I want it to be easy to use and understand, both front- and back-end. So when I were creating the editor I wanted something simple since the users, our level designers, didn't have much scripting experience. A script trigger on a collider should do the trick.

Taking inspiration from Unity itself, it was decided that there should be three events in the trigger; OnEnter, OnLeave and OnTick. The first two are quite self explanatory, triggering once when a unit enters or leaves the trigger volume, while OnTick was for continuous updates for things like timers, triggering 4 times every second.

It worked well, and a basic playable level was created with it, but a need to be able to use variables was required for more advanced scripting, such as to keep track of if a script had been triggered already. Because the editor was built to spit out the finished script file, a simple panel could be added into it to allow adding variables to each trigger script. The variables could then be used in all three events of that script.

Student awards

As voted by students who tested the game, out of 6 games

Least amount of bugs

3rd Place

Best entertainment value

3rd Place

Best Gameplay

3rd Place

Best Art

1st Place

Best Storytelling

1st Place

Best Overall

2nd Place