tl;dr section: The randomizer engine is done (barring clean-up) and this is the probably the last post about it. I go over some of the challenges I faced while working on this project. Don’t expect more, because I’m kind of burned out on this proejct and that would likely get into the territory of actual ROM hacking, which I’d like to avoid.
I’m kind of surprised that it’s been 4 months since the last post I made about this randomizer. I spent a whole bunch of time doing data entry, since I wanted to test the randomizer on real data. To do this, I actually went through the entirety of Kirby and the Amazing Mirror and created a JSON file for all of the door data. The actual time I spent writing code for the project was comparatively small.
Code
Since I removed the code from the previous post, I decided to start with it for this post. You can peruse the code at your leisure over on GitHub here. Feel free to use the code for whatever you like. I didn’t want to dump all of the code here, mostly because it’s not really finalized, although I’m not sure when I’ll revisit this project.
Redesign
The original project structure that I had looked as follows:
After careful thought, I realized that this made no sense. The door data should be able to be defined however the application likes. This could be JSON, CSV, whatever. All the engine cares about is that the data is converted into the graph format that it requires for randomization. Thus, I ended up redesigning and moving much of the code.
Petgraph
Since I implemented the algorithm using petgraph, taking a type-driven approach ended up being a little bit more difficult. I had to compromise on some of my data definitions, since I needed to adhere to petgraph’s API. Ultimately, this wasn’t such a problem since I added some tests, but it did cause a few bugs in the initial implementation, which I later added regression tests for. In the future, I would like to come back to this and see if I can’t come up with a better encoding, but the existing one wasn’t that bad and did save me some trouble in the end regardless.
Future clean-up
Right now, the bidirectional maps I’m using need to be constructed by the application code. I’d like to keep the construction of this map out of the application code and instead make it part of the engine code.
Final thoughts
By the time I finished entering all of the door data, I was pretty burned out on this project. It turns out that this probably wasn’t a good project for me to start after all. I’m still glad I tried it though. I found that Rust’s affine typing actually caught a few potential bugs for me and once I got the whole thing working, fixing data entry errors became very trivial. I also ended up learning how to use thiserror and anyhow, which I quite like. I’m not sure how long those two crates will last in the Rust ecosystem, considering how often new error handling crates are made, but I’m generally pretty satisfied with them right now. I think for now, I’m probably going to move on to more interesting projects that won’t require weeks of data entry. I’ve been playing with dependent types for a while now and I’d really like to work on more projects using them.