Life update: I'm learning Godot

Apologies for the lack of updates on gamedev stuff or art in recent months. It's been a difficult year for personal reasons I won't get into, as well as the same reasons it's been a difficult year for everyone else. The world sucks right now. You get it.

Nonetheless, a little over a month ago now, I decided I needed to channel my nervous energy into some long overdue creative work, to give myself a distraction and achievable goals. And so I'm finally formally learning the engine I would like to make my future games in: Godot.

Read on for my experiences with Godot so far, videos of the silly little games I've made while learning the engine, and my plans for our next big game.

Why Godot?

Broadly speaking, I desperately need to move on to working in a "proper" game engine after twelve years with RPG Maker VX Ace. Don't get me wrong, RPG Maker is a great engine, and Super Lesbian Animal RPG wouldn't exist without it. But the tradeoff for its low barrier to entry is that it's extremely restrictive. There's the obvious fact that it's built for one specific genre of games and I'd like to make more types of games, but even on a technical level it has all sorts of issues like terrible controller support, a completely broken reset option permanently bound to F12, and poor fullscreen options. (As a pixel artist it still kills me that my options were to ship SLARPG with either an incredibly blurry fullscreen mode or a fullscreen mode with jagged, unevenly sized pixels. Every time I see a screenshot of the game with uneven scaling I die a little on the inside.) Shit, the editor in VX Ace doesn't even have a redo button!! I could go on and on. If I want to make better games, or games in different genres, or maybe even games that could be ported to consoles, I need to ditch VX Ace and learn how to program in a general-purpose engine.

But why Godot in particular, as opposed to any of the other options?

Well, these days Godot is the rising star in the world of video game engines. I could list features it has over Unity or GameMaker or Unreal or whatever, but when you get down to it, the main reason why people like it is simple: it's the most robust option that's free and open source. This model comes with its own issues and drama, but you don't have to pay a single cent to use it, and you don't have to worry about its parent company fucking it up in the future. Whatever version of the engine you download is yours to use as you please, forever. This also means that the engine's continued development is controlled by people who actually use it, rather than shareholders looking to chase the latest tech trends.

Notable Godot games you may have heard of include Webfishing, Cassette Beasts, Your Only Move is Hustle, Cruelty Squad, EX Zodiac, Brotato, Until Then, and Luck Be a Landlord, with the list only growing as more devs ditch Unity and its endless controversies in favor of Godot. Slay the Spire 2, for example, went from being a Unity game to now being developed in Godot.

This isn't supposed to be a Godot puff piece, though. It does have its drawbacks. Its 3D tools, while improving, are still a bit of a work in progress compared to its more robust 2D offerings. Its dev community is smaller than Unity's, meaning there are fewer tutorials or readymade assets available online. And its free, open source nature means it can't natively support console ports out of the box. But point 1 is irrelevant to me as someone who makes 2D games, point 2 is becoming less of an issue as the Godot community grows, and for point 3 there are plenty of porting studios you can work with to port Godot games to console. I get why many devs who already know how to use Unity or whatever would rather stick with what they know, but as someone picking an engine to learn in 2025 Godot's pros vastly outweigh its cons.

Really though, at the end of the day, there's no perfect engine that magically does everything right. I'm sure I'll find plenty of things that annoy me in Godot over time, the same as any other engine. I've just gotta start somewhere.

How I'm learning Godot

I first began trying to learn Godot in early 2023, shortly after SLARPG released. It went... okay. The engine seemed promising, and I toyed around with the official beginner tutorial project to turn it into this:

So far so good. The problem was that I did this right after the release of Godot 4, so there was basically no learning material available for it beyond this brief official tutorial. There was material out there for Godot 3, but this was now out of date, and many of the people making tutorials had kind of just abandoned their Godot 3 material, knowing they'd have to redo it for Godot 4 anyway. Given the choice between learning the out-of-date version that lacked some new features I was interested in (most notably the tilemap editor) and just waiting for more tutorials to become available for the new version, I chose the latter. This also gave me some more time to recover from my post-project burnout in the process, which I probably needed.

The main thing I'd been waiting for was the completion of GDQuest's paid "Learn Gamedev From Zero with Godot 4" courses. Unlike the countless video tutorials out there where you just follow along and do exactly what the YouTuber tells you to do and copy their code, these are full-blown courses from people who worked on the official Godot documentation designed to teach you the fundamentals of both the engine and game programming in general through the process of making a series of small games. This seemed like exactly what I needed as someone coming off of RPG Maker with extremely bare bones coding skills—which was why I felt overwhelmed when I tried to make things in Unity years ago. I could follow along with a tutorial and copy some prewritten code just fine, and then maybe tweak that tutorial project a little to tinker with it. (Shout out to anyone who remembers "Andromi Ball.") But when faced with a blank canvas, I had no idea where to even begin if I wanted to translate my ideas into functional code. It was like trying to speak a new language where I knew the nouns but not the verbs. Hopefully, these GDQuest courses would teach me those verbs... once they finally had more than a few modules out of early access.

