Project Betelgeuse Developer Diary 007 (Patreon)

Hello everyone. I’m a little under the weather at the moment and have spent the last two days trying to decide how I should update you all this month. The indecision is costing me so much time and energy that I think it’s best if I do this basically as a stream of consciousness. I’ll try to update you on some happenings but I want to write this as fast as possible so it might be a little unrefined.

After the huge collision wins last month, I started this month by putting it through some further testing. The code to handle bounding box changes was added very late in April but it held up well. Once I was satisfied with that, I added semisolid platforms. (Platforms that allow you to pass upward but not downward.) Although I make regular backups of the project, I have almost never had to revert to an earlier version. Semisolids are the most notable exception. This was a feature I had actually tried to add twice before but the results were so messy that I ended up reverting in both cases. There were a few challenges there.

Firstly, it’s not merely a matter of blocking the player from moving downwards since the tile also needs to correctly signal when an actor becomes grounded. Many state changes rely on this transition from airborne-to-grounded so it needs to only happen at the top of the semisolid, even though the semisolid takes up a full tile like anything else. (If you’re having a hard time imagining this, picture a jump which just barely doesn’t reach the top of the semisolid, most of the character is above the semisolid but we only want them to become grounded when their feet rest on top of it, meaning it has to be very precise.)

Secondly, since I already wanted slopes and semisolids, I figured it would be cool to get sloped semisolids working too. It’s not hard to envision cases where this might be useful, like staircases or uneven ledges.

Thirdly, I wanted to ensure that the addition of semisolids had little performance impact. The performance gains last month were hard-won. Part of the motivation for gaining ground there was so I could add more features but I still wanted to be careful about how I spent all those extra frames. Thankfully, I found a method which exceeded my expectations. It uses more memory and adds up to a frame’s worth of delay when entering a room (while the screen is covered and the player can’t even notice a hitch) in exchange for no performance impact during gameplay. Overall, it feels like a big win, especially since it thwarted me twice in the past.

As far as I can see the only remaining collision stuff which needs to be tackled is moving platforms or doors. Given Mushido’s (relatively) grounded aesthetics, these will probably be rare, maybe even non-existent, so I figure that can wait.

That’s another thing. While I was streaming yesterday I accidentally revealed the name I’d like to use for Project Betelgeuse: Mushido. For those who might be puzzled by this choice, it’s a play on the term Bushido (武士道) which means “way of the warrior”. Mushi (虫) is the Japanese word for insect and the “way” part of Bushido comes from the “do” which means that (unless I’m mistaken) the “mushi” should slot in pretty nicely to become “the way of the insect”, which looks like this in Japanese: 虫道. Whether it actually makes much sense in Japanese doesn’t really matter, I think it’s a cool enough name that we’ll use it. I’ll be calling it Mushido from now on.

Moving off Mushido for a second. I actually returned to Project Proxima this month since I figured now was a good time to update it to all the systems I’ve built since. It pre-dated even my work on the state machine but now it has that and the new collisions, including semisolids. I spent a few days tinkering around with the gameplay and made some good additions. It’s much more compelling now than it was before and might be worth pursuing as a project already. Still, I do have some misgivings which are holding me back. Some of you might have predicted that my exacting standards would be a hindrance as well as a help. In this case they’re being a hindrance but I’m still not ready to give up on them quite yet. I think if I keep experimenting I might find a way to sidestep my issues or otherwise make the game compelling enough that I’d finally be willing to let some things go. I’d be more specific but I still want to keep Proxima under wraps. It’s still a very appealing project since it would be nice to put something out and maybe generate funds and momentum to help carry Mushido. Unfortunately it’s just not there yet. I’ve returned to Mushido and will simply tinker with Proxima on the side from time to time as ideas arise.

Once all that was done, I deleted Victor. I still maintain that implementing him was the single greatest decision I’ve made so far. He presented a sudden spike in the complexity of what I was trying to achieve which sparked all the work on the state machine and helped to put collisions through their paces as well. He survived longer than I would’ve liked but he’ll be missed all the same. May he rest in peace.

This means we now have a samurai, although not with proper art yet. My partner made a bunch of different actions for him but she did them all within an hour so they’re very rough. The flea is getting proper sprites first since it seemed like a smart idea to start small. This small scale has actually been frustrating though and she’s now looking forward to working on larger creatures instead. I expect the pace of progress here will be slow for a while as she gets used to spriting so please forgive us if it takes some time to see results.

Even just placeholder samurai sprites have been enough to allow for prototyping actions and exploring what’s possible. In a previous post I discussed the idea of conveying the player’s health state through the character’s standing stance instead of a UI. Over the past few months I’ve been playing a bunch of games with a particular emphasis on action platformers as I search for inspiration and try to clarify what I do or don’t like about existing games. For example I recently played through the entire Blaster Master Zero trilogy. I don’t know how fruitful it’s been overall but just the other day I got inspiration from an unlikely source.

I didn’t expect Dragon’s Crown to be relevant, I just wanted to play it recreationally but I noticed that the dwarf moves forward at an uneven pace. His animation has a huge amount of swagger so to emphasize it even further, his underlying movement speed changes from frame to frame as well. In my nomenclature this would be called a “looping impulse” which Mushido didn’t support as of last week. I had considered adding them before but hadn’t thought of a good use case to justify their inclusion. Well, seeing Vanillaware do it lit a fire under me and I finally added them which thankfully was easy since the existing systems are quite extensible. Long story short, we have looping impulses now and I thought our samurai seemed heavy enough that he might benefit from a slight wobble to his walk, to sell how powerful he is. With the temporary sprites it somehow gave the impression of a limp though, which got me thinking, if the player starts limping (or otherwise walking in an injured way) after they take damage, that’s a little bit of nuance and it becomes a lot more clear what the current health state is. I’ve added that as a new condition and it feels pretty good to me. This also further incentivises players not to get hit and might lead to a nice comeback feeling if you manage to survive while in an injured state. I don’t know if this will remain all the way to the final game but I like it right now and whether we keep it or not, it just goes to show that inspiration can come from anywhere. I’m trying to keep myself open to these kinds of opportunities. As a bonus, I quickly found a second action where looping impulses really helped but I’ll talk about that one another time.

The most recent addition to the project is arguably my first foray into tools programming. Mushido now has a tool I can use to quickly determine the offsets and sizes needed to spawn hitboxes in a particular place. This allows me to get perfectly precise results, although naturally spawning more hitboxes does incur a performance cost at runtime. This is like a little mini-game of its own where the goal is to figure out how to cover a shape in the fewest possible boxes but it’s still a massive improvement over the painstaking process it was before. I was typing in values by hand and trying to line them up with good guesses. By contrast, it only took about a minute to generate the hitboxes above.

Finally, what we’re working on right now is enemies. Specifically, I decided it would be a good idea to create the most complex enemy we could to push the system as far as possible and also explore whether it becomes too much for a player to handle. I’ll save my full reasoning for another time but suffice to say, I’m interested in the idea of enemies having a multitude of actions and whether this is something we should try to emphasize. We have a very complicated one in mind and are starting to prototype it. That’s where we are right now. Hopefully by the end of next month I’ll have more enemies mapped out and a stronger prototype of the player character too.

After combining all of the work so far it feels as though I’ve answered at least one question. Can I make a game? The answer to that is now obviously yes. Can I make a good game? We’ll see.