A couple of days ago, I properly wrapped up work on Honeycomb CRUNCH and moved back onto Hive Time. The final build has some new sounds, some scoring adjustments, and some tweaks to the bee collision area. Most of these are in response to watching player experiences/listening to player feedback, and I think that they make the game a bit stronger.

Inspirations

Earlier in the day, I also streamed Honeycomb CRUNCH, talked about development a bit, showed off some of the assets, and played a little bit of Frank Neuhaus' 1987 Amiga game Swooper as well.

I've mentioned elsewhere that Swooper inspired the core of Honeycomb CRUNCH's gameplay. Its meteor field sequences were little bonus levels between stages, but they were always the most interesting and enjoyable part of the game for me.

Tracking the movement of many asteroids and projecting ahead to work out which gaps were safe and which weren't was an interesting an engaging challenge for a young Cheese, and replaying the game for the first time in years, I still found it fun.

While mechanically, there isn't much difference between Honeycomb CRUNCH's hexagons and Swooper's meteors, or between the flower and the astronauts, both games end up manifesting similar concepts very differently. Honeycomb CRUNCH explores some of the ways that the meteor sequences in Swooper made me feel, but it has a very different feel in both an aesthetic sense and a gameplay sense. The influence is still there though, and I think that's worth touching on.

It's kinda rare for people to talk about their inspirations in this industry, which is something that I lament whenever I get the chance, and something that I put conscious effort into making sure that I don't do. In my eyes, our works are enriched by their heritage - everything we make draws upon our experiences and feelings about things that we've come across in our lives, and to hide or suppress that feels problematic in a bunch of ways.

Firstly, it fails to respect the power that others' work has and the impact it's had on our own feelings, but more importantly, it suggests to future people who're making stuff that all of their work should be born of the void, that making derivative works is something to be ashamed of. It contributes to the prevalence of imposter syndrome, makes it harder for people to have positive relationships with the stuff they make, obscures important paths to skill growth, and makes it harder to view works in their historic context/to appreciate their cultural influence.

Legacy

Looking in the opposite direction towards the future, I may have shipped what I intend to be the last Honeycomb CRUNCH build, but that isn't the end of the story. In addition to whatever impact it has so far as a learning resource or in encouraging people to explore game development, it will also result in improvements to the tools that are available to developers.

I've already had two Godot pull requests merged with code and documentation improvements, and will submit more as I have time. While neither of these are particularly important or stand-out changes, they still incrementally contribute to the engine's usability.

The first changes the API for Camera.project_position() to allow a depth value to be passed in. The function is intended to allow 2D window coordinates to be converted into 3D world coordinates. The function was written before the engine was open sourced, and so far as I can tell, it never really got much use - possibly in part because without the ability to provide a depth, it wasn't very usable (without resorting to a fairly dodgy workaround).

The second corrects some copied and pasted documentation. It was likely clear from context what those values were meant to be, but it is the kind of thing that makes you stop to double check that you're reading correctly, and addressing even that small friction point has some small quantifiable value, both in speeding up work and in making documentation feel more complete/reliable.

I also have an issue open raising some more documentation improvements for discussion. Another small issue, this time helping clarify what AudioStreamPlayer::set_pitch_scale() does and how the pitch_scale property works. Initial versions of Honeycomb CRUNCH were throwing errors because I had the false assumption that a value of 0.0 meant no change, when it turns out that pitch_scale is a multiplier, and 0.0 is an invalid value (1.0 means no change).

And that's about it for Honeycomb CRUNCH. I'll likely do an update when the next version of Godot ships so that I can get rid of some workarounds. At that time, I may or may not feel motivated to make some gameplay additions, but for now, I'm feeling pretty happy with the state of the game and its outcomes.

Honeycomb CRUNCH has been a lot of fun to work on and to play. I hope it's been an interesting diversion for you as well ^_^

- Cheese

P.S. I also want to give a big thank-you to all of my Patreon supporters, who're also listed in the game's credits. For their support and patience while I worked on this game instead of other things :)