Weekend with Godot

1280px-godot_logo.svg_

Global Game Jam took place last weekend, once again; I took part with a friend, once again; but this time we used Godot instead of Unity! How did it go? Well, the result is here, and the process wasn’t all smooth sailing. Many small issues were brought up during the few days.

We chose 3.1 Beta 2, with C#, over the stable build which lacked the Quat(Basis) constructor despite documentation stating otherwise. 3.1 Beta 3 came out on the day the Jam ended, so I tried all of the issues on it as well.

Comparisons to Unity will be made as I have 6 some years of experience with it at this point.

Positives first

The editor user interface is clean and easy to use. There aren’t a whole lot of panels or hidden features in the menus as nearly everything relies on the nodes.

The nodes

nodes

The nodes! A slight change from Unity, although the basic scene layout is rather similar and “prefabs” are much simpler in Godot, in theory at least.

There are loads of them, so sometimes it is difficult to ascertain which node to use. For instance anchored GUI elements can be parented to a CanvasLayer node or to a Container node, both work just fine.

About the only thing I missed is dragging and dropping references to inspector variables from the current scene. Setting references in code directly, using GetNode, or utilizing signals are all fine, but cumbersome when it comes to quickly trying things out.

Found a related issue and learned about NodePaths, which are halfway there and would have been good to know in the jam!

Signals

signals

Godot has a simple event system well integrated into the editor with signals neatly arranged into a separate panel, much unlike UnityEvents which are massive and mixed in with other script variables.

As a further improvement the “Connect signal” menu should show available methods in the targeted node. This would be useful, especially when it comes to core functions as the signals look for GD script methods (eg. queue_free), rather than C# methods (QueueFree). Related issue report.

A few times during the jam some signals in a scene would disappear when opening a scene after git pull. This might have something to do with the next point.

Scene serialization

serialization

Which is a rather specific point. Git likes to auto-merge text files and I like to manually merge text files; the .tscn file format is not kind to either.

Adding node entries into a scene file and loading it in the editor results in some nodes disappearing, including signals which are the last entries in the format. I don’t exactly understand why this happens so I’ll simply refrain from merging scenes in the future.

This it is not a big issue; Unity doesn’t like scene merging either,

Inspector arrays

InspectorArrays.png

As mentioned before, direct references to scene nodes via script variables would be neat. Inspector arrays are another useful feature. They are supported on paper, but just don’t work at the moment.

An inspector string array shows up as expected, but at runtime the array cannot be accessed and its length is either zero or something very strange. Luckily a bug report has been opened and assigned.

Additionally export arrays for all types would be stellar. There is a request already, but an example will suffice nonetheless.

In the last 3 hours of the jam I was implementing sounds and wanted to recreate this simple script from Unity.

using UnityEngine;
public class AudioPlayer : MonoBehaviour
{
    public AudioClip[] clips;
    public AudioSource source;
    public void Play()
    {
        source.clip = clips[Random.Range(0, clips.Length)];
        source.Play();
    }
}

After 30 minutes of wasted time and searching for a solution ended up with this, a completely non-reusable, ugly, hack.

Debug visuals

debuglines

Had a need for debug lines (Debug.DrawLine in Unity) so I made my own, hacky, version again. Something like this, with support for an arbitrary amount of lines which don’t show up in a release build, would be nice to see as a built-in feature. The request is in.

Particle system user experience

Particles.png

The 3D particle system (CPU Particles node) does nothing by default. There is a warning message about assigning a mesh, which results in plain white meshes being emitted. To achieve a textured billboard particle system you also need to add a spatial material, set the billboard mode in the material parameters, and, for colors to work, also check the “Use as Albedo” box in the vertex color section.

Jumping through this many hoops for something Unity does by default is annoying. Needless to say I couldn’t figure out the vertex color bit in the jam, so no custom color blending for us.

The GPU, 3D particle emitter (Particles Node) is even stranger. Nothing shows up even after resolving the warnings in GLES 2, which we used due to a texturing issue. In GLES 3 a mesh does show up so this seems like a temporary issue.

Code editor & IDEs

monodevelop

The built-in text editor works well for quick code changes. The lack of code completion drove me to use MonoDevelop instead, which worked for the duration of the jam at least.

The issue here is that renaming or moving a script in the editor messes up the C# solution forcing a restart on both programs and a manual deletion of the .sln & .csproj files. Time consuming, especially on a tight deadline. This issue is being tracked and it is even mentioned in the documentation as a caveat.

Conclusions

Will I give Godot another go? Yes.

Does it have many small issues? Yes.

Am I going to help with those? Yes, one way or another.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s