/tower

laboratory

brewing · /tower/laboratory · one of two domains you start with

There is no command that brews a potion.

That is the whole design of this room in one sentence. The laboratory holds five instruments, and brewing is moving materials through them — clear a tool, load it, set it working, collect what it made. The only way one line makes a potion is a spell you wrote yourself.

stage        instrument           heat      leaves behind
preprocess   mortar_and_pestle    —         husks
process      balneum_mariae       athanor   sediment
combine      flask_and_rod        —         dregs
distil       alembic              athanor   phlegm
(heat)       athanor              —         ash

The fire is the decision

The athanor is shared infrastructure. It takes charcoal, burns at a constant rate while lit, and heats whichever of the bath or the still is working. It consumes fuel per lit tick whether or not anything is mounted on it — so idle lit time is pure waste.

The two heated stages are not adjacent. The unheated flask_and_rod sits between the bath and the still, which means burning straight through the combination throws fuel away. The efficient play is:

light → digest → damp → combine → relight → distil

That was not designed. It fell out of the durations, and it was found when the fire died in the middle of an end-to-end test.

The cost of getting it wrong is fuel, never progress. A careless player pays a little more charcoal; an attentive one banks what has not burnt. This is the cleanest argument for automation in the game: a player who walks away with the athanor lit wastes fuel, and a script that ends its loop with stop athanor does not.

Byproducts, under one rule

Every byproduct has at least one use. A tool fouled by the last brew must be cleared before the next, and a byproduct that is an input to another recipe makes the room’s current state change what is worth doing now. A byproduct that was only ever litter would turn clearing up into tidying — which is the exact feeling the rule exists to remove.

Next: the archive, the other domain you start with.

archive

research · /tower/archive · one of two domains you start with

Every command in the game is found, then understood, then used.

You do not begin knowing how to read a file. You begin with attend and survey, and everything after that is a fragment recovered from a siege, a hidden directory or a stranger’s machine, carried back here and deciphered.

orbs:~/archive$ decipher fragment_0x1f

  the sigil resolves. it is a sieve — it lets
  through only what matches, and holds back
  the rest.

  learned: sift
    sift <pattern> <file>
    ... | sift <pattern>

  the grimoire grows.

Shell verbs, domain verbs, and capabilities all unlock on this one track — conditionals, loops, triggers, offline accrual, extra panes. Literacy and progression come out of the same mechanic, which is why the archive is played more than anything else in the tower.

It is also why the fiction holds. You are not being handed a tutorial; you are a wizard who has recovered a word and worked out what it does.

grimoire

spellcraft · /grimoire · a sibling of the tower, not a room inside it

A spell is not kept in a room. It is a book you carry.

Spells are ordinary text files. You write them in the orb’s editor or in your own, and the orb reads exactly what you typed — your words, not a rewritten canonical form.

orbs:~/grimoire$ cat night_watch.spell
#!/orbs/invoke
# runs each dusk

ward --upon north_gate --strength 3
invoke brew_clarity --qty 2
purge --byproduct --above 60%

if scry --enemy --within 2leagues; then
    alert --priority high
    ward --upon all --emergency
fi

orbs:~/grimoire$ bind night_watch.spell --to dusk
Bound. The orb will remember.

brew_clarity is a spell you wrote, not a command the game ships. It holds the dozen-odd lines that clear the instruments, move the reagents, wield each in turn and siphon the result — and night_watch simply calls it. Scripts composing scripts is the beat between “I automated one chore” and “my tower runs itself”.

Why automation wins

• Some things cannot be done by hand at all. Triggers on events you cannot sit and watch for; conditions that need continuous evaluation.
• Your attention is the scarce resource. A manual action occupies its pane for its whole duration. A script does not spend the attention you need elsewhere.
• The orb is simply better at it. A script-executed action completes faster than the same action typed.

And why that is dangerous

Automation is progression and automation is attack surface. A bound script runs unattended, on inputs it does not question. The siege does not out-damage your defences — it feeds them a log that is subtly wrong, a record with the spacing off, a name that refers to a gate which was destroyed and rebuilt.

References resolve by identity, not by name, so a rebuilt gate is a new thing and the script says so rather than quietly acting on a replacement. That is what makes sabotage detectable instead of invisible — and finding it is the game.

the siege

the second half of the game · /siege · not yet built

Urgency is consensual. The tower is safe; a siege is something you walk into.

A siege is real-time and can genuinely be lost. Your bound spells execute as an autobattler while you diagnose and repair under pressure — which is the moment every other system in the game converges.

Why you would go

Sieges are the only source of certain reagents, fragments, and knowledge of what your enemy can do. Idle play plateaus without them. Nothing pushes you in; the ceiling simply stops rising.

What you keep