Well, now they finally have more than a few modules out of early access, so I've been going through the learning material they have available. And it's been going really well! So now for the fun part where I show what I've been working on.

My progress with Godot so far

So! The first few lesson modules covered the absolute basic stuff you tend to learn first in a game engine. Make a little spaceship move around in four directions, click on a thing and have it react to being clicked on, display a health bar, etc. And things went pretty well. Even early on, I often found myself getting excited by the possibilities of the engine. While having to code things from scratch is a new challenge for me, working in RPG Maker still often required me to break things I wanted to do down into a sequence of individual commands in the event editor, sort of like in coding. So the skills I developed there gave me at least a slight leg up when starting Godot, compared to if I had never made a game before.

There are also a lot of things that are way easier to do in Godot than they were in RPG Maker. Character animations, for instance, were a fucking nightmare in RPG Maker. It's only really supposed to support simple little top-down sprites that can face four directions and walk in place. For cutscene animations, I would have to stick different frames and poses in the slots for the different directions and have characters "turn" to change frames. The animation for Javis warping in with his staff is practically a whole sprite sheet of its own, shifting between "characters" in the sheet every four turn frames. And of course I had to do this manually, frame by frame, in every scene. Cutscenes would quickly fill up with "set move route" commands for the most simple of animations. In Godot, on the other hand, you just attach an animation player node to a character. The animations can be as long or as short as I want, using any arbitrary number of frames. And then when I want to play one of those animations, I can do so with a single short line of code.

Ironically, some things also require less custom code in Godot than they do in RPG Maker. For instance, I was only able to implement wiggly rainbow text in SLARPG because a kind stranger randomly sent me a plugin they'd coded from scratch to handle those animations. That animated text took over 400 lines of code to implement. Hell, even just using bold or italic text required a third party plugin, because it wasn't built into the engine. In Godot, text within a Rich Text Label is formatted with good old-fashioned BBCode tags. Yes, BBCode, like on a forum! And there are even custom BBCode tags for wobbling, shaking, and rainbow animations built right into the engine by default. Ah, the joys of working in a real engine...

Anyway, after a few units, GDQuest presented me with a list of simple games I could now try to make on my own using the skills I've gained so far. One of them was a clicker game a la Cookie Clicker. Seemed simple enough. So I spent a couple days making this:

Please enjoy the stupid jokes I put into this one. (About a minute in I start using cheats to speed things up lol)

