Note: The following blog post is based off a script for a YouTube dev diary that I was unable to record due to a serious injury. While edits have been made from the original script to account for the different form factor and other impacts caused by the injury, the content is largely the same as when it was originally written in early February of this year.

I recently got a leverless fight stick. On top of being great for fighting games, it turns out it’s a fantastic way to play games like DJ MAX as well.

I’ve been playing Evangelion New Theatrical Edition: Sound Impact on PSP. It’s a weird little game, released following the second Rebuild of Evangelion movie, developed by Grasshopper Manufacturer, with music production overseen by Akira Yamaoka, of Silent Hill fame.

It’s also a rhythm game.

I’ve been continuing to play games like DJ Hero, Rock Band, and Fortnite Festival. This hasn’t just been for fun, mind you. Feel is an incredibly important part of a rhythm game. It’s not enough to have notes that you hit, in time to the music. How it feels when you hit them, when you miss them is equally, if not more, important.

This is, I think, the real challenge of making a rhythm game (honestly, most games). It’s nailing that feel. It’s why something like Fortnite Festival doesn’t quite hit the same highs as a title like Rock Band. That feel is off. The feedback is lacking. And so I’m playing all these games, recording footage as I do so, to try and better hone in on what makes them feel good, or bad, as I play them. And how I can recreate those methods in my game.

Let’s wind the tape back though.  What the heck is a HYPER GROOVE?

In 2014, I was a senior at WPI in Worcester, Massachusetts. My senior capstone project was to build a game in a handcrafted engine. I did. It was a rhythm game where, for no real strong design reasons - you switch between two different note highways matching beats. It was called HYPER GROOVE.

Fast forward to Summer 2024, and while messing around with the Playdate SDK, I realize a remake of said game was a perfect fit for Panic’s nifty little handheld. And thus was born HYPER GROOVE Anniversary X Edition.

Which brings us to today, in early 2025. The atmosphere is tense, scarier. 

But HYPER GROOVE is still an escape from that. A game about grooving to music, matching beats, and trying to rack up as high a score as you can. Working on this game is a panacea for my anxiety. It gives me focus, it gives me an outlet. So do the other projects I’m working on, but this also brings me closure. HYPER GROOVE is an inside joke amongst friends. The endless iterations of other beat-matching rhythm games I started and never finished in its wake contributed to the inside joke. But this game is real. And it has a new name:

HYPER GROOVE AX

It’s targeting a release later this year - originally I had a firmer launch window, but breaking my leg in two places paused development for two months. Even having now resumed work on the game, things in my life are just generally moving slower for the foreseeable future and I can't sit at my desk to record live guitar (which at least two songs plan to use). But let’s talk about what’s been done so far, and what’s left to do.

Back in Summer 2024, in a YouTube video, I showed off early footage of this game. I’ve spent about two hours a week (at most - some weeks I've not touched it at all!)  working on it since then prior to my accident, so in terms of actual development hours - not a ton of time has been spent building it. That’s I think really important to understand, because I’m really happy with how much progress it’s made.

The core systems, save for leaderboards — but we’ll come back to that, are all implemented. I have one fully playable, original song, with another finished song composed, but not in the game. Everything is functional, and now I’m focused on content and polish. 

Let’s break down what that means. 

Content wise, this means making about 6 - 8 more songs, animations to play during the songs and getting them all in the game, as well as some additional UI/VFX elements to help with the game feel. The game is fully playable but the feel isn’t quite there yet. In early attempts to adjust the feel, to improve things it became clear some of the technical foundation needed to be re-worked, and so I actually spent some time in December doing just that.

The Playdate SDK is Lua based. Okay sure, there’s technically a C++ and Swift SDK available now, but when I started making this game the recommendation from Panic sure seemed to be to use Lua and I don’t know Swift anyways... and I wasn’t exactly chomping at the bit to casually starting building a game in C++ in my spare time. You see… Where was I? Oh, right Lua. 

So, Lua’s main data structure is a “table”. A table is basically an associative array. At a super high level it’s an array that doesn’t just have to be numerically indexed, you can use strings, or basically any value that isn’t null (or nil as Lua likes to use). And, tables aren’t a fixed size. You can add as many elements as you want and don’t need to define them with a size. I was originally using tables to contain the note gems that players hit. And I mean… I still am. Except now, I’m using the table structure, combined with an existing Lua stack implementation to actually use it as a stack. 

Maybe you’re not a programmer and are lost. Let me try and give a quick overview of what an array and a stack are. An array is a core structure in most programming language. Wikipedia defines it as:

“a data structure consisting of a collection of elements (values or variables), of same memory size, each identified by at least one array index or key.”

As I alluded to earlier in defining a Lua table, most of the time arrays are numerically indexed. So you would access an element of an array by a number value - the first slot being 0, the second being 1, etc. (Again if you’re not a programmer - most programming languages are “zero indexed” that is the first value is zero, not one).

So what about Stacks?

Wikipedia defines a stack as:

an abstract data type that serves as a collection of elements with two main operations:

Push, which adds an element to the collection, and
Pop, which removes the most recently added element. 

Additionally, a peek operation can, without modifying the stack, return the value of the last element added. The name stack is an analogy to a set of physical items stacked one atop another, such as a stack of plates.

So when a note is hit by the player, or when the time a note should have been hit by the player has passed, the structure containing that note is popped off the stack. 

Whereas before, I was just basically marking it as null. So what’s the big deal in this change?

Well… actually detecting note judgement (basically - did you hit the note, or did you miss the note) is a lot smoother now and I have greater control over what happens when a note is hit or disappears. For example: now on a note being hit, I can trigger an animation and a sound. Or on a note miss. Simply using a table as I was actually made this really difficult and the code was incredibly messy to manage. It was in implementing this visual feedback that I realized I had made life harder for myself. My first pass of getting audio/visual feedback completely broke the hit detection because notes were either disappearing too soon or too late, and the entire system was getting clogged. So you’d hit a note, but a note much earlier in the table was being impacted, for example. But with the stack implementation notes that are long gone are well… not able to interfere, because they’re no longer in the data structure.

So that’s an example of polish work, but there’s other stuff to work on from there. Some other to-dos: 

• Polishing the UI! This means both how it functions and responds to player input, but also the actual visual design of it itself. I’m iterating some designs right now, and that’ll impact the technical implementation.
• Input detection! This is largely related to the crank. Right now it’s a little finicky switching between tracks using the crank, and getting that to feel right - not too strict, not too sensitive - is paramount for this game’s mechanics to really work.
• More audio! Obviously there’s the music that needs to be made, but adding sound effects to UI interactions in the menu, balancing the sound properly still needs to be done too.

This may sound like a lot of work, and it is, but the game has been progressing pretty well (outside events aside).

That's all for today though, stay tuned for more dev updates in the coming weeks and months.