Godot

I forget exactly where I originally read about the Godot Engine but I decided to give it a try after I completed my map generator. The verdict: Godot is extremely good. I should note that I have not tried using it for 3D projects, just 2D game projects. Here are some things that stood out to me.

Supported Languages

Godot supports several languages, including C++, C#, D (GDNative), JavaScript and Nim. It even has its own proprietary integrated language, GDScript. A Godot user created a benchmarking tool that helps give an idea of how well each language performs. C# support is still in its early stages, unfortunately, and you can’t use Visual Studio for debugging… Yet! Given some time these functionalities will be added. For now you have to use VS Code to debug, which admittedly isn’t that major of an issue.

Supported Platforms

Windows (and Xbox One by extension), Linux, OSX, iOS, BlackBerry 10 and HTML5 are supported. Other console support cannot be included with Godot as console SDKs are proprietary and all of Godot’s code is open source. There are ways to deal with this limitation, as outlined in the Godot docs.

Organization

Godot and Unity use a lot of similar approaches when it comes to organizing a game project.

Unity uses the entity/component paradigm with scenes and prefabs. Godot instead uses a tree approach to accomplish the same thing. Everything is a tree of nodes. Your scene is a tree containing several nodes for the interface, game elements, and so on. Prefabs are just a tree of nodes. Everything is organized in this manner.

What makes Godot stand out is that there is no distinction between scenes and prefabs like there is with Unity. Scenes and prefabs are the same thing, functionally. If you wanted to, you could instantiate several scenes inside of your main scene. There’s no limitations as to what you are allowed to do.

A GameObject in Unity can have several components, so you have to take a slightly different approach when you want to accomplish the same thing in Godot.

If this were Unity, some of these things would just be components of the base PlayerTest node. Personally i think i prefer Godot’s approach. This way, you can see every component at a glance without having to inspect entities to see which components they contain.

Each node performs a specific task. An AnimatedSprite node renders a sprite and handles its animations, a RigidBody node controls a rigid body, and so-on. When you’re used to being able to have several components on a single GameObject in Unity, it can be a little jarring at first. The upside of Godot’s node system is that it’s very easy to keep track of everything since every component is its own node with whatever name you decide to give it. Instead of having a bunch of components tied to a GameObject, you have a tree of the various nodes your game element requires.

Animation

Godot has an incredible integrated animation system that works for both 2D and 3D projects. The general workflow is:

  1. Set up your skeletal heirarchy.
  2. Create animations.
  3. Use blend trees and state machines to control the current animation state in-game.

Not only is the animation system intuitive and easy to use, it also allows you to wire function calls to specific keyframes in the animation. It’s been perfectly planned from start to finish.

Workflow

Debugging a project can initially be more tricky with Godot compared to other engines like Unity. With Unity you can set up a scene then run it in debug mode and pause the game so you can browse the active scene in the editor window. This allows you to tweak variables and move things around in the live scene so you can really get an idea for what is causing bugs and how certain elements are interacting.

With Godot you can pause execution and examine the instanced entities in the scene tree but the interactivity isn’t there. You can’t see the active game instances rendered in the editor pane so you can’t dive in and disassemble things like you can with Unity. This is probably my biggest gripe with Godot’s debugging workflow.

Other Considerations

As mentioned before, Godot represents a game scene with a tree of nodes. In Unity you can access a GameObject’s component pretty easily. How do you do this in Godot when your components are organized in a tree structure?

var list = GetNode<VBoxContainer>("CenterContainer/Units/UnitContainer");

Nodes in Godot are organized visually as a tree, but when accessing them via code you use a string path.

I ended up writing some utility functions for creating nodes via code since it tends to get a little obnoxious without them.

public static T Instantiate<T>(string path) where T : Node
{
    string temp = "res://Prefabs/#.tscn";
    string filepath = temp.Replace("#", path);
    var node = GD.Load<PackedScene>(filepath);
    T inst = (T)node.Instance();

    return inst;
}

...

// Usage example
var player = Util.Instantiate<PlayerController>("Characters/PlayerTest");

Conclusion

Godot is shaping up to be the first open source game engine that is on par with existing game engines. Even in its current state i’d consider it a viable alternative to other existing 2D game engines. As it matures i expect it will get more and more attention.

