Emily's Hobbies

👩‍💻 Unity? Err... how about Godot?

So after struggling with Unity for a bit, I'm switching gears and trying out Godot.

Initially I was concerned that Godot might be too lightweight in the end for what I want to do. Or rather, I was afraid I'd start working, and eventually reach a roadblock where I was heavily invested into it, but then Godot isn't capable of handling everything I'd wanted, and I'd have to cut features I have my heart set on. That was the main reason I'd went with Unity, as both engines support C# - my bread and butter.

Unity

But as I used Unity, I kept running into problems (which I talk about a bit here.) An issue I kept dealing with was trying to get some basic platformer code going. For example: double jump! With some tutorials, I could get a basic jump working for my stick figure. But once you start trying to do a double jump, things got... messy.

My basic thought process was to have two variables: one that tracks a number for the maximum amount of jumps allowed (called MaxJump) and one that tracks how many jumps the player has done so far (called CurJump). The CurJump value resets when the player touches the ground. Simple enough, right? Well, every time I'd try to fiddle with this configuration, it seemed Unity must not really be tracking my variables, or adjusting their values, the way I'd expected.

The tutorials I found were always different. Which is okay, but they were also incredibly complicated to get this functionality to work. I never really found one that took the approach I wanted to use, and many had very complicated logic that seemed so over the top for a basic double jump. This code snippet I shared in the last post uses a enum called PrepareToJump, which basically was you shift the character into a "prepare" state, and you can jump from that state.

if (jumpState == JumpState.Grounded && Input.GetButtonDown("Jump"))
    jumpState = JumpState.PrepareToJump;

But... why? Why does it need to be so complicated??

After trying this approach and found it to be too much while still not really getting it to work... I decided I needed to create a debug GUI to spit out the values of my variables. Well, similar to my problems with reading user input, Unity also had at least three "debug" systems that it was recommending for different scenarios. I sampled a couple, really tried to make one work, and just set the whole game project aside.

Again, why so complicated? I just want to spit text at the GUI.

Maybe my naivety to the systems is too great to figure it out. Maybe it's actually quite simple and an experienced Unity dev can fly through these. But I didn't find any of it to be intuitive, and struggling to find the right tutorials for every little thing didn't help.

Switching

After having lots of trouble with Unity, I decided to google a list of games that had been produced with Godot to get an idea of what it was capable of. And I found that Godot has actually been used for a AAA game! Which game, you ask? The Sonic Colors remake. So... nothing amazing, necessarily, but this did give me an idea of what Godot could handle. I'd played the original (though not all the way through) and if you've played a 3D Sonic game, they are full games. Godot is solid, or at least solid enough for my own pet project.

Godot

Godot has been a night and day difference. I do think the time I spent in Unity helped, as I've opened the Godot interface before (I'd considered it before going with Unity, so I had it downloaded already) but couldn't make heads or tails of what I was looking at. Now I'm familiar with how these things use their own custom class for a base - Unity uses MonoBehavior, Godot uses some variety of Node. Just about everything has to be framed within these object types.

Almost immediately, I found a basic tutorial provided by Godot themselves for how to do a basic platformer. Two things were immediately better about this:

  1. This was a honest to goodness, step-by-step, put-together-yourself tutorial. Not a finished platformer that you can just pull apart.
  2. The tutorial didn't give you advanced garbage that you don't know what you're looking at. The Unity sample project was bloated with far too much for a beginner to get lost in. It's honestly terrible as a primer.

The Godot tutorial was not only produced by the Godot team, but it's edited by the masses. You can post comments directly to each tutorial page to get help with your particular bug, or suggest corrections for the latest version of the tutorial - because they update the tutorial for every version of Godot. Which is huge; any youtube tutorial you find has potential to become out of sync with the latest version if the devs decide to move just one menu item to a different location. Because Godot is set up this way, the tutorial remains fairly accurate - and if you DO have problems, someone else may be having the same problem in the comments!

And no, I don't expect Godot to provide these nice tutorials for every little problem I have. But for starting off and getting the hang of the program, it's very nice to have my hand held, and not have to worry that I can't find the right menu in the GUI as I work. (This is why I'll never learn Blender.)

My Progress

So for all the progress that I made in Unity, I struggled to get jumping working. I got basic movement working, I got jump working, but then broke it several times trying to get double jump working. By the time I abandoned my Unity project, jump was completely broken. I also tried to get the GUI to grab the mouse's coordinates on the screen when I left-click, and shoot a fireball object from the player to the point I'd clicked. Similar with how jump never seemed to work right, the coordinates that I was getting back were always off for some reason. 😒 Also did some structural code, such as making interfaces, enums, etc. that I plan to use. This was all over several sitdowns with Unity, spread out over a few months.

In one weekend with Godot, I've caught up to where I was in Unity. The only thing missing is spawning a fireball from the player and moving it to the mouse coordinates. I do have the GUI printing the coords when I click, however, so it should be doable soon. I have some basic test animations set up that I didn't have before, as well. (Which, to be fair, I hadn't drawn these images when I was working with Unity. I had just a still image I was working with. But every time I looked into animations there, I found it confusing. And I was able to catch up and set up new animations in one weekend. So... yeah.)

Screenshot of the workspace in Godot.

Screenshot of the workspace in Godot.

Here's a basic video of my test character jumping! I'm not sure if Bearblog has the markdown capability to play a video, but it did let me upload one.

Shoutout to my friend Andy for sharing his Godot resources with me and talking shop as well. I've got a site of shaders that I'll be able to thumb through when I'm ready to get some cool effects going, which I'm sure I'll need. He shared a plugin with me that might be helpful with some of the dialogue modes I want to do later on, I haven't installed it yet but it sounds cool, so we'll see.

So hopefully I'll have more updates here and there going forward. Windows 11 makes it easy to take screen recordings that Bearblog is letting me upload, so I can share bits of progress that way. Maybe once I get further along I can make a youtube channel for those clips and embed them directly? I guess we'll see.

#2025 #game-dev #godot #unity