In terms of sheer lines of code and features added, this was an incredibly productive day for Blorp. A few major things happened:
I am, of course, particularly proud of that last one, because just look at it! It almost looks like a competent game developer made it, and here at disco.zone, we strive to bring you almost-passable video games.
There were many other great strides made today, such as finally fixing the bustness of platform collision, and refactoring some ugly platforming physics code. However, not everything was so awesome.
In my haste to add these new additions, I decided to add a new class,
Session, which holds a bunch of the current game’s state. The
Game object already does this, but the idea is that
Session should basically be transitive and only specific to the current game, and be totally blown away when the game is restarted.
This was done previously for Monotron, where it was a ten-line class that mainly just held the current score. However, in Blorp, I decided that it should also be in charge of more complex state - mainly, the state of the current level. For example, the
Session object holds state like “has the player collected enough fuel to activate their spaceship?” and “has the player entered their spaceship?” This still wouldn’t be all that bad, except it also continues some quite-complex methods to mutate this state (for example, a method to enter the next level and a method to go into the “transition” state), which further complicates it. There’s now very blurred lines between what goes in the
Session and what goes in the
Game, and it seems like it will only get blurrier as more polish is added to the game.
Of course, this isn’t an insurmountable issue, and it pales in comparison to many of the horror stories of mutable state I’ve heard before. Still, I’m somewhat annoyed at myself for not thinking harder about the architecture of the game as I rolled ahead on new features. I’m sure I’ll find myself paying down this technical debt soon enough.