# Build Riverward: a browser-based strategy game

Build, run, test, and deliver a playable original desktop-browser real-time strategy game using the brief below. Implement the game, test the actual gameplay, and repair issues you find. Prioritize a complete, coherent experience over optional features.

## The experience

Working title: Riverward, an original title placeholder, not a trademark-cleared brand. Make it feel like an actual compact RTS: establish a settlement, assign workers, gather resources, build production and defenses, explore terrain, unlock useful upgrades, command troops, survive an enemy attack, and rebuild. The setting, ruler, people, geography, and events are fictional. Do not use Age of Empires code, logos, music, art, or exact interface. The player is the ruler; their own impressions and dreams form a light strategic layer. Most engagement comes from the world, economy, progression, and battles.

Target desktop browser, mouse and keyboard, 16:9 and usable at 1280x720 through 1920x1080. Use a maintainable local stack you can verify; keep dependencies and network requirements small, and consult current official docs where needed. Prefer a real simulation rendered with Canvas/WebGL and a readable interface. Do not deliver a dashboard or a collection of static cards pretending to be a game. No login, account, payment, tracking service, external runtime API, or multiplayer backend. Once installed locally, gameplay must work without external services.

Art direction: original stylized angled overhead/isometric landscape, warm stone and timber, cultivated greens, readable river and elevation, coherent buildings with visible growth, moving workers and soldiers, subtle construction/impact effects. Strong contrast between terrain, player units, enemies, and selection. Prioritize actual game clarity and thoughtful visual design over a generic UI. Programmatic vector/procedural graphics are acceptable when cohesive and sufficiently detailed; no need to wait for paid assets. Give the town visual life. No gore or ethnic morality/skin-color coding.

## Complete first release scope

Deliver a title/menu screen, a guided River Settlement scenario, and a free-build or skirmish mode using the same genuine mechanics. The scenario should support roughly 20–35 minutes of normal play, adjustable speed, pause, and an optional shorter test mode visibly labeled. This is a target to tune, not a claim of measured runtime. Provide difficulty choices affecting enemy pressure and clear objectives, victory/defeat, restart, save, and load. Do not fake additional campaign chapters with nonfunctional buttons.

Start with a settlement hall, a small group of workers, and a scout on a readable river map. There are trees, stone deposits, cultivable land, a ford/crossing, a neighboring settlement location, and an enemy camp. Explore fog-of-war; preserve explored terrain while concealing unseen moving threats. Terrain and buildings affect navigation.

Resources: food, timber, stone. Show current amounts, income/consumption or a comprehensible explanation, population/housing, idle workers, current age, and objective. Workers actually move, gather, carry to storage, construct, and repair. Resource deduction must correspond to authorized actions; blocked or canceled placement must not silently consume resources. Queue construction visibly. Explain why actions are unavailable. Ensure recovery from early shortages.

Building families: hall, home, storehouse, farm, timber camp, quarry, workshop, training ground, watchtower; also placeable palisades and gates. Make placement and access clear. Roads are optional if they improve strategy. At least two stages, Settlement and Village, with distinct visual and mechanical changes. Add Town only if the complete loop is already sound; do not sacrifice finish or verification for breadth.

Research includes improved tools, food storage, ranged training, and advancement. At least two upgrades unlock a usable capability, not just a stat percentage. Show prerequisites and upcoming unlocks. Players choose between economic investment and defense; avoid mandatory dead time. Building and troop upgrades have visible feedback. Ordinary progress is earned through resources, development, and objectives, not locked behind narrative choices.

Unit roles: worker, scout, melee defender, ranged defender, and corresponding enemy combatants. Click and drag selection, group orders, right-click contextual orders, attack, move, gather/build/repair, hold, stop, and retreat must be practical. Include keyboard shortcuts, selection panel, concise help, and an idle-worker command. Movement must handle gates, newly placed buildings, and crowded areas without recurring stuck units. Combat needs real range, cooldowns, health, targeting, readable damage, and actual outcomes. No arbitrary automatic victory.

Enemy behavior should prepare and execute an attack from an actual camp/approach. Initial deterministic scenario behavior is acceptable, but use genuine units moving and fighting. Warn beginners and allow preparation. Easy mode remains forgiving; normal demands planning. Units/structures can take damage; workers can repair after battle. Victory should require defending the hall and viable settlement through the scenario threat. Defeat/recovery must be communicated. Sandbox remains playable after the scenario.

