The Trackerator project is at its heart a purpose-built computing appliance meant to support the video game speedrunning and randomizer communities. It has two segments: the Trackerator software and the Trackerator Pro hardware. The Trackerator software is able to be run on any computer capable of running Python and pygame, and is designed to be a modular platform to create a unified interface for tracking game data such as timing splits and item collection in randomized games. The Trackerator Pro is meant to be a platform that runs only the Trackerator software, freeing up computer resources for maximum performance on the computer being used to play the game and/or making data tracking no longer require a mouse and keyboard.

Why Is This Needed?

There are two use cases for the Trackerator: speedrunning and randomized game playing. Speedrunning is a form of video game play wherein a player endeavors to complete a game under a certain set of restrictions as fast as possible. Randomized play is a form in which a well-known video game has elements of it shuffled around by a specialized computer program, and the player attempts to complete the game in this modified state. Both of these methods require the player to not only be familiar with the game to a preternatural degree, but may also require specialized knowledge to be stored temporarily for the course of a game session (typically called a “run”). In simpler games, a player may be able to hold all of this information in their head. In more complex games, however, the amount of information or the complexity of location information may exceed what the player is capable of keeping track of mentally.

Since the beginning of both speedrunning and randomizer play, software tools have been built to keep track of specific information such as the timing of milestones during the gameplay– called “splits”– and the tracking of game information that may be in different locations than their defaults. Furthermore, for the purposes of livestreaming gameplay on video sites such as Twitch, tracking information can be displayed by these programs in order to visually cue audiences that an event has happened, even if they missed seeing it in gameplay. The most common split tracking tool is called LiveSplit. Each game for which state must be tracked typically has its own tracking software, though EmoTracker is closest to the ideal of a unified front-end. Trackerator aims to unify these two tools while also creating a unified method for interacting with the tracker and timer.

Unified Information Updating

The core of the unified information updating interface is the Action Buttons. These are 16 keys dedicated to specific software-definable functions. For example, while tracking information for Fred Coughlin’s Zelda 1 Randomizer, these keys could be dedicated to items such as Bombs, the Bow, the Boomerang, and such. Furthermore, these functions can be made context sensitive: if the player has acquired the regular Boomerang, then the key could be updated to be pressed when the Magic Boomerang has been acquired.

Additionally, the software assumes the presence of eight additional keys: four arrow keys and four other action keys. This set of eight is called the “D-Pad Bank”. The D-Pad bank is used for navigation through menus on the Trackerator, and the four action keys can be configured as needed by the software, similar to the main Action Buttons. In the Zelda 1 Randomizer example, the D-Pad Bank’s arrow keys are used to navigate around the world map, and the action keys on the bank can mark which locations the player has checked.

Tracking information for a game is handled by modules that are drag-and-drop installed into the Trackerator’s directory in the file system. Modules are written in Python and are designed as subclasses of a default module class. The default module class provides methods for drawing information to the screen, accepting input from the Action Buttons and D-Pad Bank, and starting and updating timers. It can also be configured to log timing and tracking data to a file. The API for these modules is designed to be easy for module developers to quickly build robust and specific tools for the games they play the most.

Time Tracking Evolved

LiveSplit is based on a paradigm of time tracking that expects a linear game progression. For example, when speedrunning Super Mario Bros. Warpless, the player is expected to complete the levels in order: 1-1 precedes 1-2, then 1-3, 1-4, 2-1, etc. Even when warps are permitted, there is still an expected and anticipated order in which the levels are completed: 1-1 leads to 1-2, then taking the warp zone to 4-1, then 4-2’s warp zone leads to 8-1, etc. There is a known and relatively unchanging order in which milestones are achieved. For such a paradigm, LiveSplit is very well-suited. However, it is less ideal for games in which progression depends on other factors.

Randomized games, by their very nature, are built around the concept of taking a new and unique path through the game each run, as dictated by the altered placement of progression items. The Link To The Past Randomizer tasks players with completing the game not necessarily by completing all of the ten dungeons, but by completing the seven of them that have the crystal-trapped maidens (called “Crystals”)¹. To track this kind of progression using LiveSplit, one would have to do so in a naive manner: instead of stating that the Desert Palace has been completed, the milestone must instead read “First Crystal”. This creates an unpredictable expectation for the time it takes to acquire the first crystal; the Desert Palace may be first in one run, but in the next the player may need to go to Skull Woods– a significantly longer trek. Additionally this cannot track whether the player has acquired a sword first, or indicate how long it takes the player to navigate from one check spot to another. Trackerator allows this kind of granularity and non-linearity in its tracking of timing data, allowing players to more precisely analyze their performance and identify places where improvement could be made.

Why Use Dedicated Hardware?

The Trackerator software can be run on any system that can support Python and pygame. However, if it is running on the same computer that is running the game being tracked, there may be a performance penalty on the game. Or, if the player is playing on a games console, they may not have easy access to their computer to run the software. It is not expected that there will be a significant resource usage for Trackerator, but with modern games requiring higher-end processing power and memory capacities, every bit that does not need to be run on the machine can contribute to improved speed. Because of this, a dedicated hardware platform is the ideal place for the software to be deployed.

The Trackerator Pro device is built around the Raspberry Pi ecosystem, with its main processing unit being a Raspberry Pi Zero 2 and the custom user controls being handled by a Raspberry Pi Pico². These are interfaced using an I2C connection to the Pi Zero 2’s GPIO pins. Custom circuit boards are being developed to hold both the key switches and the devices. The Zero 2 outputs to a small flat-panel display with a known resolution; the current prototype uses a 7-inch screen. At this point in time the prototype must start the software using a keyboard; it is expected that in the final product it will boot directly into the software.

Networking the Trackerator Pro is possible, and future development is planned to allow a Pro hardware device to send its data to a copy of the software running on another computer, to facilitate creating an overlay for video streaming. Additionally it can be used to facilitate races between players regardless of location; the tool can automatically notify the race coordinators when a player finishes rather than relying on text chat communication in different tools. The goal of networking the Trackerator Pro is to make speedrunning and randomizing easier, faster, and more engaging.

Current Progress

As of today, 2 March 2025, the tool is in a middle to late alpha phase. A second-alpha hardware prototype has been built and software exists for both the Pico and the Zero 2. The Pico software is mostly completed and should be considered to be in its beta phase. The Trackerator software has its main framework built and work on several modules is in progress. A third iteration of the custom PCBs is anticipated to be needed to make assembly and configuration easier and less expensive.

There is currently no scheduled date for the beginning of crowdfunding a “founder’s” production run. Consequently there is no scheduled release date for this project. Please continue to follow this blog for updates and information.

1. This is the default configuration of the LTTP Randomizer; advanced configurations may require fewer crystals or may require collecting a certain number of hidden Triforce fragments instead. Presumably modules will be developed to support these modes as well. ↩︎
2. Originally the development platform was a full Raspberry Pi 4; however the decision was made to switch to a Zero 2 to facilitate ease of connection and to reduce costs. A future iteration of the custom PCB will explore replacing the Pico with an onboard RP2040 to further reduce complexity and costs. ↩︎