Session artifact · final

Product Requirements Document

The behavioural contract for the production, crafting, combat, quest and evaluation loops of the proof of concept.

Document
TestGame Production-Chain Strategy PoC
Created
1 August 2026
Updated
1 August 2026

0. Document Purpose

This PRD defines a solo hobby and learning proof of concept (PoC) built in Unity for Windows. It turns the product brief and brainstorming record into a stable behavioral contract for later UX, architecture, and implementation work. The PoC is an experiment, not a vertical slice or commercial game. Technical mechanisms and tuning details are preserved separately in addendum.md.

1. Vision

Test whether a deliberately small, production-chain-first fantasy strategy game is compelling and enjoyable enough to justify further experimentation. The core thesis is that understandable production chains can make combat and quest decisions more meaningful when their outputs produce immediate, visible tactical effects.

Production is the implementation spine. Combat proves whether crafted outputs matter. Quests expose the different payoffs of immediate aggression and longer-term investment without forcing a mutually exclusive choice in the Baseline PoC. The experience should move through comprehension, anticipation, agency, and payoff without becoming a logistics simulation.

The PoC is successful when Tim can play the complete loop, understand its causes and effects, enjoy making its core choices, and remain motivated to iterate. A successful PoC may inform a separate shippable-game project, but that project will live in another directory and treat this repository as a learning resource.

2. Target User

2.1 Jobs To Be Done

  • As the creator, learn how designing and implementing a game feels through a bounded, playable experiment.
  • Try production, combat, and quest ideas quickly and learn which succeed or fail.
  • As the player, prepare for tactical challenges through readable production choices rather than deep logistics management.
  • See what was made, why it matters, and how it changes combat or quest outcomes.
  • Choose between immediate military progress and investment in stronger later capabilities.

2.2 Non-Users

  • Players seeking a polished, content-rich, balanced, or commercially complete strategy game.
  • Players seeking worker simulation, transport logistics, automation, or large production networks.
  • External playtesters; Tim is the only planned tester for this PoC.

2.3 Key User Journey

  • UJ-1. Tim prepares, fights, and decides whether another loop is worthwhile. Tim opens the Windows build, moves the camera with WASD and the mouse, and places Resource Buildings, Processing Buildings, and Crafting Buildings. He watches Resources enter Mythical Storage, inspects a Recipe, and starts a timed Crafting job. Visible progress creates anticipation; completion moves the Crafted Good into Inventory. Tim equips or uses the Crafted Good, then sees its tactical effect during Combat or a Quest. He chooses whether to invest in further Production or pursue immediate military progress. The journey resolves when he can explain the effect of his preparation and decide whether he wants another loop.

3. Glossary

  • PoC — The complete but bare-bones learning product defined by this PRD.
  • Baseline PoC — The first complete implementation of every in-scope capability, before any extension milestone.
  • Resource — A raw or processed production input held in Mythical Storage; never placed in Inventory.
  • Mythical Storage — The shared global Resource pool to which Buildings push and from which Buildings pull instantaneously.
  • Resource Building — A Building that passively generates a Resource.
  • Processing Building — A Building that converts Resources into other Resources.
  • Crafting Building — A Building where the player selects a Recipe and starts a Craft.
  • Recipe — The required Resource inputs and resulting Crafted Good for a Craft.
  • Craft — A timed production job that commits Resources and creates a Crafted Good.
  • Crafted Good — An item produced by a Craft and stored in Inventory, including equipment and the Morale Flag.
  • Inventory — A ten-slot container that holds only Crafted Goods.
  • Hero — A player-controlled melee or spellcasting combat character.
  • Soldier — A regular player-controlled combat unit.
  • Monster — A hostile combat unit that may drop a Skill Scroll.
  • Skill Scroll — Monster loot that teaches an equippable Hero Skill.
  • Hero Skill — An ability learned from a Skill Scroll and equipped by a Hero.
  • Morale Flag — A temporary Crafted Good deployed near Soldiers to provide a visible positive area effect before disappearing.
  • Quest — A simple objective that demonstrates either aggressive or production-focused play.
  • Extension Milestone — New experimental scope considered only after the Baseline PoC is completed and evaluated.

4. Features and Functional Requirements

4.1 Windows Play Surface and Camera

Description: The player can run the PoC on Windows and inspect the strategy play space using keyboard and mouse controls. Realizes UJ-1.

FR-1: Run the PoC on Windows

The player can launch and play a Windows desktop build.

Consequences:

  • The Baseline PoC does not require another operating system or device form factor.

FR-2: Navigate the play space

