17 · Technical

Status: Skeleton · Owner: TBD · Updated: 2026-09-23

Purpose

Record the technical shape of the game and the constraints design must respect. Engineering owns this page; design reads it before promising anything.

To define

• Engine and language
• Target platforms, OS versions, minimum device spec
• Client/server split — what is authoritative where
• Server architecture: shards, regions, hosting
• Combat resolution: server-side simulation vs deterministic replay
• Real-time requirements (if any) and netcode approach
• Live config: what can change server-side without a client update
• Data/telemetry, analytics events, and the dashboards that matter
• Anti-cheat and bot detection
• Build, CI and release process; store review lead times
• Save/account system, cross-device, account recovery

Think about

• The single biggest technical question is the one from Battle: is combat real-time? Async formula-resolved combat is a well-understood, cheap, horizontally scalable problem. Player-controlled real-time combat means synchronous sessions, netcode, matchmaking, reconnection, spectating and a far higher device floor. These are different projects with different budgets. Do not let this stay open.
• Server-side live config is a design capability, not an engineering nicety. If reward tables, event parameters, costs and store contents can only change via a client release, your live-ops calendar is hostage to store review. This is the cheapest thing to build early and the most expensive to retrofit.
• World map state is the hard scaling problem. Thousands of players, live marches, tile ownership, and everyone watching the same region. Prototype this before committing to map size or interception mechanics.
• Time is the substrate of the whole game — build timers, march ETAs, shield expiry, event windows. Server-authoritative time, clock-tamper resistance and correct handling across time zones and DST are load-bearing. Clock exploits are the classic cheat in this genre.
• Telemetry designed after launch answers no useful questions. Instrument the funnel, the economy faucets/sinks and the event participation curve before soft-launch, or you will be tuning by vibes.
• Store review lead time is a live-ops constraint. If a hotfix takes 48 hours to reach players, the event calendar needs that slack built in.

Open questions

#	Question	Blocks	Owner
1	Engine choice?	Everything
2	Is any part of combat real-time?	Architecture, budget, scope
3	Minimum device spec?	Art, battle scale