## Leadership and guidance

One civic event asks for help from a neighboring community. Give meaningful feasible choices: provide supplies now, promise a smaller delivery and fulfill it, or decline. Account for genuine shortage; do not treat clicking a donation repeatedly as virtue. Record commitments and completion. Public trust/receptiveness change based on actions with clear narrative feedback, not an exposed morality score. A repair/reconciliation path should exist.

An authored impression or dream from the ruler can warn about an actual upcoming threat, such as the northern crossing. Receptive leadership yields earlier or clearer guidance; other leadership states may yield a less specific concern or no warning. Scouts can discover the same threat. The scenario determines the threat independently, before the warning; do not punish ignoring a dream by spawning a larger force. Player action—scouting, fortifying, stockpiling, repositioning—creates the tactical benefit. Guidance is not a spendable mana meter or guaranteed win button.

Use one or two short atmospheric moments and a journal, not constant interruptions. Pause or present safely during noncombat; preserve player control. Keep dream dialogue clearly fictional. No live AI generation. The guidance system is a fictional design built around intuition, fairness, preparation, and trust; battle outcomes depend on strategy and the simulation.

## Audio and comfort

Include locally generated or licensed subtle game sound for selection, building, completion, combat, and alerts; user-controlled mute/volume, audio unlocked by interaction. Music optional. Readable fonts, reduced-motion option, pause and speed buttons, no flashing effects. Prevent accidental browser context menus from interfering with commands. Confirm resize handling and pointer mapping.

## Architecture and persistence

Separate simulation/state, input commands, rendering, UI, scenario/event rules, and data definitions. Use stable entity IDs, a fixed simulation step and seeded randomness where appropriate. Keep balance values discoverable. Save all state needed to resume: resources, units, structures/queues, research, explored terrain, threat preparation/timers/seed, leadership commitments, journal, scenario progress. Version save schema, handle malformed/old saves safely, and do not duplicate rewards or reroll attacks on reload. Support user export/import if practical. Do not let debug tools alter normal saves silently.

## Five acceptance tests

1. ECONOMY: In a fresh normal game, a worker gathers a real resource, deposits it, and constructs a building that consumes the stated cost. Placement cancellation, insufficient funds, and occupied terrain behave correctly.
2. PROGRESSION: Earn and spend resources to advance or research, then use a newly unlocked troop/building/capability. UI and simulation agree; the improvement has a visible effect.
3. COMBAT: Scout an approach, command multiple defenders, observe a genuine enemy raid, resolve a win or loss through simulation, and repair surviving structures. Document route, gate, targeting, and crowding behavior.
4. GUIDANCE: Under the same scenario seed/threat, distinct leadership histories change warning clarity/timing without changing the underlying enemy force. Guidance journal works and independent scouting is viable. Show the tested states.
5. PERSISTENCE: Save during active play, close/reload a fresh page, and continue with matching economy, units, research, leadership and pending threat state. Test through the real UI, not only in-memory serializers.

Automate meaningful invariants and browser interactions where appropriate; also inspect screenshots and play the rendered game. Check no runtime errors, controls work at target sizes, and sound assets exist. Test the build command and production preview, not just dev server. Run a provisional 100-unit stress scene separately and report measured behavior/hardware rather than invent a universal performance promise. Keep debug mode explicitly labeled and separate from earned progression evidence.

## Completion and evidence

Deliver functioning source, dependency lockfile, clear README run instructions, docs/VERIFICATION.md with passed/failed/untested checks and evidence, docs/KNOWN-LIMITATIONS.md, and screenshots under evidence/ where feasible. Preserve actual errors and repairs in logs; never manufacture failures or test results. Do not claim commercial readiness, multiplayer, historical accuracy, human playtesting, or features not implemented.

Treat satisfying economy/progression, responsive combat, a readable original world, and robust save/load as core. Complete and polish the coherent scenario before optional breadth. Continue your autonomous implementation and repair loop until these completion conditions are met or a genuine external blocker remains. Leave a local playable server and a concise honest final report with the local URL, run instructions, test results, and known limitations.