Recompilation Part 4 - OpenKuru & Beyond

In the previous post about this project we'd moved away from the static recompilation/emulation layer build and reimplemented much of the game in SDL using TAS completion recordings to verify course and input parity with the retail game. The game was theoretically completable (but not by me!) but there were things missing.

I'm not going to continue explaining the minutiae of the process but wanted this post to act as a summary of where the release is now, and what comes next. 

I needed to actually prove that the game could be completed from a 'power-on' state and kept hitting a brickwall using the TAS inputs from mohoc - things were going out of sync. I set Nibs to work and you would not believe how much cheese this guy managed to nibble through. 

I should've been supervising more carefully because Nibs ended up burning through a large number of ChatGPT Codex usage limits, usage limit resets and I even funded another £20 worth of credits. It was quite infuriating to tell the truth, up until this point we had been making significant amounts of progress within each 5 hour window, going from nothing at all to a full implementation in C++ with SDL. All I wanted to do was use the inputs from the TAS and watch the game complete but after completing a level the inputs were out of sync and so the next level didn't line up properly. To 'fix' this Codex was testing against emulated behaviour and started to add arbitrary delays between courses.

This went on far too long before I caught it but even when I did, I was hoping for some sort of pattern, some sort of universal magic number or set of numbers that we could apply to make the inputs work. So I kept feeding the cheese monster in the hope it'd happen but ultimately it never did and I decided we needed a new approach. 

The GBA, apparently, had a different amount of loading and preparation time between courses and this was not consistent across the game. I suggested that we try to find the non-gameplay element (menus/world map course selection etc) of the TAS inputs file and replace them with waits that suited the native engine instead. With permission to adapt the existing TAS, retaining the original gameplay inputs but replacing the transition wait periods with timings appropriate for the native engine, Nibs made short work of it. What follows is a video of a full 100% no-damage clear of the game.

This video is actually from the current build of the game but essentially this is the same thing that I saw when I first booted up the TAS playthrough. 

There's another TAS that completely breaks the game. It's actually possible in the retail version to break out of bounds and complete the levels by doing very little of the actual level itself. In lieu of being able to complete the game myself, or perform these game breaking glitches, I once again turned to the TAS inputs from mohoc. If this native implementation could replay those inputs and 'complete' the game in the most broken of ways then I'd consider this convincing evidence of gameplay parity with the retail release and call the single player experience complete. 

And that's it. Single player can be completed from start to finish in the native Windows port (I think I can call it that now). There's a few bits and pieces that aren't quite right - there's an incorrect background shown after course completion and the 'GOAL' text is supposed to palette cycle. Those two can be fixed really easily but have no impact on the gameplay. 

I've referred specifically to the single player experience throughout this series of posts and for good reason - I never actually played mulitplayer back in the day. The game would allow for a link cable or multitap connecting upto 3 additional GBAs - it'd send the game down the cable and let you race each other through any of the challenge mode courses. I wanted to implement this in the native version but I wasn't sure how to approach it, what I settled on was local split-screen multiplayer and so that's what I asked Nibs to implement next. 

This was implemented really quickly - I didn't do much in the way of prompting except suggest that the scoreboard etc be centred, instead of repeated 2 or 3 times. I had to explain how I believed the progress bar at the bottom would work but the whole mode was finished in under 30 minutes. Amusingly, I had forgotten to explain that only the 'Challenge' mode levels should be playable and so initially I ended up with the adventure levels instead. 

I explained this, requested a selection option and in short order a quick selector was provided so that for first time, OpenKuru, as I was now calling it, was providing more functionality than the game originally shipped with.

Seeing the 'ghost Helirin' like this gave me another idea - I would request Nibs add the ability to play single player against your highest completion ghost. I suggested that all runs should be recorded and that runs that ended up being the record for any given course should be saved and played back the next time that level is attempted. Again, this was really quick to be implemented - Nibs correctly identified the previously used method of displaying the ghost in the split screen mode and simply ported it over to the single player game. The recording is created by recording the Helirin position 60 times per second and storing it as a file if a new speed record is created. Ghost display can be toggled with a menu that appears when pressing 'Select'.

There's also an option there to play the TAS recording under 'See Demo' or to 'See Map' which displays as below.

