On coping with failure
A good friend of mine pointed out (rightfully) that I’d been doing a whole lot of talking about the game I want to make, and doing things kinda-sorta adjacent to it like working out details and the visual presentation (I’ll write about that in a later post), but not a whole lot of actually learning the engine. So I decided to really buckle down and give Godot a try.
After all, you can’t make a game with nothing but a design document - you need practical experience. And since I had next to no experience actually using the engine as opposed to watching videos, it was time to build that experience.
So I watched more of GDQuest’s Getting Started With Godot in 2021 playlist, most notably up to the “How to use Godot’s signals” video. I figured that was about all I needed to do some really basic playing around.
On the one hand, I was correct - on the other hand, I wasn’t ready for something like 3 hours of banging my head against a wall trying to get extremely basic things to work. (Given my prior experience with learning coding that was more or less exactly this, you’d think I would know better by now.)
Let’s backtrack a bit. Godot games, as far as I understand them, are largely composed of three things:
Scenes
Nodes
Signals
Nodes are your simplest building blocks. Scenes are a bit of a misnomer, because they’re more like... a container for nodes. If a scene is a toolbox, then nodes are the tools inside.
Despite the name “scene”, they are not related to scenery (I mean, they can be, but not inherently). A scene can be practically anything - so for example, a player character, an enemy, a stat bar, or, yes, your game’s scenery.
A good example is the protagonist of your game. Your Mario or your Link. They are a “scene”, as odd as that sounds. So, this scene might have a sprite node (your character’s appearance), a collision node (the hitbox), an audio node (sound that plays when you jump or get hurt), etc.
Again, it’s basically a box of parts - any components that a player character needs to function. The scene itself is a mere container and a label. Anything in your game that has a few interlocking parts, even if it’s simple? Probably a scene.
So once we’ve made our player character’s scene, what do we do with that? Well, the neat thing about scenes is that once you make a scene, you can drag them into *other* scenes. If you have an overworld scene, you can drag your player character scene in, then some enemy scenes, and an item scene... et cetera. In other words, you design various parts of your game, then put them all together in a bigger scene.
And you can use as many instances of a single scene as you want. Want 4 goombas? Drag the goomba scene in 4 times. And if your Goomba turns out to have a bug in its behavior, fixing the original Goomba scene will automatically fix it for all 4 of those Goombas.
Another neat thing is that scenes can act like nodes. In other words, you can take simple parts, create a slightly more complex object, then put it inside of a bigger object. Maybe you make an Oil Pan scene and an Engine Block scene and you add those together to make an Engine scene. Which then becomes part of your Car scene, which also has four Tire scenes, and a Wheel scene, which in itself is in a Garage scene... et cetera.
There’s no end to this nesting. You can go as simple or as complex as you want with it. It’s all made in the service of making parts of your game easier to design, reuse, and debug.
For example, you could make a base Animal scene for behavior you know you want all animals to have (like walking, eating, drinking water). Then you make a Cow scene with the Animal scene in it, but now you add some features unique to cows. And a Goat scene that does the same with features unique to goats, a Horse scene, etc. You didn’t have to program in those basic features for each animal because you created that “part” and reused it.
But it’s kind of overwhelming. And the terminology, to be frank, kind of sucks. “Scene” is just a really unnecessarily confusing term. I think it’d be much easier if you called nodes “attributes” and scenes “objects” or something, but I’m sure those words are taken by other game engines so it’d get confusing? I don’t know.
It takes a bit of getting used to. And to be honest, it’s part of why I bounced off Godot a few times. But I feel a bit more comfortable with it now.
So! Signals. Signals are how your scenes (and the nodes within) *talk* to each other. In other words, if we were making Super Mario in Godot, and Mario jumps on a goomba, how do we have Mario’s scene talk to the Goomba’s scene?
The Mario scene has a hitbox node. It detects collision, checks if it’s from the bottom (so Mario jumping on something instead of running into it), and sends out a signal. It says, hey whatever I jumped on, you should probably die now? And the Goomba scene receives that and is like, “Yeah man” and deletes itself. It’s also received by the sound node that plays a fun little noise. It’s ALSO received by the score scene, which increases score, and sends a signal to the UI scene, which is supposed to update every time the score changes.
Or maybe you jumped on spikes instead. So the hitbox node would need to check if it was an enemy you jumped on, or spikes. And if it’s spikes, it’d have to send a message to Mario’s health node to make him either lose his mushroom or die, and that would send a message to the sound node, saying “play either this sound or that sound”. Et cetera.
Once you wrap your head around it all, it’s not too bad. But there are problems like... picking the wrong node for something, because you don’t know what to choose. Or something not working and you don’t know why. Or having to redo an entire thing because you were stupid and didn’t set it up right.
Or... maybe you went about it in a really inefficient way just because you didn’t think about it right in the first place, because programming and ANY software development means learning to think about things in the most efficient ways.
These are normal steps. They’re all part of learning. You can’t really sidestep them unless you’re watching tutorials that teach you off the bat the most efficient ways to do things, but even then, you’re going to need to go off script and make your own mistakes if you want to make games beyond Baby’s First Unity Platformer.
And God, it’s normal, but it can be really irritating when it takes you three hours to do something that feels like it should’ve taken - and will, in the future - only 30 minutes.
For a bit of an odd segue...
I’ve been learning Japanese on and off for a while, and though I can’t say I’m any level of “good” at it, I’m often struck by the parallels between natural language and programming languages.
There’s often this impulse, especially if you’re a newbie, to translate a sentence or sentiment 1:1 into the language you’re learning. A few months ago I was looking up how to say “hello from America” in Japanese, as kind of a friendly “hi, sorry my Japanese sucks ass, I’m a dumbass American” sentiment. It’s a common enough sentiment you hear enough times from other overseas folks that I assumed it was fairly universal - greetings from France, and whatnot. I didn’t really think anything of it.
But Google pretty immediately told me that yes, while you can say アメリカからこんにちは (very literally, “hello from America”), it will always sound artificial and translated because it simply is not a phrase that exists in Japanese. It sounds very normal to a native English speaker, and certainly, the meaning would get across, but it comes across as odd.
It’s sort of like if I said to you, “Not like we’re riding on a rabbit’s back”. From context, you’d probably be able to glean that I meant “We’re not in a hurry”, but it would sound very strange, because that is an idiom that only exists in Finnish, not in English. (Sorry to any Finns if ei tässä jäniksen selässä olla isn’t a common phrase or something, I got that off Reddit.)
In other words, it’s not enough to know how to say every individual word in another language. It’s also about learning the right way to do things. You’re not trying to be a dictionary that translates every word 1:1. You’re trying to learn to think in another language, and abandon your preconceived notions.
You aren’t supposed to think of an English sentence and translate it. You’re supposed to think of a sentiment, a concept, one without language, and in your target language, express that in a way that is natural - as you would in your native tongue.
Programming, and developing in an engine, feels a lot like that.
Programming is not just learning what an if/else loop and a function is. It’s learning to properly consider concepts from the very start, so that you can write them out as efficiently as possible. You have to learn how to break down broader ideas and translate them into code, or code-and-nodes-and-scenes-and-signals-or-whatever.
You have to fundamentally change the way you think about problems. You cannot look at it in the way you’re used to. You have to view it entirely through the lens of whatever tool you’re using. And, using that, you have to figure out the best, most efficient solution for the problem.
And then do that like, 200 times.
And, of course, you can’t learn the most efficient ways until you bang your head against the less efficient ways, and learn why those ways suck, and what ways work for you.
So, then, to the crux of this post: It’s honestly humiliating. And overwhelming. And I took a break for like a fucking week. My first real attempt at working with Godot, and it demoralized me so much that I stopped for a week.
(Pictured: This took me hours, and only one of the buttons works.)
I have trouble with stumbling blocks where if I run into a significant impediment, I get very demoralized and stop. It’s derailed projects for me more times than I can count. I think a lot of ADHD people can probably relate. But the problem is - when you get used to only doing things that don’t involve a lot of failure and risk, it really limits your opportunities.
I just wanted to admit that, like, this is fucking hard, I guess. And it’s okay for it to be hard. It’s okay to be struggling to learn something no matter how old you are. But that I’m not going to give up, either. I made this blog for a reason - to stay accountable.
I am tired of leaving behind a string of failures.
I’m going to go back to watching tutorials, and see if I can’t get a little more insight into what the best way to handle certain things is (like lowering and incrementing stats). Then I’ll come back, and I’ll take another crack at it. And we’ll see what I can do.
And I will probably bang my head against the wall for another 3 hours, and accomplish far less than I’d hoped in that amount of time.
But I will have learned something. Hopefully.
