Clouds-War

Context

Clouds-War started from a simple game idea, but it quickly became a systems problem.

The visible game is direct: three teams fight over a realistic territorial map. Each player has only a few actions per day. A territory matters only if it stays connected to the team's headquarters. The shared resource, Clouds, is both the team bank and the season score.

That gives the game a clear center.

It is not a game about clicking faster than everyone else. It is a game about reading a moving map, choosing a pressure point, and making a rare action count because the team understands the line together.

Product Shape

The product is designed around a short daily rhythm.

A player should be able to open the game, understand the front, read what the team is trying to do, and contribute in a few minutes. The depth comes from consequence, not from interface density.

The main surface is the war room.

It is map-first by design: the map carries the state of the season, the territorial pressure, the hubs, the operations, the isolated regions, and the places where a single decision can shift the shape of the front. Social tools exist around that map, but they do not replace it.

The design target is deliberately sparse. Dark field, off-white text, hairlines, restrained chrome, strong typography, and team colors reserved for gameplay meaning. The game should feel authored, but still fast to read.

System

The current repository is a working monorepo, not a pitch document.

It contains:

• apps/web for the public player surfaces
• apps/admin for operators and support
• apps/api for the authoritative gameplay API
• apps/worker for ticks, season lifecycle, and scheduled jobs
• shared packages for auth, contracts, rules, database access, map data, UI, and runtime config

The stack is intentionally pragmatic.

Next.js carries the web and admin apps. Hono keeps the API small and explicit. PostgreSQL and Drizzle hold the season state. Graphile Worker runs the timed parts of the game. MapLibre renders the tactical map. SSE carries live server-to-client updates, while player commands stay as explicit HTTPS writes.

That split keeps the game understandable operationally. Commands should be logged, validated, and replayable. Live updates should help the client stay fresh. The server remains the authority.

What Is Already Real

The local runtime already covers a concrete part of the loop:

• username and password auth
• role-based routing between player and admin surfaces
• current season, snapshot, and recap endpoints
• gameplay commands for attack, fortify, repair, build hub, and ping
• global and team chat
• SSE streams
• hourly tick, operation expiry, season closure, and recap generation
• a playable war room on seeded local data
• admin routes for season overview, player lookup, command lookup, and incident timeline
• unit, e2e, and visual workflow foundations

The project is still in active build.

The current gaps are also clear: the admin surface needs more depth, visible language still needs full French consistency, returning-player orientation needs sharper summaries, and the map editor remains a documented target rather than a finished product surface.

Below The Surface

Clouds-War has a deeper world behind it, but the project is very strict about how that world enters the product.

The player should not need a lore briefing to play. The first promise stays readable: join a team, read the map, use scarce actions well, and coordinate.

That deeper layer appears through pressure rather than exposition: team doctrines, season names, briefings, archives, recap fragments, and the slightly strange weight of certain product words. It should make the game feel larger than the screen without forcing the player to decode everything before acting.

That restraint is part of the design.

The game needs mystery, but not confusion. It needs a world, but not a homework assignment. The lore is there to make repeated seasons feel like they belong to a larger structure. It is not there to explain the core loop away.

Tradeoffs

The biggest product tradeoff is restraint.

It would be easy to add more panels, more public backstory, more visible lore, more admin tools, more map ambition, or richer realtime presence too early. Most of those moves would make the project feel bigger while making the actual game less sharp.

The build is therefore sequenced around a smaller number of strong invariants:

• the map must tell the story first
• the server must stay authoritative
• every daily action must feel consequential
• social coordination must be useful without becoming noise
• the world must deepen the game gradually
• a future map should not require rebuilding the engine

Direction

The next useful work is not to make Clouds-War louder.

It is to make the existing loop more coherent: harmonize the visual system, finish the admin depth, improve returning-player summaries, strengthen contextual help, and keep hardening the worker and visual review workflow.

The ambition is a game that feels immediate on the first session and more charged after the third season.

Readable first. Deeper later. Built as a system from the start.