My Godot game engine experiences
What's up folks. Welcome to the UIBuzz podcast and video log.
In this episode, I talk about my experience with the Godot game engine.
So I have been working with this now, and I want to start by saying I started from knowing nothing other than this was a game engine. I think I've used it for about seven or eight hours in total now. And I want to give some thoughts.
First of all, why am I doing this? Well, as I said before, it's always good to try out multiple tools to always have options open. And the Godot engine is one of those game engines that I was always curious about because so many people use it and like it. Of course it's essentially licensed free as it's open source.
I always urge folks to support your toolmakers, as I've said before. But one of the things I wanted to do with this was do like I've done with the other engines like I did with unreal engine and unity, which is to rebuild my Sprite kit based game that I have on iOS now.
The interesting thing here, of course, is I just like unreal and unity. I can publish to multiple platforms that is an immediate payoff right there. As I've expressed in other episodes and on my Compile Swift, SpriteKit gets very frustrating to work with, and it's not really a game engine, as much as it is a framework.
### My plan of attack for learning
The best way for me to experience this engine is come at it from the perspective of knowing essentially nothing. What I mean by that is using the built in tools and features and everything else and discovering their benefits, their limitations, all of that kind of stuff.
So for example, I went with GD script, as my programming language of choice. You can use C++, and of course others via plugins.
For me, something I will look at is the Swift binding option. Which is very interesting to me, obviously as Swift is my primary driver from day to day. And if I can write swift, maybe with a little inconvenience, but if I can write swift in Godot, Hey, that's perfect for me.
But for now I went with GDScript so I can understand it. So let's go through this. I'm rebuilding my endless hurdles game. It's a very simple, straightforward, 2d infinite scroller. The player has simple options for controls. You only really need to jump over things. That kept the control side of things simple. As far as input. Being 2d means there is less concerns for me for, having to deal with the global space within the game. Also just dealing with 2d sprites, textures, materials, that kind of thing.
I decided that I would use the assets that I'd already created for the SpriteKit version. To keep life simple. I Didn't need to rebuild those, the resolution and everything else was good enough.
### Things I like in Godot
The first thing I like about the Godot engine. You just put everything in a bunch of folders as far as assets. You lay them out in a bunch of folders on your file system. Windows, Linux, Mac, whatever.
I went with Mac. You can organize everything in these folders and Godot keeps itself up to date as far as indexing and where things appear. So that's nice. The next thing that struck me was. I had to adapt to my brain to the idea that everything is a node.
In other languages and engines, for example, Swift and SpriteKit, you have this idea of a node and attach a bunch of things to it, or manipulate a bunch of stuff on that node. Same with Unity, and for that matter unreal engine.
You apply and attach it to that node, but it is still part of that node. Took me a while to wrap my head around the idea that in Godot everything's a node. So you have a node within a node. For example, if you've got, let's just say a button, you can put a graphic in there and there are multiple ways to do this. But you can essentially just add a 2d Sprite node, and add an image to that node. Then that is now part of the button.
So you can end up with these very long. Visually complex trees. Once it snapped in my brain to just think of the root node and in there is something, say a player. In that player, node is another node for the animated sprite graphic. There may be, a collision area. Hit box, those kinds of things. So I think you get the idea. They're all nodes within the player node. Once that registered in my brain. It's good to go. Fantastic.
I can just drag new nodes or add new nodes to something and keep working.
Scripts are different. This was an interesting one because you add a script in a different way to a node, via an icon in the inspector.
Once I got that, now I've got this mostly blank script. It took me a little while to remember, to think about it that way. Yes. I'm sure there's other ways, but again, I'm just embracing the ways built in to the Godot engine.
Then it opened up the script.
GDScript is very much like Python is the best way for me to describe it, I guess.
Spaces or tabs are critical. The interesting thing about that, I do like in the built in editor, if you have a mixture of spaces and tabs, it solves that holy war problem for you. You can't have both, you can do it, but it's going to keep reminding you. Hey, you've got a mixture, pick one. I went with tabs.
And that's interesting because anytime you get code from somewhere, say stack overflow, and you paste the code in, the editor is going to go Hey, these are spaces. That's a nice little reminder. This is forcing me to adopt a good practice of go with one. Stick with it. So I like that.
A lot of Godot is about the little things.
The other thing is it has a lot of built in functions within the script for sensible helpers. Now, what I mean by that is every time I tried to solve a problem and I did this on live streams. Folks in the chat room were very helpful. Shout out to you all for helping me adapt.
I was trying to look at it and say, okay, I know I need to achieve this thing I need to have. If this object collides with this object or things like that. Godot has this wonderful way of having very sensibly named functions within the language. And these are great.
No cryptic name that you have to then research in the documentation for hours and hours to understand what they mean. They're very sensibly named. I loved this. This helped me move along quickly.
I'm now seven or eight hours into this and have rebuilt most of the basic game already. Fantastic. Absolutely fantastic.
### My advice for transitioning
I'm blown away by how sensible Godot it is to work with. It does require some adaptation if you are used to other game engines or programming languages, all I can give you is my advice to embrace the way it wants you to do things. That's just my suggestion.
I think you'll have a quicker transition, like I have.
I'm continuing to move forward with this as my 2d engine of choice right now for rebuilding my games because I wanted to have better options for expanding as they go forward.
SpriteKit, like I say, is just an exercise in frustration even though I'm very familiar with Apple's platforms for development. I don't want to build an engine to build my game. I just want to build my game.
### The weird bits
There are some quirks right now, as I understand it, publishing to iOS platform is not quite ready in the 4.x versions. I'm using Godot 4.1.1 or something like that.
Whatever the current production version is. And as I understand it, there are some limitations right now. You can't use C++ to publish to mobile platforms. It's just not part of it yet. They're working on it. So there are some gotchas there.
There's hundreds of people working on this engine and I have found it to be super stable, super reliable, and I'm just really impressed with it.
### Final thoughts
So in this episode, I just wanted to put this out there to say, if you've thought about it and you're not sure. Take the deep dive, go for it. It's a lot easier to work with than it might seem at first if you are someone who's used to programming already.
I also think it's a good one because there's lots of fantastic resources and everything else out there if you're making a 2d game, you don't have to deal with issues like 2D in a 3D engine like Unity or Unreal Engine.
For folks just getting started with development, I really think it's a good option.
Building UI systems in Godot is a lot simpler than some of the other engines from the perspective of building and incorporating, it's just there and you bring it in.
### Endless Hurdles 1.1 release
Also want to mention that I've just pushed to the store the new version of the Endless Hurdles game on iOS. This is the SpriteKit version that has the brand new Halloween event, which I spent a lot of time working on. Also a lot of time in the marketing side of things, I'm really went to town on it a bit more. Every time I release a new patch, I want to push things further. And so that's out there.
The event will automatically activate and deactivate itself. So if you play the free in game event between October 12th and November 15th, you unlock the Halloween event free forever.
Simple as that. It doesn't cost you anything. It'll just register as being played and stay unlocked after the event.
If you don't play it during the event, the button will disappear after November 15th. So my advice, download the game, play the event at least once.
If you've got any thoughts on this, or if you want to come talk to me about the Godot game engine. I am very invested in this subject you can reach out to via the contact form or @UIBuzz on Twitter.
