Pictured below is "The Hub", a parkour gym in Boston, MA:
MZST gamifies parkour gyms. It allows players to create custom "lines" through the gym (e.g. start on platform 'A', swing across bar 'B', vault over ledge 'C', and finish by pressing a button on wall 'D') and compete for the fastest time to complete these lines. A persistent database stores player profiles and a competitive leaderboard, all of which are accessible to players through a smartphone app.
MZST is being made by myself (software) and my close friend Alec Reduker (hardware). The major components to MZST are:
MZST is very much a work-in-progress. The primary focus right now is on developing the Checkpoints, Server, and Synchronizers, which all have functioning prototypes. The Backend and User Interface are partially designed, but will not be fully implemented until the core gameplay is fleshed out.
Simply put: when a player triggers a Checkpoint (e.g. by touch), it sends a message to the Server with the exact timestamp of the trigger.
More specifically, a Checkpoint is a collection of sub-modules coordinated by an ESP32s3 microcontroller running FreeRTOS:
So far, we've built 5 prototype Checkpoints. See below for a picture and circuit schematic below, or check Alec's website for more (1) (2). The firmware is public on our GitHub repo. It handles:
The Server controls the game by processing input from the Checkpoints and the users. The game itself is a state machine, updated by actions such as Checkpoints being triggered or players loading a new "line" via the User Interface.
Currently, the prototype Server implementation is an Android app written in Java. The Android layer simply provides a convenient UI for interacting with and debugging the core Server functionality. In the future, we may create other deployment options for the Server (e.g. as a desktop CLI or qt application), and/or port the Server logic to another language.
A state machine diagram for the Server, as well as a simple block diagram of our prototype implementation, are shown below: (note that the terms may be out of date, e.g. "Sensor Packages" are now called "Checkpoints")
The definitions for each state and action are as follows:
| State | Semantic Description |
|---|---|
| IDLE | The game is not being played |
| READY | A player has loaded a "line" and the game is ready to play |
| DEFINE | A player is creating a new "line" |
| RUN | A player is actively running a "line" |
| FINISHED | A player has finished running a "line", either sucessfully or not |
| Action | Semantic Description |
|---|---|
| START | Begin the game |
| RESET | Reset the game |
| LOAD | Load a "line" to be played |
| SAVE | Save a new "line" |
| NEW | Enter "create-line" mode |
| TRIGGER | Advance current state |
The Synchronizer, or "Transmitter Module", is responsible for accurate and consistent timekeeping. The Server must know exactly when a Checkpoint is triggered, so that players can be fairly judged on their time to complete the game. This is incredibly challenging due to variable network latency and clock drift.
Periodically, the Server will instruct the Transmitter Module to perform a time-sync operation. The Transmitter Module emits a strong, encoded RF signal. Receiver Modules, present on each Checkpoint, reset the Checkpoint's internal clock upon receiving this signal.
This method is simpler and more accurate than other solutions of clock synchronization, such as the Network Time Protocol.
Like the Checkpoint, the Synchronizer itself is a collection of hardware orchestrated by an ESP32s3 microcontroller. It runs the same firmware as the Checkpoint, with a different implementation file.
Prototype Transmitter Modules have been built (image below), and Receiver Modules are integrated into our prototype Checkpoints. In practice, this approach has proven to be extremely reliable; however, it has yet to be tested in a larger, noisier environment.
The Backend comprises the database of player details, "lines", leaderboards; as well as an interface for the Server and players to interact with the databases.
We have not yet started work on the Backend, aside from some brainstorming on how to best integrate it with our existing design.
The User Interface is how the player controls the game. Our current vision is a smartphone app where players can:
We have some mockups of how the app could be structured, as well as a website to browse leaderboards and manage player profiles. However, work has not yet started on the User Interface.