So this is an experimental game I'm making for Bullet Hell Jam 6.

I've participated in the jam's earlier incarnations, and in fact, my entire BUTTERF.EXE series got its start there back in 2020. There's 10 days in the jam and we're at the halfway point, so to accompany today's new playtest build, I thought of writing a little devlog about my creative process so far.

This is where we're at right now. How did we get here?

Bullet Hell Jam comes at an opportune time, I've just been on a creative game design streak and started a couple of new projects exploring some unique gimmicks. This project inherits the Lost Century palette from Juggleflask, and there's still some of its sprites remaining in TIC-80's sprite memory too.

It's a good palette.

I do have ideas for future BUTTERF.EXE games, but I went into this jam without planning anything in advance. So when the theme of 'Unstable ___' was announced, I surrendered to it. It made me think of transformations, like perhaps your character changes its shot type often. Or perhaps the bullet patterns themselves change. And that train of thought lead me to this whole 'editing source code' idea. (Which I am willing to bet is entirely unique in the bullet hell genre.)

This game has a target audience of like 3 people in the world.

As always, taking such an idea into a playable game was a process of much fumbling around. I couldn't possibly have extrapolated the current state of the game when I only had an empty TIC-80 project. So there were some really stupid phases like using graze to switch what variable you're modifying. (Dual-purpose mechanics like that always sound attractive, but when tested with actual inputs, it meant you had no control over making the necessary precise adjustments.)

With my programming experience, I had no trouble actually implementing the functionality I'd decided on, and already had a proof-of-concept build submitted within the first 24 hours. The first builds of the game were kind of sandboxes with some content but without any kind of goal. Sure, you can manipulate the attacks and maybe end up with patterns that have aesthetic value, but what is it you actually do in the game?

To answer that, I decided on chasing achievements that are themselves expressed via Lua code.

Once I got started, the ideas just kept flowing.

But first, I needed some way to access the content of the game, which seemed to naturally become structured around individual stages that had separate patterns - rather than a traditional Touhou gauntlet of overlapping attacks.

I could've implemented a menu where you choose a stage from a bunch of preview images (like I did with Blueprint), but this game refused to do something so predictable. Instead I implemented the stage select screen with the building blocks I already had. (Games that do this are called 'diegetic'.)

Just using it teaches you how to play.

Then I ended up pivoting from multiple simultaneously available achievements to a linear quest system. I think this was the key ingredient in making a properly progressing game about the concept, so I'm glad to announce that today's update introduces functional quests!

Pictured: non-functional quest.

To accommodate the newly found progression, I added a separate music loop for each quest. In the context of the gameplay this gives a sense of escalating danger.

But something really surprising happened when I coded some procedural music for the stage select screen. You see, in TIC-80 you can produce audio by poking values directly into the sound registers in the RAM. But my code had a mistake that went out of bounds and corrupted the waveform data. This made quest music sound different after you've visited the stage select screen!

Original compositions: https://vocaroo.com/1kg9x389yaOj
Corrupted tracks: https://vocaroo.com/1dAPtZUaRjwg

I ended up liking the corrupted tracks more than the originals, so I made it a point to purposefully corrupt the waveform data even when you're skipping the stage select screen by resetting. So that was a glitch that became a feature, or perhaps a happy little accident.

Speaking of resetting, I realized I'd also have to have a savestate/checkpoint system, since it was really punishing to go back to quest 1 every time you die. In TIC-80 you have the persistent memory which holds 256 unsigned 32-bit integers. Now I'll need to save how the variables in the bullet pattern have changed in later quests, and this difference in values can be negative, which can't be stored in an unsigned integer, so...

What other option did I have? I'm telling you, it's good programming practice.

Alright, so I've got the game working and it's got all these bells and whistles in it, now I just need to export the project as--

Et tu, Brute?

There's something wrong on my end but I haven't been able to figure it out. Usually TIC-80 is reliable but lately it's been acting up like this. If anyone has any insight on this I'd like to know!

Okay, but I've been babbling for too long about what's happened so far. There's still 5 days left in the jam to make further improvements. I plan on adding more stages/content, as well as persistent rewards for completing quests to further motivate the player. And I'm always polishing based on playtest data I get, so if you try this game out, I'd like to hear what you think were its strong and weak points!

Bye from me and keep dodging!