The player can move the camera with WASD in combination with mouse input.

Consequences:

  • Camera movement is sufficient to inspect, place, and select relevant entities.
  • WASD or moving the pointer to a screen edge pans the camera.
  • Q, E, or holding the right mouse button while moving the mouse rotates the camera.
  • The mouse wheel zooms the camera through a deliberately small range; exact limits are deferred to implementation testing.

4.2 Buildings, Resources, and Mythical Storage

Description: The player places simple Buildings that generate, process, or consume Resources through Mythical Storage. Transfer is intentionally instantaneous and global so the experiment focuses on production decisions rather than logistics. Realizes UJ-1.

FR-3: Place Buildings

The player can place the Resource Buildings, Processing Buildings, and Crafting Buildings required by all Baseline PoC Recipes.

Consequences:

  • Placement visibly succeeds or fails.
  • A placed Building displays its name and operational role.

FR-4: Generate Resources passively

Resource Buildings can add their configured Resources to Mythical Storage over time.

Consequences:

  • Active generation is visibly indicated.
  • The player can inspect current Resource quantities in a shared overview.
  • Each Resource Building adds one unit of its Resource to Mythical Storage every ten seconds.

FR-5: Process Resources

Processing Buildings can pull required Resources from Mythical Storage and push their resulting Resources back into Mythical Storage.

Consequences:

  • Processing never requires workers, warehouses, or transport routes.
  • Missing inputs prevent processing without creating negative Resource quantities.
  • The player starts a processing job with a button in the Processing Building interface.
  • Each Processing Building runs at most one processing job at a time; separate Processing Buildings may run concurrently.
  • A processing job commits its input Resources when it starts and produces its configured output after 30 seconds.
  • The player can cancel a processing job with its cancel button and receive a full Resource refund.
  • Processing orders, queues, and automation are deferred beyond the Baseline PoC.

4.3 Crafting and Inventory

Description: Crafting Buildings expose readable Recipes, consume Resources from Mythical Storage, show timed progress, and deliver Crafted Goods to Inventory. Realizes UJ-1.

FR-6: Inspect Recipes

The player can inspect each Recipe’s required Resources, available quantities, resulting Crafted Good, and craft availability.

Consequences:

  • A missing requirement is distinguishable from an available requirement.
  • A Craft action that cannot start does nothing and communicates insufficient Resources.
  • Each Recipe costs one unit of every Resource listed as its input.

FR-7: Perform a timed Craft

The player can start a Craft when all required Resources and an Inventory destination are available.

Consequences:

  • Required Resources are committed when the Craft starts.
  • Every processing job and Craft takes 30 seconds; progress from start to completion is visible.
  • Each Crafting Building can run at most one Craft at a time; separate Crafting Buildings may Craft concurrently.
  • The player can interrupt a Craft with its cancel button, which returns all committed Resources to Mythical Storage.
  • Completion produces exactly the configured Crafted Good and provides visible feedback.

FR-8: Store Crafted Goods

Inventory can hold up to ten Crafted Goods and never holds Resources.

Consequences:

  • A completed Crafted Good appears in Inventory.
  • A Craft reserves a destination Inventory slot when it starts and cannot start when no slot can receive its output.

FR-9: Support the sword chain

The player can produce an iron sword by processing iron ore into iron ingots and then a steel blade, processing trees into planks and then a hilt, and finally assembling the blade and hilt.

Consequences:

  • The chain includes multiple Resource dependencies and at least one final Craft.
  • The completed sword can be equipped by any melee unit and increases that unit’s base hit points by 5%.

FR-10: Support the armor chain

The player can process thatch into rope, combine the rope with leather to craft tier-one leather armor, and combine that armor with iron ingots to craft tier-two metal armor.

Consequences:

  • Deer hunting supplies leather.
  • A Resource Building supplies thatch, and a Processing Building converts the thatch into rope.
  • Tier-two metal armor consumes tier-one leather armor, demonstrating continued usefulness of an earlier Crafted Good.
  • Equipping tier-two metal armor visibly improves a Soldier’s survivability by increasing base hit points by 10%.

FR-11: Support the Morale Flag

The player can craft a Morale Flag from leather and one plank and deploy it near Soldiers.

Consequences:

  • The deployed Morale Flag shows its area of effect and remaining duration.
  • The Morale Flag affects Soldiers within a 10-meter radius, increasing base hit points by 5%.
  • Multiple Morale Flags do not stack their effects.
  • The Morale Flag remains active for ten seconds, then disappears and returns no materials.