Noita Enhanced

Noita is a brilliant action roguelite (I hate this term) where every pixel is simulated. Compared to your standard roguelite, there’s a greater focus on using the environment to your advantage. What really excited me the most about it was the degree to which the game can be modded.

Under the hood

Noita uses Lua for handling all scripting-related tasks. Serialized entity data is stored as XML files and there is a heavy reliance on an entity/component relationships for organization.

Virtually all aspects of the game logic are modifiable via the existing Lua scripts. A modder can override certain scripts or XML files or append new data with relative ease.

What needs changing?

When I start modding a game, it’s usually for one of two reasons: I have ideas for new features that I think should be in the game, or I find certain aspects of the game to be lacking or incorrectly implemented. With Noita, it was a mixture of both.

I skipped over some of the stuff i made since i don’t have a gif for everything, the entire list of mods i’ve made can be found here.

High risk, high reward

In Noita, the player progresses by collecting magic spells to append to their magic wand. There are certain spells which are considered to be must-haves, and once you find them you have a better chance of reaching the end of the game… If you can mitigate their inherent risk. One glaring problem I saw with the game progression is that the variety of these must-have spells is too limited. Creating new spells that fit this category was not too hard, the biggest thing to consider was the risk/reward factor involved. In order to balance out the stronger spells, they have to be made difficult to use.

Both of these spells are incredibly powerful, but they also have some inherent risk in their use. The freezing spell creates a small shower of damaging ice particles that can harm the player, and if the player manages to get caught in the blast they will be frozen for a short period of time. The magma explosion is very short range and also creates a small shower of magma which can harm the player and ignite them. Shooting it straight upward isn’t possible unless you’re willing to take some damage from the magma that falls on your face.

Miscellaneous spells

I made a handful of other fun little magic spells that I thought fit the game well, such as a projectile modifier that makes your projectile suck in nearby objects.

Perks

Perks are a major component of Noita. The player descends through several biomes and at the end of each biome they reach a “safe room” where they can regroup, heal, and adjust their magic spells. At the end of each safe room the player is given 3 random perks to choose from. A perk changes an aspect of the player to make them more powerful in some way. There are perks that make the player more resilient to damage, perks that increase the player’s mobility, and so-on. I thought the selection of default perks was a bit lacking so I created a handful of my own.

This perk makes the player summon sprites that attack their enemies automatically. These sprites are technically an NPC, but i used the entity/component system to give them a projectile component. In a technical sense, they are a living projectile.

Both of these perks give the player an inherent trail of either fire or ice. The trail applies a burning or freezing effect to enemies that enter it, and it also interacts with the environment as you’d expect. The fire trail causes oil to ignite and turns water to steam, and the ice trail freezes any liquid it touches.

Altars

Giving the player random places that allow them to trade objects for rewards was something i wanted to do, so I implemented new altars which have a small chance to appear in any given run.

This altar makes use of the game’s pixel engine to convert corpses into gold dust pixel by pixel. It looks neat and gives the player a way to generate income using nearby corpses.

Magical stones

The world is littered with enemies and treasure, but it also contains objects the player can pick up and store in their inventory, such as flasks of water. There is one unique object, a stone that emits electrical charges, which caught my interest. I decided to make different versions of it.

The holy stone converts impure substances such as blood to water. The fire stone melts through ice and converts water to steam.

Quality of life

There were several small aspects of Noita that annoyed me, so I modded them. I don’t have much footage of these mods in action because they aren’t especially exciting.

Putting it all together

I kept all these mods separate from eachother so that i could allow the end user to pick and choose which features they want and customize their experience to their liking. I created a modworkshop entry containing the github link to my mod collection. It quickly became one of the most popular Noita mods. This, to me, is affirmation that my assumptions about what aspects of the game needed changing were correct!

Mordhau CTF

I previously discussed the process of making a custom map for Mordhau. Finishing my first map left me with a feeling of dissatisfaction, like there was still work to do. With a more complete understanding of what the uSDK is capable of, I set out with a more ambitious goal of creating a whole new game type. The obvious choice for this was capture the flag, something that i thought would translate well to a game where melee combat and teamwork are at the forefront.

