3 Sep 2015
August 2015 - Scale Training Torture Device

One thing that I've never done since I started 1GAM is quit a game after it reached a playable state. That's the battle, the hard part. The rest is fleshing it out, adding content, polishing. That is not what happened this time. I saw a free and open MIDI interface library for Unity, I looked at my MIDI keyboard, and I figured maybe it was time to try that combination out. Once it was playable, I stopped immediately, and decided to learn and move forward, because I'd created something that I would never play, that I would hate to play, that I would be angry with someone for making me play.

It is for these reasons that this month's project has been branded the Scale Training Torture Device.

An Auspicious Beginning

I'd thought about doing something with a MIDI controller before, but had never pulled the trigger on it. I was also doing most of my 1GAM projects in Unity, and native libraries, which would be required for MIDI access, were a professional-only feature. My hobby gamedev habit was in no way enough to justify the price of a pro license, so that was that.

But earlier this month, I was pointed to Keijiro Takahashi's impressive collection of open source Unity components and libraries, including MidiJack, a Windows/Mac library for simple for reading MIDI input. It seemed the time had come to experiment with MIDI.

Making Noise

The first task it seemed was just to make sure I was reading the MIDI input correctly, using it to generate notes, and representing it in some visual way as well.

MidiJack turned out to be satisfyingly simple - following the same pattern as Unity's Input.GetKey/GetKeyDown/GetKeyUp, MidiJack exposes MIDI input as MidiMaster.GetKey/GetKeyDown/GetKeyUp, with GetKey returning a float representing the velocity of the note input, as well as GetKnobNumbers and GetKnob to enumerate the available control knobs and read their values. Worked as described, almost immediately upon being added to the project, and I'm 100% happy with that part.

Making sounds was a little more challenging with my total lack of knowledge of digital music tools, but luckily after some false starts I wandered upon the University of Iowa's Electronic Music Studios and their collection of musical instrument samples. With a little trial and error and educating myself on how to use chains in Audacity, I ended up with a satisfying array of instrument samples covering three octaves with two different instrument types. So that went well.

Representing the input visually could go in a lot of directions, but I wanted to start by attempting a very literal interpretation, creating a piano-style keyboard on-screen that would show the player's inputs, including animating the keys and highlighting pressed keys. I jumped straight into Blender with optimism that was in no way justified by my experience of knowledge of such, and somehow, miraculously, I ended up with an entirely serviceable piano keyboard. So that made three unmitigated wins in a row, and things were looking good.

Actually Doing Something

I knew I didn't want to go with the obvious Guitar Hero/Rock Band rhythm game structure, what with the need to actually generate song data to match audio and get the timing exact and all that just to clone an existing game. The idea of each key having a lane seemed a good start though, and I started playing with the idea of each key launching an object in its lane and how I could incorporate the instrument sounds into the gameplay.

Long story short, I ended up with a very Missile Command kind of situation, where hostile objects fall from the top of the screen, and you use the keyboard to fire your owb projectiles in the appropriate lane to intercept each one before it reaches the bottom. I gave each side an instrument, with the hostile objects announcing their arrival with a trombone note, while the player's projectiles use piano samples. Start spawning objects, add collision handling, and we've got a mechanic here.

There wasn't a lot of lasting challenge there, so I had the idea that the lower keys in the supported range, the C2 octave, would determine which key the player was in, and only the notes that were in the major scale of that key are available to play, with the rest being disabled. In order to intercept all of the incoming projectiles, the player would have to listen for key changes, announced by a bass trombone note of the new key, and try to match their key to make the appropriate notes available. Add some simple logic to generate the incoming notes, change keys periodically, increase difficulty over time, and add one of those "here's how well you're doing on a scale of good to fail" UI elements, penalize the player for hostile objects that aren't intercepted or notes that leave the play area without hitting a hostile object, and we've got a game.

What Fresh Hell Can This Be?

Here's the problem - what a miserable game that is. You start out in C major, playing your natural keys, intercepting those hostile objects, getting points, feeling good. Then the key changes. Hope you caught that note, because now you have to figure out what key to switch to, and until then you'll have projectiles streaming down the screen while the keys to stop them are disabled. Where in this horror does the fun lie?

I thought about several ways of dealing with this, like visual cues of key changes, or telling the player what their target key was until they'd progressed further, but it all seemed like unsatisfying patches to an unfun mechanic. I can't imagine anyone playing this game without being forced.

And Whither Unity?

As a side note, having done most of my digital game dev in Unity thus far, it was with no small degree of shock that I realized this was my first 1GAM project created in Unity since December. I still work on tabletop game ideas, I've done a couple of Twine projects, and one Unreal game, and I've been experimenting with getting back to my low-level coding roots (I was catching up on Handmade Hero for a while there, and I wrote my first functional TRS80 Model 4 program in Z80 assembly last month), so that's probably part of it. I think I've also been waiting to see how things shake out with Unity for simple game distribution - the writing is on the wall that the plugin won't be a viable option going forward, and the WebGL export is still experimental, so part of the charm of Unity, being able to easily put up a playable game without requiring people to do a full download, is gone, at least for now. Unreal is powerful, sometimes too powerful if that's possible, and it's nearly impossible as far as I can tell to use it for anything that isn't a Great Big Thing. Maybe that's my inexperience with it talking though. For now, I guess I'll keep plugging along in whatever seems appropriate at the time and see how this all turns out.

The Verdict

It's a game, it's playable, I learned lots of stuff and was happy with the process of creating it, and if you want to give it a shot, brave soul, feel free, and don't hate me when you're done.

Note: the OSX build is available for testing purposes but I don't have the ability to test it. It's a Unity build so I don't anticipate any serious issues, but I can't vouch for correctness or performance of this build.