Systems Architecture Revamp

As indicated in the previous drunken devlog that I barely remember writing, Black Road Sky is finally back on track. Still have one Nubby achievement left to grind, though.

As you'll know if you've been following along, I started the BRS project over last year, but didn't make a whole lot of progress before needing a longer break, so I've just started over again. I know what I'm doing this time, I know what I want the game to be, and I've solved all the major technical difficulties. Now it's just a matter of getting over the terrifying realization that I have years of near-daily work to do. But, like, what else have I got going on?

The work, and therefore the devlogs, will be fairly boring for at least a few months, maybe more like a year. How boring? This boring:

Ship Systems Backend Architecture

Ship systems, and the interplay between them, got very complicated in my last attempt even though I was nowhere close to the final vision. The code wasn't quite spaghetti-bad, but maybe like a nice bucatini. Confusing, anyway. Basically it wasn't vamped good enough, so by god I'm revamping it.

IT'S DIAGRAM TIME BITCHES

Ok, so the diagram kind of makes it look like I'm just making things more complicated, but hear me out.

First of all, the systems themselves are, by design, never calling per-update events (Update() or FixedUpdate() in Unity), instead everything is called by referencing each systems' handler function from a single point, the player ship controller class. So it's trivial to see, at a glance, what order shit is happening in, which is kind of the thing that makes programming hard. This goes a long way towards untangling the bucatini.

Second, system logic and hardware functions are handled separately, which again just helps in managing the logic & order of events. Both system and hardware classes derive from base classes which hold all the common stuff like general health stats, repair functions, cockpit button interaction handlers, and so on. Nice & clean.

Finally, the actual hardware stats (thruster power, response time, durability, and eventually things like cost) are held in logic-free stat blocks, glorified plain text files that Unity calls scriptable objects. That means that I can quickly & easily create new hardware components with just a few lines of text, and maybe even open it up to modding. Not sure about that, though, probably shouldn't even have said it.

I'm also doing a better job of commenting code for future me, who as it turns out is kind of a dunce, and following best practices for Unity-specific things. When I started making this game it was my first Unity project (I mean, I guess it still is), and I couldn't have given half a fuck about whether a variable was initialized in Awake() or Start(). But here I am now, giving a bunch of fucks.

Coming Up Next

More exciting diagrams and shit, probably! And I'll let you know if I 100% Nubby's Number Factory, but I've been pretty distracted lately by My Summer Car. Got a lot going on over here.