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.

If you’re not too familiar with raising sims, they’re a simulation game subgenre where you aim to increase stats of a character, usually with a time limit to do it in. Examples are Princess Maker, Long Live The Queen, My Lovely Daughter, Cute Bite, etc. Typically you’re raising a child to adulthood, but not always.

The appeal is the novelty of choice, as well as the various events and endings you can get. Perhaps raising your daughter’s strength makes her get a rival who wants to fight her, and she might become a swordsman at the end of your playthrough. Maybe she’s not very smart so she only becomes a lowly bandit. Raising her elegance and intelligence could get her a spot in the royal guard. That sort of thing. There’s lots of replay value, obviously.

Complications are added by having to manage a character’s stress, the fact that tasks typically decrease one stat while increasing another, and that there are undesired outcomes such as increasing a stat *too* much and locking you into an ending you’re not interested in (perhaps because you got it before).

(Tokimeki Memorial is another example - while it’s typically considered more of a dating sim, the stat juggling aspects are quite similar.)

So, this arguably being my favorite genre of all time, I decided that perhaps this is what I need to focus on and develop a longer-term project.

I was quite intrigued by My Lovely Daughter, which I played recently. The game is about trying to bring your daughter back to life by creating artificial homunculi daughters, which you then sacrifice. The novelty of having not one but multiple daughters really struck me, because I’d never seen a game do that before. I also found myself really wishing I could keep my daughters alive and raise them as I pleased.

Thus came the spark of inspiration. A game similar to My Lovely Daughter in that you create and raise multiple girls, but more like Princess Maker, where you raise the girls to reach their own happy endings (rather than murdering them for your own ends). Princess Maker but on an accelerated timeframe - raising several daughters at once, potentially over a dozen over the course of an entire playthrough.

And that’s how I decided upon the basic concept of my game. Theoretically, and that’s a big “theoretically”, it shouldn’t be too hard to keep track of all their stats using basic coding things like dictionaries. But... I am a little concerned about the scope of the game.

“Scope”, if you’re not familiar, is a gamedev term referring to how big your game is, in the sense of how many features it has and how long it takes to develop. Something like “it needs a lot of endings” can very quickly spiral into an unmanageable amount of work for one person. And it’s very easy to succumb to “feature creep” - when you have a really cool game idea and you go “and it needs this, and this, and this...” and as a result, it never gets done, because you’ve penciled in way too many features to add.

So I’m working on figuring out the ideal scope. And that’ll probably be the topic for my next post. I also want to make sure the game is unique enough to stand apart from its influences - I don’t want to copy anyone wholesale.

Dealing with the skeletons in the genre’s closet

It’s worth noting that, like I talked about in my last post with Princess Maker, raising sims have often had weird and gross shit in them. In general, the idea of “you have total control over this girl’s life” has been a weird power fantasy for a lot of men - these games are historically aimed towards such men, and there are sometimes some weird... creepy... borderline pedophilic things in these games as a result.

It wasn’t really until the kids who grew up on PM2 seemingly got older and started making their own games (like Hanako Games’ contributions to the genre, like Long Live The Queen and Cute Bite) aimed at more general audiences that these games started getting less creepy, seemingly, at least in the west.

(For all I know they’ve been very diverse in Japan, but most of those games don’t get brought here, unfortunately.)

It is very important to me that any game I make not have any gross shit in it. I mean, I don’t mind the concept of adult content in games, to be clear (not that I plan to have any in this game) - but there’s “sex between consenting adults” and then there’s “you can dress your daughter up in skimpy clothing for fun! and also marry her!”. Ew.