If you wanted to record yourself playing on a GameCube, you could use a VCR to capture the video output on tape. But there is a more interesting way to do it—which is precisely what [jiinurppa] built GameCube bot for.
The concept is simple—GameCube bot is a small device that captures controller inputs and records them to an SD card. It can then play them back on command, allowing it to recreate gameplay as it happened the first time right on the console. A Raspberry Pi Pico is the brains of the operation, which is able to intercept signals from a standard GameCube controller. It’s paired with the aforementioned SD storage as well as an ST7735 display for showing status information. The device records in the DTM (Dolphin TAS Movie) format, which can be played back on the device when hooked up to a GameCube console, or in emulators like Dolphin itself.
[jiinurppa] notes that the device isn’t accurate enough to use for tool-assisted speed runs. Most notably, small errors in optical drive reads can lead to desyncs compared to the original machine state that make frame-accurate replays impossible. Still, it’s a neat build that can be useful for capturing game play and later analysis.
We’ve explored the world of Tool Assisted Speedruns before, though this device isn’t directly applicable to that world. Video after the break.
This isn’t that weird! It’s similar to how early multiplayer games worked – far less data to send the player’s inputs than the state of the world.
A lot of fighting games still work this way. The replay data is a bunch of inputs. Smash Bros replays will only work on the same software version.
Doesn’t this approach assume that subsequent game sessions, where the replay data is used, are deterministic and don’t randomize enemy locations / powerup locations / scenery timings?
Or am I misunderstanding it?
It can just save the seed of the pseudorandom number generator along with the replay data
You’re not wrong, but even in the Gamecube era, there were relatively few possible ways to seed a random number generator, and most of them were controllable by the player in some way (time since power on, system clock, etc).
Demo files work this way too
It must also rely on the game having no randomness, persistent state, wall clock access, internet access, 2nd player, etc.
That limits its usefulness in a lot of ways.
My thought as well. You need to store the random seed with the input recording. Also need to eliminate skipping of logic loop.
I think this will not work for most games.