Skip to content
DHDorian
All projects
Playable MVPActive developmentMultiplayer strategy game

Karo

Karo is an original real-time multiplayer strategy game built around private 3–4 player rooms, a shared 19-region hex board, server-authoritative rules, Supply production, construction, trading, and Development Cards.

Source

Karo is a playable multiplayer MVP in active development. The core 3–4 player loop, optional scenarios and modules, and completed-match history are implemented; active-state durability, production deployment, browser E2E, accessibility depth, and a dedicated match-end presentation remain ongoing.

Role
Product design and full-stack engineering
Scope
Gameplay systems, real-time architecture, deterministic board modeling, optional modules, completed-match history, and product interface
Status
Playable MVP · Active development
Primary stack
React · TypeScript · ASP.NET Core · SignalR

Product interface

One authoritative match state

The supported 2D interface keeps the complete island, active turn, player standings, Supplies, Trails, Camps, Strongholds, harbors, Warden, and contextual actions visible in one synchronized match view.

Karo mid-game browser match showing three players, a complete illustrated hex island, Trails, Camps, Strongholds, harbors, the Warden, Victory Points, Supply inventories, and the active turn panel.

Product overview

Why this product exists.

Karo is an original browser-based multiplayer strategy game that translates a rules-heavy tabletop experience into a synchronized, board-first web application.

The ASP.NET Core backend acts as the authoritative source of active match state. React clients send typed actions through SignalR, while backend game services validate player identity, turn phase, construction costs, board connectivity, trading rules, Development Card timing, Warden actions, and scoring before synchronizing viewer-specific results.

The 19-region island is modeled through deterministic regions, vertices, and edges that drive Trail connectivity, Camp and Stronghold placement, harbor access, Supply production, and network-based scoring. The stable SVG interface keeps the island central while contextual panels and utility drawers expose secondary systems.

Karo is a playable MVP in active development. Base multiplayer, four scenarios, optional Karo Tactics and Public Ambitions, and optional SQL-backed completed-match history are implemented; active rooms, sessions, reconnect state, and matches remain in memory, the 3D renderer is experimental, and dedicated match-end presentation, browser E2E, responsive and accessibility depth, and production deployment remain unfinished.

Problem / motivation

Rules-heavy multiplayer strategy only works when every client agrees on legal actions, turn phase, hidden information, costs, connectivity, trading, and scoring. Karo keeps the shared board understandable while the backend remains authoritative.

Product experience

Key features.

  1. 01

    Built a server-authoritative multiplayer loop where SignalR actions are validated by backend game services before viewer-specific state is broadcast.

  2. 02

    Modeled the 19-region board through deterministic regions, vertices, and edges that drive placement, connectivity, harbors, Supply production, and scoring.

  3. 03

    Implemented rule-safe multi-step workflows for setup, construction, trading, Development Cards, Warden resolution, optional modules, and turn progression.

  4. 04

    Protected private player state through viewer-aware DTOs that hide Development Card identities, exact opponent Supplies, private Tactics choices, and reconnect credentials.

  5. 05

    Separated in-memory active match state from optional EF Core and SQL Server snapshots that persist completed-match summaries without storing private hands or reconnect tokens.

Under the surface

Architecture and technical challenges.

Architecture

  • React 18 and TypeScript client with a supported SVG board, contextual action panels, utility drawers, rules help, and an experimental React Three Fiber renderer
  • ASP.NET Core on .NET 10 with in-memory lobby, session, lifecycle, topology, game, scenario, Tactics, and Public Ambition services as the authority for active play
  • SignalR actions, monotonic state versions, reconnect tokens, and viewer-aware DTOs for synchronized shared state without exposing private Development Cards or exact opponent Supplies
  • Deterministic regions, vertices, edges, and harbor slots for construction connectivity, Supply production, maritime rates, Largest Army, and Longest Trail calculations
  • Optional Entity Framework Core and SQL Server persistence for completed-match summaries and history; active rooms, sessions, reconnect state, and matches remain process-local

Challenges

  • Deriving legal construction targets from the same stable board graph used by backend validation
  • Coordinating multi-step SignalR workflows for snake-order setup, trading, Development Cards, Tactics, and Warden resolution
  • Preventing temporary client interaction state from becoming a competing source of active match truth
  • Protecting private cards, exact opponent Supplies, Tactics choices, and reconnect credentials in shared updates
  • Persisting useful completed-match history without implying durable recovery for active multiplayer state

Technology stack

