Yichus

Example

Time-travel game

A programming puzzle with time travel

A portal sends you back in time. Your past self keeps walking. Choose where the two versions of your character meet, then check the resulting timeline.

Each puzzle supplies a configuration to shared game rules. The source below shows where the configuration ends and the rules begin; the replay lets you inspect what those rules do.

Play the puzzle Starts with a guided first trip.
The tutorial at turn one, with portals, a recorded move sequence, and the timeline.
  1. Watch the first trip.Press Run. The character follows its recorded moves, enters the portal, and reappears earlier in the timeline.
  2. Book a rendezvous.In later puzzles, pick a cell and a turn where the two selves should meet. A collision tears one move out of each self’s program.
  3. Make the loop close.Scrub the timeline and inspect what happens. Adjust your bookings or moves, then run again. Help explains the controls; Show me reveals the intended plan.

An engine and its configuration

Describe a puzzle using the shared game rules

A new puzzle needs a board, portals, and a starting move sequence. It should not need a new timeline simulator or a new browser interface.

The configurations are written in Bosatsu. They construct a Puzzle value that the reusable game rules consume. The rules compute movement, collisions, and replay; Yichus’s browser runtime handles events and display. The game rules and UI are also written in Bosatsu—this example has more than just its configuration in the language.

Puzzle configuration / Bosatsu

A board, portals, and a recording

Each level supplies values to the same puzzle type.

Puzzle value ↓

Reusable rules / Bosatsu

Movement, collisions, and timeline replay

The same rules consume each level’s configuration.

Compiled game and UI ↓

Yichus browser runtime / JavaScript

Controls, state updates, and display

The host executes the generated program.

The game demonstrates an engine/configuration boundary. Its replay follows the game’s rules; it is separate from the API and distributed-system checkers.

Here is the tutorial’s board configuration. Each set_cell produces a grid with the named cell changed; the final grid is passed to Puzzle alongside the portal and moves.

grid_0 = empty_grid(10, 6)
grid_1 = set_cell(grid_0, 1, 4, Start)
grid_2 = set_cell(grid_1, 4, 4, PortalIn)
grid_3 = set_cell(grid_2, 1, 3, PortalOut)
grid_4 = set_cell(grid_3, 5, 3, Goal)
Puzzle configuration & engine source Read the files, then run the shipped game

Editing moves while playing changes the player’s plan. Changing a level’s source changes the puzzle itself and currently requires a local build. Read the complete game source.

Back to Yichus · Try a simulation with Why explanations

Where this fits

What this is about: Why an Analyzable Language?

Measure it