Skip to main content

🇬🇧 they/them, it/its 🇩🇪 es/ihm

A Different Look at Componentization in Godot

So one thing that I've noted before, often unprovoked to an unwitting audience on mastodon, is that there are a good number of tutorials on how to get started using Godot for people who already know a bit about game development. Two areas that are lacking however, are basic fundamental learning materials for an absolute beginner framed within the Godot engine, and more advanced guidance for how to structure a larger project. We're here to talk about the latter today.

Two sources that I drew upon for this are The Shaggy Dev's video on his video on the design of his tactics engine and Firebelly Games' video more directly about composition in Godot. I highly recommend giving them both a watch if this is a topic of interest to you.

So looking back on Counterspell, which I worked on over a year ago, and the various little side projects I've done since I was essentially doing an inverse version of this structure.

Comparison of the scene trees of the Skeleton Warrior and Skeleton Archer entities, which differ only in terms of sprites and what script is attached to the Brain node.

What I did was make the root entity (Skeleton and SkeletonArcher) the generic object, and had it turn off of the Brain object which handled the glue and awareness of what was going on. The CharacterBody only needed to know that there was a Brain object at that path, and what its contract was, but didn't need to know much else.

In theory, this is fine, but you might be wondering, if the Brain is called by the CharacterBody, and drives everything else, isn't the CharacterBody dependency kinda backwards? And yes. Yes it is.

The different actions by the brain could be split up into state handlers in your favourite node-structured state machine (here's mine) but I think for my next project I'm going to use Firebelly's approach of writing the state machine inline on the root object along with the rest of the glue.

So the tree you'd end up with would be something like:

+ Skeleton (SkeletonWarrior.gd that contains the glue and FSM)
|-+ CollisionShape (For walls)
|-+ Sprite
|-+ AlertnessComponent
| |-+ AlertnessVisuals
|
|-+ HurtBoxComponent
| |-+ HurtboxCollider
|
|-+ HealthComponent
|-+ CorpseComponent
... ect ...

Again, not apparently necessary for a game the scale of Counterspell, but I am eventually looking to make larger games with more than just myself, so these are things I've been thinking about quite a bit.

The next project, by the by, is finally taking a look at the wii tanks clone I started on a year ago but haven't been bothered to finish. I think this structure will also make creating the different tank behaviours a lot easier than the Resource based Brains I had before, as well as Godot 4's better handling of custom types in general.

Thanks as always for reading my strange ramblings.