Category: godot

I just wanted to take a moment to write about one of my new favourite features of Godot 4.

Tweening! Now this existed in older versions of Godot, but you had to instance a ‘tween’ node in your scene and then reference it through code to get your tween to work.

For those un-aware, a tween in a video development context is to essentially smoothly move a property from one value to another. For example, say you want to make some text fade in, you could tween the alpha channel of that text from 0 to 1 over the course of say a second.

In Godot 4, they made this much easier to do by creating a new helper function called ‘CreateTween’ off of the Scene tree, so you can do things such as…

Tween tween = GetTree().CreateTween();
tween.TweenProperty(this, "modulate", new Color(1, 1, 1, 1), 0.1f);

This would (assuming that the alpha was set to 0 at the beginning) fade in the object over the course of 0.1 seconds. You can chain properties too, like this:

tween.TweenProperty(this, "scale", new Vector3(2, 2, 2), 1f);

If you add that line after the previous two, after 0.1 seconds of fading it, it would double in size over the course of 1s by tweening the scale property to (2, 2, 2). You can also tween other things such as methods (for example, you could Tween a call to QueueFree() to delete a node after X amount of time!)

There are many examples available on the Godot documentation regarding tweening. There are many ways to customize and tweak how the values transition between values. The change in Godot 4.0 to allow you to quickly and easily create a tween programmatically really reduces to barriers to adding tweens to your game on the fly.

I’ve been using it a lot, especially to give more character to the user interface by making things slightly larger or fading in / out.

Will provide updates about projects I’m currently working on soon^TM

Last year I messed around with a game engine called Godot, and enjoyed how simple and lightweight it felt. I’ve used Unity in the past but after trying out Godot I preferred it instead. The way it handles game scenes is great, and I found I could get a lot more done in short amount of time in Godot compared to Unity.

The game is currently being worked on in C#. Initially it was 100% written with GDScript, a scripting language similar to python specific to Godot, but I personally prefer a statically typed language. I got frustrated with GDScript as the project and my scripts got larger and eventually decided to re-write the whole thing strictly in C# which is an option for scripts in Godot. So far, so good.

Another goal of the re-write was to leverage a new networking solution (SteamNetworkingSockets) instead of the built in networking provided by Godot which uses ENet. I plan to write more about my networking in the future.

When working in Godot, every game scene is a collection of nodes, which can have nodes as their children. Essentially every scene is just a big tree of nodes.

You can instantiate these scenes easily during run time. For example, I have a player scene, and a game scene. When a player joins, I create a new instance of my player scene and add it to the game scene. Every important part of the game is a scene, which are all just composed of nodes.

In contrast to Unity which has objects which you modify and save as ‘prefabs’ to instantiate later and a entity component system (at least the last time I used it that’s how it worked), Godot felt more intuitive and straight forward. Everything was a node.

For a quick example, in Unity you might have a generic object, and to make it render, you attach a sprite renderer component, in Godot you’d add a Sprite node to your node.

Anyway, I’m kind of rambling but basically I enjoyed how Godot worked and for my use case it performs perfectly, and Trivo runs quite smoothly on it so far. I plan to keep using it unless it somehow fails to provide what I need for Trivo. With Godot 4.0 coming soon I’m excited to see all the new changes.

So recently I’ve been doing the user interface for Trivo, and I had been referencing all the control nodes that I needed by creating string variables and storing the path to them.

This worked, but anytime the scene’s node hierarchy changed, my hard-coded string paths would all be incorrect and have to be updated. This caused changes to the UI to be quite cumbersome since I had to copy new node paths over to my code each time.

I got fed up with the workflow and looked for another way, and I can’t believe it took me this long to figure a cleaner way to manage references to the nodes I want to manipulate in my scripts.

Essentially, Godot has a nice feature that allows you, in the editor, to set a scene’s variable. Godot also features a handy variable type called a NodePath which is just essentially reference to a node in a scene. Combining these two features allows one to easily add NodePaths to your script which you can then set to nodes in your scene that will automatically update even if they’ve been moved.

This is pretty simple, but for whatever reason I never leveraged it until now. Glad I’m using it now though, makes changes to the scene tree much easier when I don’t break all the references in the script.