This is about as rudimentary as a clicker game can possibly get, more a digital toy than a real game, but it reflects what I'd learned about the fundamentals of coding in GDScript, Godot's UI tools, displaying and updating text, motion tweens, and other stuff like that. In order to make this I also had to do my own bit of research into implementing sound effects and looping music, as well as how to properly display pixel art and pixelated fonts without letting them get blurry, as the lessons had yet to broach these topics. (When I tried to learn Unity a decade ago it took a third party extension to display pixel perfect pixel art, so I'm very happy to see that Godot supports it by default.) This clicker game is simple, but it's something I never could have made only two short weeks earlier, and I coded it all from scratch!

Fast forward another two weeks, and I was able to make this:

You could say this is a bit more advanced than the clicker game!

So, credit where credit is due: the foundation for this was laid by GDQuest's video tutorial "Your First 2D Game From Zero in Godot 4: Vampire Survivors Style," which I did as a break from the course work. But after following along with that video, I took what I'd learned and went and made my own separate game, greatly expanding upon the tutorial's baseline of "you have a little guy that automatically shoots enemies, and if they touch you too much you die" over the course of a week.

I used my own custom pixel assets for everything, including a tiled background that I put together after researching Godot's tilemapping tools. I replaced the tutorial's auto-targeting gun with a wand that fires where the mouse is aimed when you click, with an auto-rapid fire option that can be toggled on and off by right clicking. As a last resort for when you're cornered, I started the player off with three bombs that clear out enemies in a large circular area. I added damage numbers based on code from the clicker game, and made Claire blink red and play a sound as she's taking damage for more clear feedback. I made the enemies drop EXP gems that level up the player through a linear series of upgrades, including a special weapon that fires in four directions at its base level and then eight directions at its second level. I also gave enemies a small chance to drop items like a health potion, extra bombs, and a magnet that draws in all the EXP gems in the level. And I added a visible in-game timer, and I made the spawn rate of the enemies increase every 30 seconds to ramp up the difficulty over time. I think I even fixed a couple bugs from the tutorial project!

It's still a very simple and unrefined game. It's not much more than the bare minimum for the genre. There's only one enemy type and no randomized upgrades. The sound effects suck, and it becomes an absolute mess in the later waves. But it's still a fully playable little action game that I coded myself. Only a month ago I barely knew how to code and never could've made something like this on my own, so it really does feel like I'm making great progress very quickly.

My main frustration right now is just that these types of tutorials, even these really good ones from GDQuest, tend to leave out a lot of the fundamentals needed to scale up. You'll generally be taught how to make the absolute bare minimum version of a game that spans only a single screen. But how should I handle transferring the player to another level? How do I save and load the player's progress? What are the best practices for handling the audio? How do I make a song keep playing from one scene to the next? I know how to display dialogue by editing individual scripts or resources, but what if I want to store all of the game's text in bulk to make translation easier for a longer game? How would I even do that here? What the fuck is a singleton, and why do people apparently have such strong opinions on them? I could go on and on. Some of this seems like it's touched on in the lessons I haven't gotten to yet, which I greatly appreciate, but a lot of it I'll probably just have to figure out by researching on my own.

This is just the frustration I have as someone coming at gamedev with more of an art and writing background than a computer science one. I don't have a game programming degree, nor have I ever worked at a studio and gotten mentored in the right and wrong ways to make a game, so these aren't things that I already intuitively understand. The other day, gamedevs on Bluesky were shocked and appalled by a graph saying that 19.1% of Godot users don't use version control, but human beings aren't born with innate knowledge of how to use GitHub! This stuff might be second nature to a seasoned game programmer, but it isn't to someone like me. You need someone to explain it to you. And if you never get an explanation, or if you don't even realize that it's a gap in your knowledge in the first place, you just don't know it. If you just decided to make video games one day, downloaded this popular free engine, and started following some tutorials you found online to figure out how to make stuff, chances are you're going to be missing a lot of this supposedly "baseline" knowledge, because the beginner tutorials just don't cover this stuff and the people who know better take it for granted. I guess a lot of people in my position on their sophomore project would be partnering with a programmer so they don't even have to worry about this stuff, but I don't have the money to hire a programmer. So I'm just figuring shit out as I go in an effort to tell the stories I want to tell.

But, again, I'm very impressed with how much progress I've been able to make in such a short amount of time. I'll figure this shit out eventually. It can just be an annoying path to get there for someone from a non-programming background.

Sidebar: "Will you be releasing the survivors game?"

Eh, probably not.

The thing is, while I'm proud of it as a display of how much I've learned in my first month with Godot, it's not a particularly interesting game beyond that context, especially not in its current form. I could polish it further and flesh it out with a proper randomized upgrade system, more characters, more stages, more enemies, etc., but I don't have any ideas for what I'd do to make it stand out in the incredibly oversaturated "bullet heaven" genre. It's quite literally a game I made because I thought it'd be easy, not because it'd be an interesting thing to release.

I just don't want to put out content for content's sake with the cast of SLARPG. That game meant a lot to me, and I know it means a lot to some of you as well, so I don't want to dilute that by slapping the Novas into any old game, just for the sake of saying I made something new with them. I want to save their return for a project I'm actually passionate about, whether that's another grand adventure or something tiny in scale.

(Also, on the subject of releasing New Content, yes, the Hard Mode update will come to SLARPG eventually. That's still on my to do list. But right now I need to look forward to the future, rather than going through and rebalancing SLARPG all over again. Your patience is appreciated.)

So I know it might be disappointing, but I probably won't be releasing the survivors game publicly. It's served its purpose as a study project, but I have other things I want to make.

The future

It's still entirely possible that I'll make some tiny game in Godot that will actually get some sort of release before my next big game. Maybe something set on Reverie, maybe something entirely different. Who knows. But right now, my main focus is on building up the skills necessary to make my next big game. Thankfully, with how well my studies have been going, that's looking extremely doable.

For those who need a refresher, this is what I've said about my next major game in the past:

• It's not related to SLARPG or its setting, though it's still about queer furry characters
• It'll be shorter than SLARPG
• Its content will be darker and more mature in tone than SLARPG, though it'll still have some jokes and cute stuff because I like jokes and cute stuff. But did you like the serious parts of SLARPG? Then good news!
• It will more than likely focus on telling a story rather than having complex gameplay, though this is subject to change
• I did the designs for the main characters in April and am very happy with how they're looking. Y'all are gonna love them
• Bee will be returning to do the soundtrack again

I think I first publicly discussed this game in the SLARPG postmortem back at the end of 2023. It's been a while, but it's taken a long time to recover from burnout after the eight crazy years I spent working on that game. In the time since, while I've been climbing out of that hole, I've been thinking about what I want to do with this new game every single day, slowly refining my ideas for its story and characters. By late April, that congealed into actual character designs, and a proper pitch document I showed to Bee and Anthony so they'd have a clearer idea of what I want to make with them. (Bee's immediate response after reading it was "Bobby, this rules.") Now I'm making rapid progress in learning Godot with the end goal of bringing this game to life.

So, long story short, it's looking very likely that I'll finally begin proper work on this new game before the end of the year. That's a very generous and doable window for the sake of going easy on myself, given my progress in Godot so far. It'll be a while after that before we can show anything from it. But I'm very excited to be making games again.