4.4 Combat, Heroes, and Skills

Description: A small fantasy Combat sandbox provides proof surfaces for production outputs, with two distinct Heroes, Soldiers, Monsters, and loot-based Hero Skills.

FR-12: Resolve basic Combat

The player can command combat-capable units to fight Monsters until one side is defeated.

Consequences:

  • The sandbox includes a melee Hero, a spellcasting Hero, Soldiers, and Monsters.
  • The player can inspect current and maximum hit points for relevant combat units.
  • Combat displays damage-event values and active status effects so the player can compare baseline and modified outcomes.
  • Deep Combat statistics and production-grade balance are not required.

FR-13: Equip and observe Crafted Goods

The player can equip eligible Crafted Goods on Heroes or Soldiers, or deploy them in the play space, and observe their effects.

Consequences:

  • Equipment state is inspectable.
  • Before-and-after maximum hit points make the effects of a sword, tier-two metal armor, and Morale Flag observable during Combat.

FR-14: Learn and equip Hero Skills

Monsters can drop Skill Scrolls that teach Hero Skills, and eligible Heroes can equip learned Hero Skills.

Consequences:

  • The player can distinguish a dropped, learned, and equipped Hero Skill.
  • The PoC includes two Skill Scrolls and two equipable Hero Skills: Slash for the melee Hero and Fireball for the spellcasting Hero.
  • Slash deals 5% more than the melee Hero’s base damage; Fireball deals 5% more than the spellcasting Hero’s base damage.

4.5 Quests and Strategic Choice

Description: Two simple Quests demonstrate contrasting immediate-aggression and Production-investment paths without requiring a broad narrative, content system, or forced tradeoff.

FR-15: Complete the aggressive Quest

The player can accept and complete a Quest whose objective is to kill a configured number of Monsters.

Consequences:

  • The Quest requires ten Monster kills, and progress toward that number is visible.
  • Completion displays a text popup confirming that the player finished the Quest; no additional reward is required for the Baseline PoC.

FR-16: Complete the production-focused Quest

The player can accept and complete a Quest whose objective is to craft one tier-two metal armor.

Consequences:

  • Quest progress updates when the player completes the tier-two metal armor Craft.
  • Completion displays a text popup confirming that the player finished the Quest; no additional reward is required for the Baseline PoC.

FR-17: Compare immediate and delayed payoff

The PoC allows the player to compare immediately pursuing the Monster-kill Quest with existing combat units against investing in Production and stronger later equipment.

Consequences:

  • The Baseline PoC does not require a forcing function, deadline, terminal condition, or mutually exclusive path.
  • Quest objectives represent and validate their associated path; material rewards are not required for the Baseline PoC.
  • Tim can compare immediate and delayed tactical payoff during solo testing.

4.6 Baseline Evaluation and Extension Milestones

Description: The PoC remains a bounded experiment even though later learning milestones may be added.

FR-18: Evaluate the Baseline PoC before extension

Tim can complete and evaluate every in-scope capability before adding an Extension Milestone.

Consequences:

  • Baseline evaluation records what worked, what failed, and whether another loop is desirable.
  • New features do not retroactively change Baseline PoC completion criteria.

FR-19: Define Extension Milestones independently

Each Extension Milestone must state its learning hypothesis, scope, success criteria, and relationship to the Baseline PoC before implementation begins.

Consequences:

  • Extension scope is distinguishable from Baseline PoC scope.
  • A possible commercial game remains a separate project and is never an Extension Milestone in this repository.

5. Cross-Cutting Quality Requirements

  • NFR-1 — Readability: Resource state, Recipe requirements, Craft progress, completion, Inventory state, equipment, Quest progress, and tactical effects must be understandable without inspecting Unity internals.
  • NFR-2 — Causal feedback: The player must be able to identify which Crafted Good or Hero Skill caused a visible tactical change.
  • NFR-3 — Functional stability: The Baseline PoC must support repeatable, end-to-end UJ-1 playthroughs without a known blocker or unrecoverable state.
  • NFR-4 — Iteration speed: Systems should favor data-driven tuning or similarly lightweight adjustment where practical, because creator viability is part of the experiment.
  • NFR-5 — Visual economy: Placeholder visuals are acceptable. Buildings may be cubes labeled with their names; clarity takes priority over art and animation.
  • NFR-6 — Local-only operation: The PoC requires no multiplayer, online service, account, or external telemetry service.

