Games Are Small Systems: Learning Automation Through Play

Games Are Small Systems

A game is a small system with rules you can learn, state you can inspect, and consequences you can measure. That is why games are useful for more than entertainment. They give experimentation a clear boundary without putting a low ceiling on expression.

The same board can support a first move, a clever shortcut, a bad assumption, a reliable procedure, and years of optimization. Scores, outcomes, and replays make the difference visible. You can try something, observe what happened, change your approach, and try again.

CLI-Games applies that loop to command-line fluency. A player can arrive for Minesweeper, Solitaire, or an arcade run without asking for a lesson. If they want to go deeper, selected games can also become small automation systems: saved Bash files, visible-state sensors, bounded actions, repeatable fixtures, and evidence produced by the run.

The lesson is not pasted over the game. It is what happens when the player decides that an intention should become a reusable procedure.

From one command to a policy

Direct play answers an immediate question: what should I do now?

Automation asks a more durable set of questions:

• What state can I observe?

• Which action is legal?

• How should I represent the decision?

• What should happen when the state changes?

• How do I know that the procedure still works tomorrow?

Those are game questions, but they are also the ordinary questions of operating an ongoing system. A server, deployment, data pipeline, personal workstation, or home lab rewards the same habits: inspect before acting, encode repeated work, preserve state deliberately, handle failure, and verify the result.

This is the bridge between games and training at CLI-Games. Play creates a reason to repeat the behavior. A filesystem gives that behavior somewhere to live. A script turns it into something inspectable and reusable. Fixed runs and measured output make improvement visible.

Minesweeper in microcosm

Minesweeper supplied a useful early example because its manual action already has a compact command grammar:

r ROW COL
f ROW COL

Me, personally, I like to start every game of Minesweeper by clearing the four corners first. I mistakenly believed they had a statistically lower chance of containing bombs. I was wrong about that, but the habit remains. You should not emulate me if you care about winning, but the point is that I have now encoded this little habit from four commands to one.

r 0 0
r 0 "$LAST_COL"
r "$LAST_ROW" 0
r "$LAST_ROW" "$LAST_COL"

becomes

./sweep.sh

Open Minesweeper's scripting tier and it automatically creates your scripting workspace:

$ minesweeper --script
$ cat README.txt
$ nano sweep.sh
$ chmod +x sweep.sh
$ ./sweep.sh

The scripting tier opens in a real workspace with its README and starter already in place.

The supplied sweep.sh contains one working reveal and three small stubs. It also receives ROWS, COLS, LAST_ROW, and LAST_COL, so the same file can name every corner without hard-coding one board size.

The first edit is deliberately small: turn the remaining coordinate stubs into commands.

When the run ends, the player can compare its measured profile, export a replay-backed GIF, or export a local JSON receipt. Packaging the habit did not make the underlying assumption correct. It made the assumption repeatable, measurable, and easy to revise.

The point is not that four reveals solve Minesweeper. They do not. The point is that a tedious repeated intention has crossed a threshold: it now lives in a file the player owns, can edit, can execute, and can question.

One pattern, different systems

The same structure is documented here across eight games:

• Minesweeper scripts coordinate reveals and flags.

• ShiftSum policies inspect register lanes and align checksums.

• Tenfold policies read a grid and choose legal placements.

• Radix policies inspect tubes and sequence pours.

• Solitaire policies operate with partial information and visible legal

• P-Squash controllers route a byte through deterministic circuits.

• Blockfall programs inspect a loading yard and plan compaction actions.

• Termiclanker develops Bash from small robot programs into factory and

The games do not pretend to be identical. Each one exposes the state and actions its own rules can honestly support. What they share is the surrounding contract: a durable workspace, a supplied README, an editable starter, normal shell tools, measured runs, and portable artifacts.

Use the web catalog's Automate view, or type:

$ games automate

The catalog and command list are generated from the same shipped game definitions, so they show only games that currently expose an automation workspace.

See how your script stacks up

Script runs today are isolated from ordinary game leaderboards. Obviously, it would be unfair to compare computer results to that of a human. But scripts can carry their own performance metrics, something that we are actively working on.

A run leaves measured output to inspect even when the policy itself needs revision.

Still, you already get some data. The current scripting tiers allow you to:

1. preserve a script in persistent storage so you can transfer, tweak, and rerun it; 2. compare a run's measured axes with saved account bests where available; 3. export a GIF or a local receipt for inspection and voluntary sharing; and 4. in ShiftSum, Tenfold, Radix, or Solitaire, request server proof across a five-fixture fixed pack.

A local receipt says that the browser host observed a practice run. It is explicitly unranked and not server verification. A successful proof request means the server replayed the submitted source twice across every pinned fixture and issued a shareable receipt. The source is processed transiently and is not retained.

That proof is stronger evidence, but it is not currently a global script leaderboard. We will not call it one until the competitive system actually exists.

What transfers

No board game can certify that somebody is ready to operate arbitrary production infrastructure. That is not the claim.

The transferable value is narrower and more useful: loops stop being abstract syntax when they keep a process alive; exit status matters when it selects an action; state management matters when yesterday's file is still there; a regression fixture matters when a change improves one case and breaks another.

Those experiences reduce the distance between recognizing a programming idea and using it to control a system. More demanding training can then name and strengthen the habit. Independent challenges can test whether it survives in a changed environment.

CLI-Games is meant to support all of those relationships without forcing them into one funnel. A casual player never owes the site a scripting conversion. An automation-minded player should not have to guess which games have deeper interfaces. The adjacent path should be obvious when wanted and quiet when it is not.

Start with a small system

Browse scriptable games, choose a familiar set of rules, and open its supplied README. Run the starter before making it clever. Then change one decision, run the same fixture again, and inspect what moved. The companion automation guide covers the workspaces, exports, proof boundary, and current ranking behavior.

That is enough for a beginning:

play -> inspect -> script -> measure -> revise

The game supplies the reason. The filesystem preserves the work. The commands make the idea operational.