As promised, I will be more consistent in my blog posts.

This is more of a message to myself than anyone else. But reinforcement does have it's benefits.
Overall in terms of consistency, I've actually been more consistent in working on projects and myself. Perhaps because it's a new year, or at least the start to a new year? Who knows.

I've been super busy in my actual work life, but personal wise - I've managed to dedicate at least a half hour to an hour each day towards either this website or one of my personal projects. Since last post, the "Gibmon" project has been postponed for a little while... I'm instead focusing on a new-ish project, inspired from older projects. But it's small and achievable to complete.

Rock Skipping Game

So it's a nice day. You are at a nice lake. You pick up a small rock. You can't resist the urge to try and skim it across the water.

Basically, I'm making a game about exactly that.

The game is also secretly a test bed for using an event driven code pattern in Godot. It has been a while since I've completed and published a fully working project - and I've almost completely forgotten the proper way to architect games.

But there's a way to overthink it and a way to just get the work done. I'm opting for an approach that's almost in the middle. I create a checklist with a couple of things I need to do to progress the game in terms of hitting those target before release. And then I include at least 1 code clean-up task on that list. I do not make another list until those 2-4 items are complete.

To wrap that up, development is happening consistently fast! So a good start so far. I'm hoping that next months update will be all about the game.

Event Driven Code

Take a seat, it's time to dive into some code. But first, why event driven code?

Why use event driven code?
1. Decouple components without direct references.
2. Organise specific actions through signals
3. Flexibility - multiple services can listen to one event.

Why do I use event driven code in Godot?
1. I'm using C# so events made sense.
2. Minimize direct references between components.
3. More control over the general code flow.

It's simple enough.

You can subscribe to any event and publish any event. Here is a simple example of the struct I use for each event, they all follow the same pattern.

I'm going to continue to use this approach to try and make a small game, and build it for iOS and Android. We'll see if the event pattern is fun to use, or if it's easy to introduce bugs due to the decentralized nature of it.