Jesse
c95620d566
Pin moves to v0.5.3, package version to 0.5.3:0.
The health check no longer just probes a port. It fetches the server's own
/api/health and reports what it says — "Multiplayer server is ready — 3
games in progress", with ", 1 waiting to start" appended only when a lobby
exists and "no games in progress" on an idle server. A server that doesn't
answer is reported as STARTING, never failed: the server replays its saved
games before binding its port, so a boot legitimately looks like nothing is
listening, and calling that a failure makes an ordinary restart look like a
crash.
Two new actions, both only-running. Games in Progress is read-only and
lists every game and lobby with players, Day/Stage/phase, who it waits on,
when it started and when it last moved. Manage Game picks one from a
dropdown built live from the server and either exports it or ends it —
ending being the only way a game finishes other than being played out,
since an abandoned game otherwise stays active and is resumed on every
restart forever. Ending always returns the deleted game's save, so nothing
is destroyed without being handed back first.
They are only-running because none of it is readable from disk: a save is a
seed plus a list of moves, so whose-turn-it-is exists only after a replay
through the engine, which lives in the game repo rather than here. The
running server has already done that work and is asked for the answer.
startos/serverApi.ts is the single place that asks.
store.json gained adminSecret (32 chars) beside joinSecret, seeded on
install and backfilled on update for a volume written before the field
existed. It is deliberately NOT the join secret: every player holds that
one, so gating a delete with it would let anyone at the table destroy
anyone else's game. init/generateJoinSecret.ts is renamed generateSecrets.ts
now that it mints both.
Also brought getJoinSecret's result strings under i18n(). They shipped as
plain strings two commits ago, which actions.md is explicit about — every
user-facing string including result titles, messages and thrown errors.
The new actions follow it, so the old one shouldn't be the odd one out.
Verified on phoenix.local, installed as an UPDATE from 0.5.2:0 rather than
a fresh install, which exercised three things at once: the boot log line
("Resuming 1 saved game(s)…"), the engine-version refusal firing for real
on a game recorded under 0.5.2, and the adminSecret backfill (store.json
came out with both secrets, 24 and 32 chars). Then, from inside the
container: the package-generated admin secret authenticating against
/api/games (200) while a wrong one is refused (403), health counts tracking
0 -> lobby 1 -> active 1 through a create/bot/start, and every field the
actions render present and correct on the listing.
NOT verified: the actions' own forms and result rendering. `start-cli
package action run` fails with a client-side deserialization error on every
action on this box — including the already-shipped get-join-secret and
actual-budget's equivalent — so it is a start-cli problem, not this
package's. The data path underneath them is verified above; the SDK
form/result rendering needs the web UI.
A test game (TRESTLE-3221, Alice + a bot) is left running on the box so
there is something for Games in Progress to show.
68 lines
3.4 KiB
Markdown
68 lines
3.4 KiB
Markdown
# Station Master
|
|
|
|
## Documentation
|
|
|
|
- [Rules and design docs](https://draco.local:53871/Jesse.Markowitz/station-master/src/branch/main/docs)
|
|
— the rulebook implications, the multiplayer design, and the game's architecture.
|
|
|
|
## What you get on StartOS
|
|
|
|
This service runs the multiplayer server: a lobby, and a table for 2 to 4 players to play a
|
|
competitive or cooperative game together from their own browsers. Everything a player needs — the
|
|
game itself, the lobby, and the connection back to this server — is served from the single web
|
|
interface below; there is nothing else to install or configure on a player's side.
|
|
|
|
## Getting set up
|
|
|
|
1. Run the **Get Join Secret** action from this service's Actions menu, and copy the value it
|
|
returns.
|
|
2. Share that secret, and this service's address, with everyone you want to play with. Anyone
|
|
holding the secret can create a new game or join one that hasn't started yet.
|
|
3. Open this service's **Multiplayer Table** interface. You'll land on the front page, which
|
|
offers three ways in: solitaire, the replay viewer, and multiplayer.
|
|
4. Click **Play multiplayer**, then **Create Game** (or **Join Game** with a game code someone
|
|
else created), and enter the join secret when asked.
|
|
|
|
## Using Station Master
|
|
|
|
### Multiplayer Table
|
|
|
|
The front page offers solitaire, the replay viewer, and multiplayer. **Play multiplayer** takes you
|
|
to the lobby: create or join a game, seat players (including filling empty seats with a bot), and
|
|
start. Once a game is underway, this same interface is where every player plays their turns and
|
|
watches the table — there is nothing else to open.
|
|
|
|
Solitaire runs entirely in your own browser and needs nothing from the server, so it works here
|
|
exactly as it does on the public Station Master site.
|
|
|
|
### Get Join Secret
|
|
|
|
Run this whenever you need the current join secret again, or want to shut out anyone still
|
|
holding an old one. Every run replaces the secret and immediately puts the new one into effect —
|
|
players already seated in a game are unaffected, but the old secret stops working for creating or
|
|
joining games from that point on.
|
|
|
|
### Games in Progress
|
|
|
|
Shows every game on the server: who is playing, which Day and Stage they have reached, and whose
|
|
turn it is. It changes nothing, so run it whenever you are curious. It is also how you spot a game
|
|
nobody is coming back to — one whose last move was days ago, still waiting on a particular player.
|
|
|
|
### Manage Game
|
|
|
|
Pick a game, then either save a copy of it or end it.
|
|
|
|
**Export** hands you the whole game as text and leaves it running. Save that text as a `.json`
|
|
file and you can open it in the replay viewer later to watch the game back.
|
|
|
|
**End the game** deletes it and disconnects anyone still watching. This is the only way to clear
|
|
a game that will never be finished — otherwise it sits there, and comes back every time the
|
|
service restarts. It cannot be undone, so the game's save is handed back to you when it happens:
|
|
that text is the only copy left, so keep it if the game was worth watching.
|
|
|
|
> One thing to know before you update this service: **games in progress do not survive an
|
|
> update.** The rules can change between versions, so a half-played game recorded under the old
|
|
> ones is refused rather than resumed under rules it was not played by. Nothing is deleted, and
|
|
> going back to the previous version makes them playable again — but the safe habit is to finish
|
|
> games before updating.
|