Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Research: Game Mechanics Prior Art

This note records the external game-mechanics grounding used for Aurelian Frontier planning. It exists because the original planning commit 79a9afc translated external mechanics references into capability-shaped Aurelian tasks, but did not leave a standalone research note. The recorded planning rationale for that commit used Stardew Valley, EVE Online, Evil Islands, PixiJS, and Tiled references, with an explicit instruction not to clone those games. This note covers the game systems used by Aurelian: Stardew Valley, EVE Online, and Evil Islands.

Source Snapshot

Checked on 2026-04-29:

The Stardew Valley Wiki and EVE Online support/academy pages are treated as the primary grounding for their systems. For Evil Islands, the official FAQ mirror and Nival page ground construction and broad tactical identity; Ars Technica and PlayItHardcore are secondary sources for combat details.

Planning Audit

Commit 79a9afc records the durable planning outcome: external mechanics are inputs to capOS-shaped tasks, not clone targets. The planning context named these stable mechanics:

  • Stardew Valley: seasons, festivals, schedules, gifts, and affection.
  • EVE Online: brokered markets and blueprint/material/facility industry.
  • Evil Islands: material/level/gold/equipment construction and limited enchantment.
  • PixiJS/Tiled: later browser-client rendering, outside this note’s mechanics scope.

The commit body for 79a9afc says the patch translates external mechanics into capOS-shaped tasks for seasonal calendars, regional settlements/outposts, service-mediated order books, blueprint/artifact construction, token-budgeted agent NPCs, and a 2D tilemap browser client. This research note keeps that translation explicit and auditable.

Stardew Valley

Stable mechanics to borrow:

  • Seasons create calendar pressure. Stardew Valley uses four seasons of 28 days; routines, festivals, visuals, and available resources can vary by season.
  • Resource availability is table-driven. Crops, forage, fish, and shop selections are season-sensitive.
  • Season boundaries matter. Ordinary crops wither at season change unless they are explicitly multi-season.
  • Festivals are scheduled events that can alter access, activities, prizes, shops, dialogue, and social opportunities.
  • Relationships are explicit profile facts. Talking, gifts, missed interaction, and events affect a visible relationship meter rather than being pure flavor.

Aurelian translation:

  • Model AdventureCalendar as explicit service-owned state, with fixed-smoke calendar values for deterministic QEMU proof and separate production seeds later.
  • Keep seasonal resources bounded and generated from content: crops, forage, fish, shop stock, route hazards, and outpost production.
  • Make multi-season resources explicit in content validation.
  • Treat festivals and military events as scheduled overlays that affect actor presence, witness availability, shop stock, route risk, quests, and debrief choices.
  • Store gifts, favors, affection, faction standing, and event participation as profile or ledger facts owned by game services, not client-local counters.

Do not borrow:

  • Unbounded daily chores as the core loop. Aurelian is an expedition and authority game; calendar pressure should sharpen mission choices, not become farm maintenance.
  • Client-owned social counters. Social state must remain authoritative and auditable.

EVE Online

Stable mechanics to borrow:

  • Markets are brokered. Buy and sell requests go through an order-matching system rather than choosing a specific counterparty directly.
  • Market eligibility matters. Some assets can be traded through market orders; others require contracts, custody, corporation roles, or special flows.
  • Matching is deterministic and rule-driven. Orders match immediately when compatible prices and ranges cross; otherwise they remain listed.
  • Industry is blueprint and job based. Manufacturing uses blueprints, materials, job types, time, and facility or slot constraints.
  • Production decisions have location and logistics consequences.

Aurelian translation:

  • Keep the current actor-local market verbs as the proof slice, then evolve toward a MarketService or equivalent service-owned order book.
  • Define market-eligible item classes. Ordinary stackable supplies can use buy/sell orders; relics, writs, witness-certified custody, and dangerous artifacts move through explicit custody or contract-style protocols.
  • Implement order books with side, item, quantity, price, location/range, expiry, fees, idempotency keys, and ordered ledger receipts.
  • Route multi-owner exchange through reserve/escrow, commit/release, stale-version rejection, cancellation, retry, and crash recovery.
  • Use blueprint jobs for construction: inputs, facility, duration, authority gates, output bounds, and service-owned job state.

Do not borrow:

  • A fully player-driven MMO economy as the first target. Aurelian needs a small authoritative regional economy that proves capability boundaries before it needs market depth.
  • Market transfer for every object. Authority-bearing objects should stay outside generic order books unless a later design proves the custody model.

Evil Islands

Stable mechanics to borrow for construction:

  • Equipment construction combines a design/blueprint with material choices and money; unavailable material can be bought as part of assembly cost.
  • Material class and quality affect item properties. Materials carry distinct weight, durability, energy/complexity, damage, armor, and vulnerability characteristics.
  • Constructed or repaired items can be inspected before committing the job.
  • Enchantment is constrained by object capacity and spell complexity; equipment can carry limited spell effects instead of arbitrary modifiers.

Stable mechanics to borrow for combat:

  • Damage type matters. Slashing, piercing, and crushing style differences make weapon choice meaningful against different enemy defenses.
  • Body-part targeting adds tactical texture. Head, hands/arms, and legs have distinct consequences such as critical risk, attack/casting slowdown, and reduced pursuit.
  • Sight and scouting shape fight selection. Long vision and stealth let the player choose engagements instead of charging every hostile.
  • Pulling and alert behavior are tactical risks. Enemies can notify related enemies, so careless engagement can turn one fight into many.
  • Cast time is a combat risk. Offensive magic can be punished if the player casts while exposed.

Aurelian translation:

  • Put construction inputs in generated content: blueprint, required materials, facility class, cost, duration, rank/star/circle gates, output bounds, artifact authority, and enchantment slots.
  • Derive bounded item properties from blueprint, material, facility quality, paid cost, and player competence. Avoid unbounded loot rolling.
  • Use a small deterministic target-zone set for combat: head, hands, legs, and core.
  • Add damage/mitigation metadata for weapon type, spell type, zone armor, ward state, and inspected knowledge.
  • Make scouting and inspection upgrade enemy information from rough threat to zone armor, ward state, intent, and likely counters.
  • Support stealth openings and pull/alert behavior as explicit service-owned state transitions with readable causality in transcript output.
  • Add fatigue and cast interruption as explicit costs. Retreat should be hard when a mob blocks it, but failures must be legible and deterministic.

Do not borrow:

  • Hidden real-time randomness or reaction-speed demands. Aurelian’s proof path remains command-level and deterministic.
  • Punitive infinite-monster-fatigue behavior. Monsters can pressure retreat, but the service should name the reason and keep rules fair enough to test.
  • Gore or locational damage presentation as spectacle. Body zones exist for tactical outcomes and readable state.

Cross-Game Design Rules For Aurelian

  • External mechanics are planning inputs, not clone targets.
  • Every durable fact that matters to public world state belongs in an authoritative service: calendar, market, construction jobs, profile progression, social standing, custody, and receipts.
  • Every user-visible refusal should name the missing gate: authority, location, rank, resource, stale version, custody, fatigue, target state, or policy.
  • Use pure Rust tests for deterministic rules: calendar rollover, seasonal availability, market matching, construction validation, property derivation, target-zone damage, fatigue, and alert propagation.
  • Use a real capOS userspace test process for cross-service scenarios: expedition flow, custody, market reserve/commit/release, construction jobs, and party transfer.
  • Keep the shell transcript as a low-dependency smoke proof and command-parser proof. It should not be the only test for complex gameplay state machines.