Install & play¶
Install the client¶
The installer picks the right binary for your OS and CPU (Linux or macOS,
amd64 or arm64), checks its SHA-256 against the checksum file published beside
it, and installs tarmy into /usr/local/bin when it can write there (as
root, or on a machine where that directory already belongs to you), and into
~/.local/bin otherwise. It prints the directory it picked on its destdir
line, so you never have to guess.
Verification fails closed. If checksums.txt cannot be fetched, carries no
entry for your archive, or does not match what was downloaded, the installer
stops and installs nothing. There is exactly one way past that, and you have to
type it yourself:
Two more variables are read the same way: INSTALL_DIR=$HOME/bin puts the
binary where you want it, and VERSION=v0.1.0 installs a specific release
instead of the newest one.
If tarmy is not found afterwards¶
~/.local/bin is not on PATH on a stock macOS shell, and on Ubuntu it only
joins PATH at your next login. So a non-root install can finish successfully
and still leave you with:
Nothing is broken. The binary is in the directory the installer named on its
destdir line, normally ~/.local/bin, and you can run it by its full path
right now:
To be able to type just tarmy, add that directory to your PATH. Which file
you edit depends on the shell you use, and these are not interchangeable: fish
reads none of the others, so putting the line in ~/.profile and then starting
fish still answers fish: Unknown command: tarmy. Run echo $SHELL if you are
not sure which row is yours.
| Shell | File to edit | Line to add |
|---|---|---|
| zsh (the macOS default) | ~/.zshrc |
export PATH="$HOME/.local/bin:$PATH" |
| bash | ~/.bashrc |
export PATH="$HOME/.local/bin:$PATH" |
| fish | ~/.config/fish/config.fish |
set -gx PATH "$HOME/.local/bin" $PATH |
| anything else | ~/.profile |
export PATH="$HOME/.local/bin:$PATH" |
Open a new terminal afterwards, and swap in your own install directory if it
was not ~/.local/bin.
You do not have to work any of this out yourself. Whenever the directory it
used is not already on your PATH, the installer names your shell's file and
prints the line in that shell's own syntax, with the real directory filled in.
Play the public universe¶
tarmy defaults to the public shard at https://terminal.army. On first run it
opens a browser sign-in URL; create an account or log in, and the terminal
client picks up the session automatically.
Windows¶
There is no native Windows build, and the installer refuses to run under Git Bash, MSYS2 or Cygwin rather than dropping a binary that cannot execute. Windows is supported through WSL. In PowerShell:
Then, inside the Ubuntu window that opens, run the normal install line:
From there it is an ordinary Linux install, ~/.local/bin caveat included.
Other platforms¶
Releases are built for four targets only: linux_amd64, linux_arm64,
darwin_amd64 and darwin_arm64. FreeBSD, 32-bit x86 and 32-bit ARM (an older
Raspberry Pi OS, for instance) have no build, and the installer says so and
stops instead of installing something that cannot run.
Play on another server¶
If a friend runs their own universe:
The URL needs its scheme. tarmy --remote their-server.example fails, because
there is nothing to say whether that is http or https.
Update¶
Starting tarmy checks whether your client matches the server, and updates
itself when it is behind. It is not a question: it says what it is doing, does
it, and starts the game on the new build. Nothing about your account or your
empire changes, and every failure falls through to the game on the client you
already had.
The check asks the server every launch rather than remembering the answer. There used to be an hour-long cache here, and it caused exactly the bug it was meant to save a request on: the game itself asks the server its version on every launch to decide whether to print the "your client is behind" reminder, so the cache never kept a launch off the network, and a release published inside that hour put the two halves in contradiction. The reminder said to update and the launcher, reading an older answer, had already decided there was nothing to update.
Two cases it will not update in, and both say so:
- The binary is somewhere you cannot write. A
sudoinstall updated as an ordinary user cannot replace itself, so it names thesudocommand instead of downloading a release it could not install. - It is a build from source. A binary with no version stamp is a developer's own, and replacing it under them would be the rudest thing this could do.
The check is capped at a second and a half. If it cannot reach the server at
all, for any reason, the game starts normally. It never runs mid-session, only
before the game, and it never touches tarmy serve or any other subcommand.
To skip it, for a pinned build or a slow link:
To update by hand:
tarmy update replaces the binary it is running from. If you installed with
sudo into a system directory and then update as an ordinary user, it cannot
write there. It stops with a non-zero exit rather than installing a second
tarmy elsewhere on your PATH, tells you where the verified new build is
waiting, and prints the exact commands that finish the job.
The startup check knows about that case too. When the binary sits somewhere you
cannot write, it says so and names the sudo command instead of downloading a
release it could not install, so a system-wide install does not re-download the
same build on every launch.
If you have more than one tarmy on your PATH, the update also tells you so,
whether it installed a new build or found you were already current. It names
the copy your shell reaches first and the directory to move ahead of it,
because updating a binary your shell never runs leaves the game showing the
update reminder with nothing to explain why.
If you installed the commander with tarmy commander, starting tarmy also
refreshes its bundled game skill. The MCP server is part of the same binary,
so it updates with the client. Reconnect an already running assistant to load
the new tools. Your permission tiers stay unchanged, and a skill you edited
yourself is preserved. See commander updates.
Log out¶
Inside the client, /logout does the same thing and quits.
The interface¶
The client is a full-screen TUI with a resource bar on top, a grouped menu on the left (Empire · Ops · Social), clickable tables in the center, a live status rail on the right, and an always-available command line at the bottom.
- Mouse: click a menu item to switch views, click a table row to build or upgrade, scroll to page through lists.
- Keyboard: type slash commands (see Commands);
Tabautocompletes,↑/↓walk history.
Every mouse action has a command equivalent, so you can play entirely by keyboard or entirely by mouse.
What it stores on your machine¶
One file per server, under your user config directory, mode 0600. It holds
the server address, your session token, your commander name, your language and
your colour theme, and nothing else. It sends no telemetry, and the only server
it exchanges game traffic with is terminal.army. One exception is worth
naming: it looks that name up through Cloudflare's public resolver at 1.1.1.1
rather than the one your system is configured to use, so a resolver that has not
picked up the record yet cannot make the game look unreachable. Cloudflare
therefore sees that your address asked for terminal.army, and nothing more.
More in the
FAQ.
Ready? Sign up at terminal.army and run tarmy.