Browser-First Constraints¶
Purpose¶
This project is being designed as a browser game first, not as a desktop MMO that happens to run in a tab. Every major system should be filtered through browser reality.
Core Browser Rules¶
1. Short Active Sessions¶
Players should be able to make progress in 2-5 minutes. That means most important actions need to be understandable, resumable, and low-friction.
2. Async Over Always-Live Simulation¶
The game should prefer timer-based and command-based systems over continuous simulation. Browsers are a poor fit for large-scale always-online combat loops and constant background processing.
3. Low Input Burden¶
The player should not need fast click accuracy or high actions per minute. Systems should resolve from planning, choices, and loadouts rather than constant manual execution.
4. Readable UI at a Glance¶
Important decisions should be made from summaries, not from digging through dense spreadsheets every login. The browser client should privilege dashboards, panels, clear timers, and risk summaries.
5. Lightweight Rendering¶
The client should keep scene counts, animation complexity, draw overhead, and memory churn controlled. SVG reuse, layered assets, and simplified scene composition are preferred over heavy real-time visual simulation.
6. Interruption Tolerance¶
Players will tab away, close the browser, switch devices, or lose focus often. Every important system must survive interrupted play gracefully.
7. Network Resilience¶
Commands should be safe to retry, state should be server-authoritative, and the client should tolerate stale views until refreshed. A browser game must expect inconsistent latency and frequent reconnects.
What This Means for Major Systems¶
Combat¶
Combat should be strategy-first and async-resolved. Live action combat should not become the main loop unless the whole architecture changes.
Gathering¶
Gathering should be route, tool, and time based, not a twitchy harvesting minigame. Site discovery and extraction planning are better fits than spam-click node collection.
Crafting¶
Crafting should be job-based with clear recipes, material roles, and workshop queues. Avoid overcomplicated inventory Tetris or drag-heavy interfaces as the main progression path.
Towns¶
Town simulation should produce readable outcomes: shortages, surpluses, projects, and board changes. Players should not need to micromanage hidden civilian AI to feel that a town is alive.
Dynamic events should appear as understandable cards, markers, and urgency states, not as invisible systems the player can only infer from spreadsheets.
Markets¶
Markets should feel deep, but the client should expose them through compact filters, saved searches, clear deltas, and historical summaries rather than giant unreadable tables.
Device and Display Assumptions¶
Even if desktop is the main target, the UI should assume:
- variable window sizes
- tab switching
- limited session time
- possible touch or trackpad input
- frequent alt-tabbing to another main game
Good Browser-Fit Signals¶
A system is probably browser-appropriate if:
- it can be explained quickly
- it is resilient to disconnects
- it can be resumed from a summary screen
- it does not need precise continuous control
- it works with commands, timers, and clear results
- it turns world changes into short readable opportunities instead of live attendance obligations
Bad Browser-Fit Signals¶
A system is drifting out of scope if it depends on:
- permanent foreground attention
- hundreds of rapid clicks per session
- precise frame timing
- huge synchronized player counts in one combat space
- constant real-time simulation for basic progression
Design Check¶
Every new system should answer:
- why this is a good browser interaction
- how it behaves when the player tabs away
- how it resolves cheaply on the backend
- how the result is shown clearly in one or two screens