Home

A while ago, I wanted to adapt arcade game Jubeat for home play, using a device called a launchpad. So I bought one. It looks like this:

a
              product photo of the novation launchpad mini mk3. It's a
              keyboard-like device made up of a grid of translucent RGB
              squares.

Jubeat is a rhythm arcade game by Konami in their Bemani line. It looks like this:

a
              product photo of the konami's jubeat arcade cabinet. It's a
              big box with speakers, a small wide screen, and a 4x4 grid of large buttons.

The grid of buttons are each separate note inputs, and the screen above it actually extends below the buttons. The notes for the beatmaps are shown beneath each button you need to press. it looks pretty cool, but naturally it's hard to play at home (ignoring that it's 'illegal' to play at home because piracy, but like, who gives a fuck on that front).

Now, with a bit of RGB magic, you can kinda get an approximation of the inputs for Jubeat on a launchpad. So... why not do that?

Thing is, it ended up pretty involved. Like projects tend to do. First port of call was talking to the launchpad from my language of choice, C#. The launchpad is controlled over MIDI, with regular input messages used when you hit a button, and output used to tell the launchpad what colours to light up. There's also a few sysex messages for stuff like changing mode, how quickly the LEDs pulse, etc.

As I always do, I checked Nuget and found - well, nothing. So then I searched github and found a perfect[ish] package called launchpad-dot-net, from a user called iUltimateLP. Unfortunately, it didn't support my model of launchpad, only earlier ones, so before I could write the game, I had to rewrite the library to support my launchpad. That's right, baby! It's a project within a project!

So I bought a midi device called a launchpad - it looks like this.

Image removed. That's enough of that - Ed.

OK so I've done my funny joke but honestly there wasn't much to this other than adding branches in the code for the new model of launchpad. The previously supported models also didn't do full RGB so I added the commands to fully control the LEDs specifically for the mini mk3.

Forking this actually turned out to be really useful for my future work on LPHotbars so I'm glad I did it, and I even did my due diligence of PRing my changes to the original repo. Still pending, that one. After a week-ish of no response from the original dev, I packaged it up to Nuget and shipped it for future use. Since the original dev never stuck the library on nuget, I felt that was... ok? I did worry about it at the time, but the original library is abandoned, so probably fair game.

Then, later, as mentioned, I picked this up again for LPHotbars. In the meantime, a very kind person called pstaszko had ported the library to dotnet standard 2. Which was pretty damn convenient, because over the course of 2024, Dalamud - the modding framework for Final Fantasy XIV - started targeting dotnet standard instead of some old version of dotnet framework.

Since I was in the code, I also added a testbed app, which allowed me to discover a bug - the CC keys (all the labelled keys in the image above, the ones around the edge) and the SYSEX calls stopped working, so I had to fix those up.

I also experimented with replacing the midi library, in an attempt to support linux. It wasn't successful, honestly - doesn't seem like any underlying midi libraries for c# actually properly support device comms on linux.

Going one deeper and forking an actual midi library to add this support was out of scope for what I was working on and would have ballooned the project, so instead I just abandoned the cause. Maybe one for the future, it would be nice to offer linux support for LPHotbars considering how nice XIV works on Linux/Steam Deck.

OK, back to the main project.

an in-game photo of youbeat, showing the game screen and the launchpad in action. 
                  buttons on the launchpad are lit with different colours to demonstrate how close a note is.

So once I'd rewritten the launchpad library I could actually make the game. I have never really got on with game engines - I'm largely a pure programmer, and my experiments with unity in the past have massively frustrated me. (Unity is a fucking nightmare. Has anyone else said this? JK I know they have)

So instead I looked for a minimal library that would do the video-gamey-relevant stuff (directx instance, drawing, etc) and then just get out of my way.

To that end, I found Otter2D, now sadly discontinued. It was written by kyle pulver, who has worked on a bunch of things you may have heard of including super meat boy forever. Otter2D is exaclty what I wanted and so naturally it crashed and burned to the ground like Icarus, a library to perfect to exist.

But before that happened, I used it for Youbeat. And it was really, really nice! Drawing stuff to the screen was a one-line affair, transitions and tweens were simple to add and there was reasonable variety to them, and the library itself was flexible enough that I could build a game that primarily functioned on an external device without it complaining.

This has always traditionally been my problem with game dev. With otter, I could just write code, like I always do. I'm pretty good at writing code, and I'm pretty rapid too. My experience with engines has largely been them slowing me down and getting me away from the stuff that makes most sense to me. They're like wading through a bog.

As a result, this is the first time I've ever really completed a game. This was admittedly helped by me not really doing any level design or such, and while I did make some art assets for the menus there was no extensive art necessary, something I have always got stuck on. I know that's what programmer art is for but my ambitions for games tend to extend past prototypes and so it presents something of a psyche barrier.

I also built a very barebones mapper! Partly so I could make my own beatmaps to test the game with, but also because I firmly believe that a good rhythm game always provides a mapper. The rhythm games community is pretty tight-knit and thrives on the free exchange of ideas and code, and so you will find that all the best rhythm games either ship with a mapper or release one shortly after they come out. It's extra work but it's good for the health of the game!

I will admit that the mapper does kind of suck, though. It's a horrible archaic winforms app, but it does the job. I think if I wanted to dedicate more time to the project this is where I'd start. Ultimately though I am a firm believer in Zack Freedman's Finish More Projects mantra. When it comes to stuff you're doing for yourself, done is always better than perfect.

Anyway. While it may look a bit ramshackle now to my more senior eye, this project taught me a lot about designing for weird hardware, a lot about how games work when you don't have an engine choking you, and a few nice tidbits about nuget and such. Worthwhile! And hey, if you have a launchpad, you should check this and LPHotbars out. I'm really proud of both.