Independent project · Active
Matcha! Suite
Thirteen modular server products covering competition, progression, delivery, commerce, player movement, and live systems. Briar designed, built, documented, and released the suite.
- My role
- Product design, systems, code, interface, identity, documentation, tools, and releases
- Runtime
- Server-side JVM modules · exact dependencies vary by product
- Project scale
- 13 live modules · hundreds of documentation pages · 19 browser authoring tools
- Web platform
- Product site · documentation · authoring tools · services · dashboard · release infrastructure
Competition · progression · delivery · commerce · movement · live systems
Product site · documentation · services · dashboard · release infrastructure
About this case study. The diagrams condense documented implementations and behaviour into a readable overview. Links beside each selected system open the corresponding documentation. Planned and concept-stage modules are not included in the live-module count.
Overview · The suite
Thirteen products, one suite.
Each product owns one server responsibility and has its own installation path. Shared services appear where coordination is necessary, but operators do not have to deploy the suite as one application.
- 01Module boundaries follow server responsibilities, not pages in one shared user interface.
- 02Ceremony supplies selected shared persistence and service components; requirements are declared per install guide.
- 03MongoDB and Redis appear only where durable or distributed state requires them.
- 04Configuration, permissions, diagnostics, and recovery are part of every product.
| ID | Module | Owned responsibility | Implemented surface |
|---|---|---|---|
| 01 | Frontier | Ranked battle system | Queues, formats, ratings, arenas, seasons, tournaments, replays |
| 02 | Journey | Quest and progression runtime | Tasks, parties, zones, flags, timelines, encounters, scripts |
| 03 | Courier | Mail and reward delivery | Messages, durable packages, offline delivery, claim recovery |
| 04 | Bazaar | Creature and item market | Listings, auctions, buy orders, collections, browser market |
| 05 | Link Cable | Cross-server player state | Ownership, six state lanes, handoff, backups, restore |
| 06 | Smart Trainers | NPC battle AI | Reusable move, switch, item, doubles, and gimmick policies |
| 07 | Bloom | Targeted spawn lures | Placed area effects for type, species, form, shiny, and ability odds |
| 08 | Outbreaks | Timed spawn events | Configured pools, alerts, distance, progress, limits, rewards |
| 09 | Venture | Creature jobs | Eligibility, timed work, persisted assignment, result and return |
| 10 | Alchemy | Item migration | Data-driven conditions, transformations, preservation, cleanup |
| 11 | Wonder | Queued WonderTrade | Channels, eligibility, matching, fallback pools, delayed claims |
| 12 | ShowdownActions | Custom battle effects | Data-defined forms, buffs, status, weather, and terrain |
| 13 | MoLang Extensions | Expanded scripting | Functions, conditionals, loops, structs, and imports |
Selected system · Link Cable
Distributed player ownership and handoff.
Link Cable runs on every application backend while the proxy remains unmodified. One backend is the orchestrator; the others participate in guarded handoffs through shared Redis and MongoDB services.
- 01Acquire per-player distributed lock
- 02Verify source ownership and current epoch
- 03Persist synchronized lanes; prepare hot handoff state
- 04Fence old ownership; advance the owner epoch
- 05Load on the target and acknowledge the new owner
- 06Settle the transfer and release the lock
Player core includes inventory, ender chest, hunger, XP, abilities, recipe book, and supported attached component data.
Ownership invariants
- Writer
- Only the backend holding the current ownership epoch may write live state.
- Concurrency
- Transfers for one player serialize behind the same distributed lock.
- Persistence
- MongoDB is canonical; Redis holds short-lived coordination and handoff data.
- Liveness
- Backend heartbeats let the network identify an owner that has disappeared.
Recovery paths
- Backup unit
- One backup contains all six synchronized lanes.
- Restore gate
- The player must be offline before an operator can restore state.
- Overwrite guard
- A new backup is taken before an existing state is replaced.
- Crash exposure
- Periodic flushing bounds the window between live state and canonical storage.
| Observed condition | Risk | System response | Operator surface |
|---|---|---|---|
| Duplicate transfer request | Two writers race | Per-player lock serializes the requests | Busy / retry signal |
| Stale source resumes | Old state overwrites new | Owner-epoch fencing rejects the stale writer | Safety log |
| Orchestrator unavailable | Authority cannot settle handoff | In-flight transfers retry and stall; participants already hosting players remain live | Role and heartbeat status |
| Bad or missing target state | Player loss | Transfer remains a recoverable operation; canonical snapshots and backups remain available | Validation checklist + backup commands |
| Manual restoration | Overwrite live player data | Offline-only restore with a pre-overwrite backup | Explicit admin command |
Selected system · Journey
Event-driven content execution.
Journey separates content data from runtime machinery. Authors define tasks, zones, flags, timelines, buffs, parties, and encounters; the server translates game events into scoped progression state.
Working excerpt · Sanitised runtime model
Author → event → state
Move the nodes without changing the logic, inspect their definitions, then send a representative event through the graph.
{
"id": "field_survey",
"sequential": "sequential",
"party_shared": true,
"tasks": [{
"event": "SUBJECT_CAPTURED",
"filter": "q.subject.species.identifier == 'example:species'",
"target": 5
}]
}Illustrative reduction of the public task schema. Domain identifiers are generalised; presentation fields and rewards are omitted.
Declarative path
JSON task and content files cover repeatable progression without requiring a new compiled module for each questline.
Imperative path
Scripts subscribe to game events and execute bounded custom behaviour when the data model is not enough.
Iteration path
Hot reload, in-game editors, generated references, and browser authoring tools shorten the path from authoring to testing.
Selected system · Bazaar
In-game, domain, and browser transaction surfaces.
Bazaar exposes the same market through the game, a domain and persistence layer, and an optional browser dashboard. Authentication begins in game; market and player events return over HTTP and WebSocket.
A component map of the implemented routes, filters, charts, and client behaviour. No production market data is shown.
Working excerpt · Replayed event contract
One transaction, three audiences
A fixed representative trace across the browser, market domain, and scoped subscribers. No production market data or live connection is used.
- 01Validate player, channel, asset, limits, and price controls
- 02Create a durable listing with an identity key
- 03Expose the same listing in game and over the API
- 04Settle purchase, bid, expiry, cancellation, or buy-order fill
- 05Collect resulting assets through player-scoped durable entries
- 06Publish market and player events to subscribed clients
Web event contract
{ type, timestamp, payload }Cross-server mode
- Topology
- Local or orchestrator / participant roles, with Redis connecting nodes.
- Compatibility
- Every participating node must run the same Bazaar version.
- Degraded state
- Read-only behaviour preserves inspection while writes cannot be trusted.
Operator controls
- Freeze
- Stop market mutation without removing its history.
- Reconcile
- Inspect and repair differences between expected and persisted market state.
- Security
- Configured limits, detectors, permission gates, alerts, and audit-facing inspection.
Selected system · Frontier
Queue-to-result state machine.
Frontier turns a queue entry into a validated competitive match and result. Rating, team legality, opponent search, arena capacity, battle timing, results, and replay data are parts of one lifecycle.
Snapshot rating on entry
The queue compares players against the state they entered with, not a value that can drift invisibly during the wait.
Expand search over time
Match quality starts narrow; a configurable rating window expands as queue time grows.
Validate twice
A legal queue entry does not guarantee a legal battle-start team. The second gate catches changed state.
Allocate world capacity
Arenas are finite resources with positions, restrictions, return behaviour, and cross-server ownership.
Bound the live match
Turn timing, disconnect handling, observation, and recovery prevent a competitive match from becoming indefinite.
Keep match history
Result history and in-world replay let players revisit a battle after it has finished.
What I made · Process · Outcome
From product code to public release.
Alongside the modules, Matcha includes the material needed to configure, inspect, update, and recover the software. The project is published through working releases, authoring tools, documentation, and operator controls.
Documentation & tools
Astro 5 · Starlight · React 19 · TypeScript · Radix UI · Tailwind
Visual authoring
Blockly · React Flow · Three.js · Mermaid · JSZip
Backend & commerce
Fastify 5 · TypeScript 5.8 · Drizzle ORM · SQLite · Discord.js · Stripe · web push
Operations
React + Vite admin dashboard · Cloudflare Worker · read-only TypeScript MCP server
Product code
Server modules, selected shared Ceremony services, persistence models, command and permission surfaces.
Authoring formats
HOCON, JSON, datapacks, GUI definitions, tooltips, themes, scripts, and module-specific schemas.
Browser tools
19 public authoring and inspection tools in the documentation site snapshot.
Documentation
Hundreds of public pages covering installation, configuration, concepts, reference, examples, rollout, and recovery.
Releases
Per-module files, compatibility notes, dependencies, version history, and release portal entries.
Validation
Input checks, permissions, dry paths, health signals, staff inspection, backups, restore, and migration guidance.
Public links