React 18TypeScriptVite 5Tailwind CSSASP.NET Core (.NET 10)SignalRSVGReact Three FiberEntity Framework Core 10SQL Server (completed history)Docker ComposeCustom .NET and Node test harnesses

Delivery status

What exists today.

Completed

  • Private six-character rooms, 3–4 player readiness and start, reconnect grace handling, host migration, forfeit, post-game lobby, and rematch
  • Snake-order setup, dice and Supply production, finite-piece construction, roll-seven Warden flow, and shared Game Log
  • Default, generic-harbor, resource-harbor, and direct player trading
  • Finite Base Game Development Card deck with Knight, Road Building, Year of Plenty, Monopoly, and Victory Point
  • Largest Army, Longest Trail, scenario-aware Victory Point scoring, and win detection
  • Four scenarios, optional Karo Tactics, and optional Public Ambitions
  • Optional EF Core and SQL Server completed-match history
  • Supported SVG 2D board and the verified six-image portfolio set

Partial

  • Responsive optimization and screen-reader accessibility depth
  • Dedicated match-end presentation beyond the existing winner and rematch state
  • Scenario, Tactics, and Public Ambition balance playtesting
  • Frontend test depth and manual cross-browser coverage

Experimental

  • 3D board renderer

Planned

  • Durable active room, session, reconnect, and match recovery
  • Accounts, profiles, global matchmaking, spectators, bots, replay, statistics, and leaderboards
  • Browser multiplayer E2E, automated accessibility scans, and repeatable screenshot-capture tooling
  • Production deployment and operational hardening

Interface

Surface 01

Private rooms and live presence

Private six-character room codes, host identity, player readiness, and live connection state keep the 3–4 player setup understandable before the backend creates the authoritative match.

Karo multiplayer lobby showing room code KARO24, four connected players, Host identity, ready states, the current user, a room-copy action, and Ready Up controls before the match starts.

Surface 02

Contextual, rule-safe construction

Legal targets come from deterministic vertices and edges, so the interface can expose contextual build actions while the backend validates turn, ownership, connectivity, costs, and finite pieces.

Construction

Close Karo board view showing a selected legal Trail edge, an existing player network, Wood and Clay cost, remaining Trail pieces, and a Confirm Build action.

Synchronized Supply production

Karo match after a deterministic dice roll with the island visible, updated Supply inventories, and a Game Log showing Supply production entries for multiple players.

Surface 03

Harbor-aware maritime trade

Owned coastal structures determine available exchange rates. The drawer separates a resource-specific 2:1 harbor route, default bank alternatives, and direct player trading while the board remains visible.

Karo match with the Trade drawer open, showing a two-for-one Wood Harbor route, Give and Receive controls, and direct player-trade options while the board remains visible.

Surface 04

Private Development Card strategy

Viewer-aware card state keeps identities private while exposing timing restrictions, playable and locked states, Supply-selection controls, and hidden Victory Point information only to the owner.

Karo Development Cards drawer showing purchase cost and deck count, playable Knight and Year of Plenty cards, Road Building locked because it was bought this turn, and a private hidden Victory Point card.

Honest edges

Limitations and what comes next.

Current scope

  • Rooms, sessions, reconnect state, and active matches remain in memory and reset when the API restarts.
  • SQL Server persistence is optional and stores completed-match summaries only; Karo does not yet provide durable active-match recovery, user accounts, profiles, global matchmaking, spectators, bots, or replay.
  • A basic finished state, winner, post-game room, and rematch flow exist, but the dedicated match-end presentation is still planned.
  • Backend and focused frontend checks are implemented, but full browser multiplayer E2E, automated accessibility scans, broader cross-browser coverage, responsive optimization, and screen-reader depth remain incomplete.
  • The stable 2D renderer is the supported experience; the 3D renderer remains experimental.
  • Karo is not production deployed and does not claim commercial release, real-player adoption, or production multiplayer usage.

Future improvements

  • Persist active rooms, sessions, reconnect state, and matches without weakening server-authoritative validation.
  • Add browser-level multiplayer E2E, automated accessibility checks, cross-browser coverage, and repeatable capture automation.
  • Finish responsive optimization, screen-reader navigation, and the dedicated match-end presentation.
  • Continue scenario, Tactics, and Public Ambition balance testing before expanding optional content.
  • Define production hosting, secrets, monitoring, and database operations before making any release claim.
  • Continue the optional 3D experiment without weakening the supported 2D experience.