Luckily, someone had already created a very barebones capture the flag mod and publicly released it. Much of the difficult work had been done, so I could really focus on the finer details and figure out what needed changing.

Fine tuning

It took several iterations, but i finally managed to massage the CTF mod into something i thought was more appropriate for Mordhau.

Stalemates

The basic CTF mod neglected to implement any sort of stalemate mechanic, which i think is a crucial aspect of capture the flag. The idea is that if the enemy team is in possession of your flag, you cannot capture theirs until the stalemate is broken. This creates a situation where both teams have to simultaneously defend their flag holder while attempting to break through the other team’s defences and kill the enemy flag holder.

A badass flag

I grew up playing CTF in games like Halo and Soldat, and one of the important concepts in both of those games is that the flag runner still has the ability to defend themselves, though it may be in a somewhat limited capacity. In Halo, you could bash people to death with the flag. It’s worth mentioning that the flag also looked really cool. Improving on the appearance of the flag was one of the things I did almost immediately.

Now we’re cooking. Achieving this was easier than i thought. The flag object is derived from the quarterstaff weapon blueprint. The skull, coiled rope segments and flag are all meshes (with all collisions disabled) parented to the quarterstaff with a vector offset to move them closer to the end. Simple but effective.

Since the flag object derives from the quarterstaff, it behaves exactly as the quarterstaff does when you’re holding it. I felt that it was a bit too weak in this state, so I tweaked its damage numbers upward slightly to give it a little more utility in combat. It’s not the strongest weapon, but a flag runner can defend themselves with it in a pinch.

A proper HUD

Capture the flag has its own unique HUD requirements, and thankfully the uSDK makes it possible for modders to create their own. I copied an existing HUD for one of the other official game types and made a few changes. Red and blue scores on the left and right, and a time limit in the middle. That’s all you need.

Both flags also have a HUD widget parented to them that indicates where they are for all players. I made some changes to the widget so that it used color instead of text to denote which team it belongs to.

Sound cues

The original CTF mod had notifications appear on the HUD for when the flag is taken or returned. I added some sound cues for these situations, and also added a celebratory noise for when a team scores.

The map

With my tweaks to the game scripts complete, i could focus on creating a rough level to test in.

I didn’t put as much effort into the visuals on this level, partly because the design was so absurd from an aesthetic standpoint that it didn’t seem to merit a serious approach. The goal was to make a map that was fun to play, not necessarily a realistic depiction of a castle like so many of the other Mordhau maps.

The colored dots indicate spawn positions and the colored X marks indicate the flag positions. It’s not immediately obvious, but the players spawned on top of a raised platform to make it a bit harder for them to be attacked as they spawn.

The general concept of this map was to have 2 symmetrical bases very close together, with a chasm dividing them. There’s an emphasis on lateral movement rather than straight lines. There are 5 bridges at ground level, as well as 2 risky bridges on the outer edges between the higher levels of both bases. In the middle, there’s a large wooden elevated structure only reachable if you jump to it from the upper level of one of the bases.

Playtesting

I thought this was an interesting layout, at least for a simple test map, but I was totally unprepared for the general response from the community.

After releasing this map i had left town for a couple of weeks. Upon returning i found several letters in my inbox discussing the CTF mode. Apparently a tournament had been organized by competitive Mordhau players and the map received a lot of attention.

So much attention, in fact, that I received a message from one of the developers for Mordhau. We set up a small group chat between myself, the developer, the fellow who created the original CTF mod, and a prominent figure in the competitive Mordhau scene. We discussed CTF and how it has the potential to be a game fit for the competitive Mordhau scene. His goal is to iterate on capture the flag further to figure out which aspects of it are fitting for competitive play.

A new version of CTF is now being worked on, with my map being the de-facto test map for it. The rules have become more complex, with players having to plant stolen flags in a specific zone and defend them. Even if this new game does not catch on with the competitive scene, I think that it has potential with the broader community.

Next steps

My goal now is to finish a few better looking maps that work with CTF. Based on feedback from players, it has become apparent that bigger isn’t always better with CTF maps. This is great news for me since it means i can produce good looking maps faster.

I’ve been able to publish a handful of maps on mod.io and they have been received well so I’ll probably rent a server for a few months and set it to only run CTF maps and see if it becomes popular.