6. Non-Goals

  • A vertical slice, early-access build, or commercial-launch candidate.
  • Workers, warehouses, transport routes, or fuller logistics simulation.
  • Automation, large-scale throughput optimization, or complex production networks.
  • Profession ranks or gathering restrictions.
  • Magical armor production or enchantment systems.
  • Deep Combat statistics, extensive morale mechanics, or production-grade balance.
  • Broad Quest, enemy, item, building, or map content.
  • Polished 3D models, extensive animation, or final visual identity.
  • Multiplayer, accounts, online infrastructure, monetization, analytics services, or launch operations.
  • External playtesting during the Baseline PoC.
  • A mechanically enforced aggression-versus-Production tradeoff; this is a candidate Extension Milestone.

7. Baseline PoC Scope

7.1 In Scope

  • Windows desktop build and WASD-plus-mouse camera.
  • Placeable Resource, Processing, and Crafting Buildings.
  • Passive generation, processing, Mythical Storage, and Resource overview.
  • Readable Recipes, timed Crafting, cancellation with full refund, completion feedback, and ten-slot Inventory.
  • Sword, tier-one armor, tier-two armor, and Morale Flag chains.
  • Deer hunting as the source of leather.
  • Melee Hero, spellcasting Hero, Soldiers, Monsters, and observable Combat.
  • Two Monster-dropped Skill Scrolls and two equippable Hero Skills.
  • Aggressive kill-X-Monsters Quest and production-focused craft-tier-two-armor Quest.
  • A visible contrast between immediate aggression and longer-term Production investment.
  • Solo creator evaluation and an explicit continuation decision.

7.2 Out of Scope for the Baseline PoC

  • Everything listed in §6.
  • Any Extension Milestone not separately approved under FR-19.
  • Quantitative external-playtest thresholds, because Tim is the only tester.
  • Production-ready tuning, final art, extensive animation, and broad content are out of scope. Values in §4 are Baseline acceptance defaults and may be tuned when the change and reason are recorded.

8. Success Metrics and Decision Rule

The Baseline PoC may continue into Extension Milestones only when it is complete enough to evaluate; failed or mixed results remain valuable learning outcomes.

Primary:

  • SM-1 — Loop completion: Tim can complete UJ-1 end to end without a known blocker or needing to inspect or change runtime state through Unity internals. Validates FR-1–FR-17.
  • SM-2 — Payoff causality: After using the sword, tier-two metal armor, and Morale Flag, Tim can explain what each changed in Combat. Validates FR-9–FR-13.
  • SM-3 — Payoff comparison: Tim can describe how immediately pursuing the aggressive Quest differs from first investing in the production-focused Quest. The Baseline PoC does not need to make the paths mutually exclusive. Validates FR-15–FR-17.
  • SM-4 — Desire to continue: After a complete playthrough, Tim wants to play or build another loop and can name what he wants to learn next. Validates FR-18–FR-19.

Secondary:

  • SM-5 — Creator viability: Tim considers the implementation and tuning loop sustainable enough for at least one Extension Milestone.
  • SM-6 — System clarity: Resource quantities, Craft state, Inventory state, Quest progress, and tactical effects can be understood through the game surface.

Counter-metrics and failure signals:

  • SM-C1 — Scope growth: Baseline completion is not judged by feature count beyond §7.1; adding more content cannot compensate for an unclear core loop.
  • SM-C2 — Mandatory crafting: More time spent Crafting is not inherently better; Crafting that feels like a chore or generic upgrade path counts against the thesis.
  • SM-C3 — Premature balance claim: Completing one path faster does not establish a dominant strategy because the Baseline PoC does not yet enforce a strategic tradeoff.
  • SM-C4 — Technical completion without motivation: A functioning build is insufficient if Tim no longer wants to iterate.

9. Risks and Guardrails

  • Scope expansion: Every capability in the brief is included, creating integration risk. Guardrail: implement only the bare-bones behavior needed to prove each capability, then evaluate before extension.
  • Unclear tactical payoff: Crafted outputs may feel like invisible stat changes. Guardrail: make state and before/after effects visible.
  • Crafting as a chore: Waiting may not create anticipation. Guardrail: use Combat and Quests as meaningful concurrent or follow-up activity and tune durations through solo play.
  • Overstated strategic choice: The two paths may not compete in the Baseline PoC. Guardrail: evaluate their perceived immediate and delayed payoffs only; test a forcing function in a separate Extension Milestone.
  • Placeholder ambiguity: Cubes may obscure function. Guardrail: label Buildings and use readable state feedback.
  • Subjective validation: Solo testing cannot establish broad player appeal. Guardrail: conclusions apply only to creator learning and motivation, never market validation.