Jump directly to “How did I get started with Godot?” if you don’t care about me and just want the info.
At the end of 2023 I worked on DDPub, the publishing engine that runs this and several of my other websites. (I just noticed I didn’t really write anything about it since I put it in production…) While it was a tool I needed, it lacked public appeal and wasn’t “visual”—it was hard to showcase.
In 2024 I decided to work on something more exciting and came up with this idea of a typing game because I’m one of those people who like keyboards. I didn’t want my side project to be a SaaS or something like that—it felt too much like work, and a focused educational game seemed like a better idea to keep me motivated to finish it.
A few years ago I was working on another game involving text called Hayaku, the goal was to teach people to read Japanese faster and it had a grid-based control. There is still nothing like it on the market and I may return to it later.
When I worked on Hayaku, I looked into many frameworks and engines because I needed full control over text rendering. Eventually I rewrote the project several times, but I got furthest first with C# and FNA (and then MonoGame), and the final pass was with C++ and SDL2 where I used FreeType and HarfBuzz directly to render text where and how I wanted.
The point of this long introduction is that I’m familiar with the hobby gamedev landscape and at least heard if not tried many of the small engines and frameworks. I also know exactly what I need re: platform support, controls, ingesting data etc.
The simple but profound gamedev wisdom for hobbyists goes like this:
If you want to ship a game, don’t build your own engine.
Especially for software developers, building your own game engine is extremely enticing because it’s such a neat piece of software if done correctly. Unfortunately, it’s not a game and the hapless victim quickly learns that a complete engine, no matter how small, is still complicated—in fact, too complicated to complete. The developer never ships the game. (You guessed it, I was that developer with Hayaku.)
This time I decided not to fall into the same trap and put some pressure on myself. I joined an in-person gamedev meetup and committed to bringing a prototype—and it actually worked.
Now was the small matter of choosing the game engine.
First, of course, there was Unity. I actually got paid to develop several somethings in Unity about 10 years ago and it left a bad taste in my mouth (for various reasons). I kept an eye on it but the bad taste never went away, and with their recent layoffs and licensing changes I liked it even less. It would probably work OK for any of my ideas but I simply don’t like it.
Then there was Unreal Engine. I have enormous respect for Epic Games to make such technology available to developers essentially for free. What you can do with Unreal if you know what you’re doing blows my mind—I follow several indie devs who use Unreal on Twitter. I installed it on my Windows PC, it was 60 GB. I played around with it and modified their demo vehicle project exploring the concept of “Moon rally.”
You can tell it’s a professional tool because of the infinite controls and complexity that it has. I decided Unreal was too complicated for what I was capable of achieving. No doubt you can (fairly easily) achieve visual fidelity but I can’t feel good about it if I don’t understand how any of it works.
Then there was Godot. A few years ago Godot was low-power and didn’t make the impression it was going anywhere, and nobody really used it. A few months ago it started popping up all over my Twitter timeline and people were saying: “Oh, it’s actually good now.” The developers of Caves of Qud (a game I like) tried switching their game from Unity to Godot.
It could do both 2D and 3D and everything I saw was impressive. It was small, ran on Windows and Mac, had some neat features I saw myself using and powerful text rendering. The last one sealed the deal.
Could I pick something else that would be just as good? GameMaker, Construct, Defold? Probably, but I felt more attracted to Godot.
How did I get started with Godot?
When I opened Godot for the first time, I was like: OK, this looks like Unity but how do I do anything and how does it work? I needed some tutorials.
First of all, I wanted to see how someone used the engine, what entities (?) they used to make a game, the very basics. I couldn’t understand from the starting empty project what I should do next, how to deal with scripts, where to put resources etc.
The very first video that I watched was “Your First 2D GAME From Zero with GODOT 4! **Vampire Survivor Style**” from the channel GDQuest (that is all about Godot, as you can tell). I happened to play (too) many hours of Vampire Survivors just before that so it was perfect.
From that video, I learned the key concepts that you should know about Godot:
- How a scene is structured
- How to find and create nodes of a certain subclass
- How to view and edit the node’s properties
- How to create and attach scripts to nodes
- What GDScript is and its basic syntax
- How to find and read documentation in-engine
- Some starter methods you might want, and that some engine bits are singletons
- How positions of the nested nodes relate to each other
- Signals and how to use them (signals are a very powerful feature of Godot)
- How to (pre)load scenes and other resources
- How to refer to specific nodes in code
- How animations work and how to make them
- UI layout and themes (which are both conceptually well done in Godot, I’m saying this as someone who does UI full-time)
After watching just that one video (on 2x) I now had a decent mental model of how to interact with the engine. This was enough to start working on my prototype and I made some progress before I had more questions. It was clear the engine didn’t really put any guardrails on how you wrote code and I wanted to know the best practices of structuring the game so that it was composed of components and not a big bowl of spaghetti. I found the channel Godotneers that gave me answers to these questions.
I watched the video “Godot Components - how to structure a game into manageable parts” that helped me learn several approaches to decomposing nodes and code with the aim of reusing them, and how the engine could help. Specifically, you can define virtual interfaces (duck typing), hide irrelevant methods on your scenes and provide context-independent signals, define your own types that are disconnected from any nodes and use them, and so on. Basically in this video you begin to understand how to not program yourself into a corner and do programming in Godot with code, nodes and scenes like you do any other programming.
To better understand how to create and layout UI, I watched “Godot UI Basics - how to build beautiful interfaces that work everywhere” on the same channel. It seems that now a lot of the UI systems (including web and mobile) are converging on using composable containers that automatically layout their children. If you’re familiar with this way thinking, you’ll be right at home in Godot after learning about its container types, and how to use anchors to lay out UI that is not tied to a container.
After that, I didn’t watch any other videos but was able to work on my game by only using the Godot documentation. The documentation is unevenly distributed. For some areas, there is not only documentation (that doesn’t tell you how to use something), but also tutorials (that do). For the key feature I needed most, the TextServer, all methods have documentation but some entries don’t describe what the parameters are supposed be, or what the method returns—there is a return type, but what does it mean? However, in the worst case you can just look at the source code, that’s a big benefit of open source.
They have a whole “Getting started” section which, incidentally, has an overview of all the key features I listed above. However in my opinion, it’s better to see all that in a video first to map it to the UI of the engine in your head.
There is a “Best practices” section that I read soon after watching the videos to better understand what to prefer when there were several approaches.
One of the most important sections which is somewhat hard to find is the section on GDScript, Godot’s native scripting language. It’s similar to Lua and is very easy to pick up. I decided to use it for now because it’s immediately accessible on any platform, doesn’t need any setup and works right in the editor. Godot lets you use any language as long as there is an extension but this all requires some setup. So far, GDScript has been worth learning and worked well for me.
There are many features in Godot that are clearly there to make the developers’ lives easier, and I’m sure you can discover them yourself as you work with the engine—this is not supposed to be a tutorial, I’m only giving you some pointers that I’ve found useful myself.
One final feature that I find particularly relevant to my usecase is resources and specifically creating your own. Resources are simple text files in a specific format and I can generate them (no matter how complex) with an external tool. They get compiled to binary when you build the game. What makes them particularly useful is that you can assign them to nodes and view and edit them directly in the editor. Here’s a visual representation of a part of the data model for Typingvania:
I have not touched any of the 3D features yet, so I can’t help with that, but there are now many more tutorials and videos than even a year ago, and the Godot subreddit has more than 150 thousand members.
Some say you will experience bugs as you work with the engine because there is such a small team working on it, and I’ve done some research around what people think about it. The overall opinion is that the bugs are mostly small, there is often a workaround, you can file them and they get fixed usually in weeks, and of course you are free to fix the bug yourself if it particularly bothers you and make a pull request.
I’ll leave you with that. Good luck and let’s make something fun to play :)