That's pretty much it for the retail game to be honest with you. I've skipped over many of the prompts and back-and-forth exchanges that were required to get to this point because I don't think it'd make an interesting blog post (and because I don't want to write that much either!) but there were about 120 builds or milestones required to reach this point. I haven't really seen anyone write about what the AI-fuelled decompilation/recompilation process actually entails and so I don't know if I could've taken a more hands-off approach. Early during the process I decided to ask that Codex ask when unsure and to stop at obvious milestones. People often talk about handing a console game to Claude and returning hours later to a completed Windows executable. I don't know how close to the truth that is and I'd be interested to find out, for me, it feels like without the previous open-source investigation, development and reimplementation work by E-Sh4rk and mohoc, this effort would've taken orders of magnitude longer to complete. 

The eagle-eyed of you will have noticed the image at the top of this page. 'OpenKuru' with Nibs as the Helirin pilot. I asked ChatGPT to create one of those over-the-top Japanese gacha game style logos to use for this project and I'm going to explain my motivation for doing so.

It's no secret that Nintendo are incredibly litigious when it comes to fanmade projects and threats to their IP. I think I'm probably in a minority in agreeing with them about this -  I believe that they have every right to protect their IP. It was with this in mind that I started considering the potential legal ramifications of releasing a PC native port of Kuru Kuru Kururin. It's not as high profile as many of the Switch ports that we're now seeing but the fact remains that this project is derived from Nintendo/EIGHTING products and would not exist without them. Whilst the project contains no Nintendo assets and requires an original ROM to be imported before the game can be started, it is still based on their game and I don't know if we've got any real precedent that has been tested in a court of law. By writing this whole process on my personal website, I am waiving any chance of anonymity if I release this to GitHub. I'd be interested to hear your views on if this is likely to be problematic before I go ahead and do so - I can handle a cease and desist but I cannot handle a life changing damages claim that'll ruin me financially for the rest of my life.

Anyway, that's a lot of words to say 'I'm scared of Ninty's lawyers' but it leads me to the next point - what we have ended up with now is a game engine that could be expanded on - there's nothing at all stopping me from creating/generating an entire tileset of graphics and new level designs, these could be freely included with the game engine and allow anyone to play, even if they've never picked up a GBA cartridge before in their life. I like the idea of opening this out to the community (if one exists) so that everyone can produce their own OpenKuru levels so that's what I intend to gradually do over time. I'm not offering any timeframe on when a release would be available but I think the idea would be that I create 4 or 5 levels, all new graphics (Nibs as a playable character?!) and music tracks and then make that release available with a level editor for anyone else to build on. 

So that's the plan and that's 'where we're at' with the project as it stands. I started this project to answer the question 'Can ChatGPT make a native Windows port of Kuru Kuru Kururin?' and I believe the answer to that question is a resounding 'Yes'. There was a deeper question I also wanted to answer, I wanted to understand what is meant by 'AI Slop' and to find out if I could use AI in a way that would bring something to the table, to improve this title beyond what was already capable within emulation. That's a question I don't feel like I can answer myself and I would love to hear thoughts on that from the community (or at least the people that exist in /r/decomps or see this)

I wanted to make a final point about all of this, there's currently a huge amount of debate over the use of AI, in creative endeavours especially. I've used AI extensively throughout this project and in this series of blog posts and on the very site you're reading this on. I wanted to make it clear that I haven't used AI to write these posts, though and I will not elsewhere on this blog, you'd be able to tell because it'd be flawless prose and wouldn't sound like me. 

I wanted to do this experiment to find out for myself what AI is capable of, I said in the first post that a project of this scale is well outside my capabilities and I am under no illusion that I am the one that 'created' this. I also want to make the point that I am continuing my own learning process into Amiga assembler and I won't be using AI to write my upcoming Amiga demo (release estimate sometime around 2082). I feel like at the very least we all need to maintain our own authenticity by declaring wherever AI is used.

So with all that in mind...

Who fancies some Amiga OpenKuru!?! So far the first level completes with no audio on a 512KB unexpanded A500, Nibs made this from the OpenKuru project - Compiled Amiga C and created a bootable ADF disk image. It took about half an hour.