Earnings accrue into escrow as they happen and settle when you leave. How much you keep scales with how far you got — so bailing out early after farming a cheap opening is punished specifically, while a run that fails at ninety per cent still pays nearly in full.

What attacks you

Not a bigger number. The enemy attacks the automation: it poisons what your scripts read, so a spell that is working perfectly does the wrong thing perfectly. One command diagnoses it. Knowing to run that command is the skill.

roadmap

solo · commercial · planned as a long build. Demo first, then 1.0 — no early access.

phase                     status
0.  vertical slice        closed
0.5 interlude             closed
1.  core loop             in progress
2.  siege                 —
3a. breadth               —
3b. remote hosts          —
3c. engine upgrade        —
4.  onboarding + demo     —
5.  ship                  —

Phase 0 built the parser, the cell renderer, the CRT port, the boot sequence, and the two starting domains — brewing and archive — as a working vertical slice.

Phase 1, in progress, is the core loop: the world clock, the script engine, the failure taxonomy, more of the sabotage surface, and the balance work that turns first-pass numbers into a game.

Everything after that is written down, argued with, and subject to a cut line that was decided in advance rather than in a panic.

One thing worth being honest about

Phase 0 set itself a numeric exit gate: eight external testers, at least half with no shell experience, and 85% of their inputs reaching the action they intended on the first attempt. That gate has not been run. It is deferred, not passed — there are no external testers yet, and the author cannot stand in for one, because someone who already knows the vocabulary is measuring their own memory.

It will run in Phase 4, where onboarding and the demo put people who do not use terminals in front of the game anyway.

pillars

the five things every decision is checked against

1

The terminal is the fantasy, not a UI. Every mechanic should feel like both operating a computer and practising magic.

2

Understanding beats memorisation. The parser forgives phrasing. Mastery is knowing what to do, not recalling a flag.

3

Automation is progression — and automation is attack surface.

4

Urgency is consensual. The idle layer is safe. Sieges are entered deliberately.

5

Everything converges in the siege.

The voice

The register moves with the world, never with the mood of the writer.

earnest arcane

The default, and about four fifths of the text. Warm, mythic, sincere.

sysadmin comedy

Easter eggs, deprecated commands, obscure corners. Old software with old opinions. Discovered, never pushed.

eldritch

Threat high, siege collapsing, forbidden directories. Clipped, cold, wrong.

The eldritch register signals through pacing, diction and silence — never through colour, so it survives any phosphor and any colour vision.

What this game is not

• Not a Linux tutorial. Terminal literacy helps, and is never required.
• Not a typing game. Diagnosis is one command; speed buys nothing.
• Not illustrated. No sprites, no portraits, no key art beyond the screen itself.
• Not multiplayer.

battlements

defence · /tower/battlements · not yet built

Walls, gates and wards. Command pressure at one action per second, and ward placement that has to hold while you are busy elsewhere.

The battlements are where a siege lands, and where the automation you wrote in calmer hours either holds or does not.

See the roadmap for when.

lens

scrying · /tower/lens · not yet built

Feeds, logs, intelligence. Scrying is deduction: parse noisy output and find the truth someone has hidden inside it.

This is the room that reads sabotage. When a bound spell starts doing something slightly wrong, the evidence is in a log, and the lens is how you find it — spacing that drifted, an alignment that slipped, a record that is malformed in a way a machine would not produce.

Log listings are never corrupted by the game’s own presentation, however bad things get. The diagnostic surfaces have to stay trustworthy as renderings, even when their contents are not.

menagerie

summoning · /tower/menagerie · not yet built

Familiars and constructs. Allocate resources, get something that fights on its own in a siege — and, being autonomous, does so whether or not it is still a good idea.

forge

enchanting · /tower/forge · not yet built

Imbuing items and wards. A sequence and a resource cost, in exchange for something that keeps being true after you stop paying attention to it.

about

made by

Blackhearth Games — David Yurek, solo

status

In development. Phase 1 of nine.

built with

Rust and the Bevy engine

platforms

Windows, macOS, Linux

licence

GPL-3.0-or-later — the game is built in the open

contact

support@blackhearthgames.com

There is no store page yet, and no wishlist link to give you. When there is one, it will be here. Until then, the email above reaches a person.

Credits

This site is vanilla HTML, CSS and JavaScript. No framework, no build step, and no analytics of any kind — nothing here watches you read it. It works with JavaScript switched off; the command line is the only thing you lose.

typeface

unscii-16 by Viznut — public domain / CC0. The same face the game renders its cell grid from.

colours

The four phosphor themes are the game’s own, converted from its source rather than matched by eye.

site source

MIT. github.com/millidavids/orbs_website

Privacy

This site sets no cookies and runs no analytics, no trackers and no third-party scripts. Your phosphor preference is kept in your own browser’s local storage and is never sent anywhere. The host, Cloudflare Pages, keeps standard server logs.