What's this? a devlog for a game other than the changing prisoners dillema? WHY YES MY DEAR READER IT IS! This is the first devlog for Bimbo Blaster! A game originally brought out in 2023 by nathan alone! A few months ago we announced the new updates would be coming. Well now we are happy to actually inform you on the goings on. So let's start at the beginning

Destroying the spaghetti

Bimbo Blaster was originally written and drawn within a single month. As nathan says, it was a personal challenge for him. If it worked it worked. This is great! if you don't plan on expanding, but it leads to a lot of problems down the line. The first few months on this project was mainly spent reading, reorganizing and improving the old code. Now, how does one go about that process? Simple enough really. You grab a pencil and a piece of paper and begin to draw the connections! THe following image is the simplified result of the game as it was.

Now this is what programmers like to refer to as Spaghetti code. Why? because it crosses in a lot of places, is not easily trackable, and with enough it looks like spaghetti. Again it worked and that was enough, but to have this be manageable and expandable for new sections of the game it.... really does not. A few problems to fix are: Every component tracks the gamestate locally without a variable, There are lines going fricking everywhere, there is no clear hierarchy So how do we proceed from here? Do we disentangle it line by line until we have something manageable? NO! the first solution that comes to mind is often one of the worse. No instead we take the components as they are and draw new lines. First things first we have a nice and handy game manager. Which is supposed to well... manage the game. So why don't we add a gamestate variable to it? A single source where all components can get the required information from. While we are at it, let's make a few events for when the game state switches. Going from pregame, countdown, playing, paused to victory and defeat. Giving us an easy way to change behaviours and a way to track down errors. Now let's start the countdown using the manager. When the countdown ends we can go back to the manager who switches the gamestate to playing. Giving that to the hud, player and score (which should be score hud. Oopsie) components. The score variable is another problem as well. It's tracked in a few different places that all need to match. Well... that is a problem. We want just one place where the score is tracked. Prefferably in a place every component already OH HEY WOULD YOU LOOK AT THAT A MANAGER! That's right. We just plop the score in there and VOILA

A clearly readable, followable and clean diagram of the various components working together. We can even add more things to this with ease. For example an enemy spawner that starts spawning when the game starts and gives back when there are no more left, and an enemy class that gives back a score when defeated

Now for those wanting to do this themselves there are 2 things to keep in mind.

1. Your manager should not become an 'everything' class. Keep it to the essentials where a lot of components need to access a single variable or event. You'll see that when the enemy or player deals damage it bypasses the manager and just goes directly to the other. They calculate their own scores and then give manager the result.

2. There should always be a single source of truth (simple explanation here) for shared variables. Score, highscore and the resultscreeen all need access to the score. Meaning it should be stored in one of them or none of them. Seeing as there was already a manager present it should be none.

Now the final part is to implement this! which was most of my early work on the project. but now we can blaze through adding in other things! With that knowledge i'll leave yall for now! Look forward to next month when we'll be posting the new version of bimbo blaster! ALICE AWAY!