# Overview
A multi stage shmup complete with bosses and 2.5d graphics!
Designed to look like something you would have found in a corner at comiket a couple decades ago, we went all in with the aesthetic here including entirely untranslated dialogue.
![]() |
![]() |
What a trip this was. We had three artists for this one, which is a record for us for sure. The division of labor was pretty easy though, so it ended up not going too horribly wrong.
As always, the Ludum Dare entry page can be found here.
# Design
A bunch of my early LD games were shmups, but once I started working with Kiri, I hadn’t touched the genre since. Frankly, it was probably for the best, my old shmups were bad, and it’s a cursed genre as far as balancing for a game jam goes… people who are good at them want something really, brutally hard, and everyone else is going to explode on level 1 even in easy mode.
One of the biggest lessons I’d learned through the years of making bad shmups was that you really, really need to hand craft your levels. This lead me towards a rather cursed UI to build the levels. This worked out fairly well, and having one interface to place enemies, backdrop models, and set story points all in the same context was a pretty comfy workflow by the time I got everything working.
…Of course, this was like 2 hours before submission, so the level design end up being a lot of copy paste. Sorry!
# Tech
3D in heaps has always been a faustian bargain. The FBX loader is some wholly hand rolled thing done by the main dev that only really works with Maya files (and only supports the features they use, with a very specific export workflow). Coercing blender to produce compatible files is infuriating. One minor change to a model can totally break its export and reverse engineering which random button you pressed that angered the importer can be a huge time sink. Not great in a jam!
As a result, we ended up keeping the 3d content very simple. Just simple static props with textures. No skins, bones, or any of that malarkey.
One of the biggest wins was the use of Imgui. Building the level editor was surprisingly straightforward. The code was godawful and the interface was nonsensical, but it just had to work, and it very much did. Since the code runs inside the game render process, you could literally just jump to any place in the level from the editor, and play from there. It was super convenient, and another example of how “bad practice” decisions can save tons of time in prototyping.
10/10 would do it again (and I have with other tools, heck this was a core feature of the Flow system!)
# Play
You can play the latest version here