Active Play and Session Shape¶
Target Session Model¶
The game should support two session types:
2-5 minute sessions: collect results, repair, eat, restock, list goods, post jobs, or launch the next expedition.10-20 minute sessions: compare markets, plan routes, coordinate a group expedition, review codex entries, craft chains, or manage guild affairs.
What the Player Actually Does¶
During active time, the player should be choosing among meaningful options rather than manually executing moment-to-moment actions.
Typical loop:
- Log in and review completed travel, combat, crafting, or market events.
- Address survival needs and injuries.
- Prepare gear, supplies, and risk limits.
- Choose a mission, gathering route, survey action, or trade run.
- Commit the hero to that action.
- Return later to resolve outcomes and make the next decision.
Async Design Principles¶
No Mandatory Real-Time Windows¶
No game activity should require the player to be present at a specific clock time. Town control contests and scheduled events have windows, not single moments. A player who can log in for five minutes at midnight and five minutes at noon should make real progress.
Auctions, contracts, and board orders all operate on day-scale timers. Expedition resolution is based on simulated time, not real elapsed time — a 4-hour expedition resolves whenever the player returns to check results, even if they logged in 12 hours later.
Async Does Not Mean Disconnected¶
The async model works because the simulation layer keeps running without the player. Town reserves tick daily, events fire and resolve, prices shift, and other players' actions affect the world. When the player logs back in, their decisions happen in a world that has changed — this creates the feeling of a persistent, lived-in game even for players who can only check in once per day.
Short-session players still benefit from the world's momentum: their market orders fill while they are gone, their guild's town control standing builds from other members' activity, and their farming operations advance autonomously.
The Game Should Not Punish Absence¶
A character left idle takes no damage, suffers no decay of gear, and loses no standing simply from not logging in. Survival needs (food, water, injury) are only consumed during active expeditions, not while the character is in town. This means a casual player who logs in once every 3 days is not walking into a crisis — they find a character who is rested, stable, and ready to launch.
The exception is time-sensitive player contracts that expire. If a player accepts a board order and does not complete it within the deadline, the order fails and the posting fee is not refunded. This creates stakes without punishing long absences — players simply should not accept short-window orders they cannot commit to.
Meaningful Choice, Not Manual Execution¶
Active play should be defined by the quality of the decision, not the number of clicks.
The game avoids: - manual resource collection that requires clicking 40 nodes in sequence - combat that requires real-time dodge inputs to succeed - crafting that requires timed minigames at every step - market activity that requires staring at an order book refreshing every 30 seconds
The game requires: - loadout selection that actually matters (wrong gear means higher failure risk) - supply pack composition (bringing too little shortens the expedition; too much wastes coin) - expedition type choice (wrong type for the destination means a less profitable run) - risk tolerance settings (safety rules are real trade-offs, not a difficulty slider) - route selection (which path to take, knowing some routes are faster and others safer) - market timing (when to sell and when to hold based on reserve-driven price cycles) - guild and group coordination (shared knowledge, divided labor, complementary skills)
These are strategic decisions, not execution requirements. A player who makes thoughtful decisions will consistently outperform a player who makes reflexive ones, regardless of how fast they click.
Session Entry Points¶
The game should support multiple natural re-entry points so a player can decide in seconds what to do on login:
| What the player sees | Immediate action available |
|---|---|
| Expedition results notification | Review results, collect loot, settle contracts |
| Auction won / outbid | Collect item or revise bid |
| Board order complete (another player filled theirs) | Confirm, post follow-up, or repost |
| Town supply alert | Post a gather order, stock up before prices rise, plan a supply run |
| Guild announcement or message | Read, respond, coordinate |
| Nothing active | Browse board, plan next expedition, craft chain continuation |
A player who logs in without a pending notification should never feel lost. The board is always populated, the market is always active, and the codex always has something to review or a site to follow up on.
Time Investment Ladder¶
Players should be able to engage at different depth levels and find proportionate returns at each:
| Time per week | Expected activity | Expected returns |
|---|---|---|
| 5–15 min | Launch one expedition; check market once | Steady coin income; basic board progression |
| 30–60 min | Two expeditions; crafting batch; market adjustment | Moderate coin and materials; rank progress |
| 2–4 hours | Multiple expedition types; crafting chain; guild coordination | Full economy participation; knowledge selling; meaningful board completion |
| 4+ hours | Town control participation; group expedition planning; teaching/guild management | Top-tier economic influence; leadership roles; most complex content |
Players at the top tier are not meant to "out-grind" players at the lower tiers in a way that shuts them out. A casual player who sells consistently useful goods to a well-run guild creates genuine value for that guild's output. Depth is rewarded, but exclusion is not the design goal.
Why This Fits the Product¶
This keeps the game usable as a side game. It also aligns with a low-cost backend because the server records intent and timestamps instead of simulating a full world every frame.
AFK Design Rules¶
- Every long action needs clear duration, risk, and expected reward.
- Every action should have interrupt, retreat, or fail states.
- The player should be able to set simple safety rules before departure.
- The game should reward planning, logistics, and information rather than idle clicking.