Youbeat

+ Home +

Youbeat

2022

+

+ 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! +

+

+ +

launchpad-dot-net fork

+ +

2022, 2024

+

+ 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.

+

+ +

Youbeat, again

+ +

2022

+

+ +

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. +

+