# Playable Prototype Standard

**Version:** 0.1  
**Status:** Working standard for game prototypes  
**Reference cases:** ORBITA 001 and CONSTELLATION 002

## 1. Purpose

This document defines what every game created by the Play Lab must satisfy, regardless of genre, technology, visual style, or audience.

The goal is not to produce a large number of interchangeable games. The goal is to create small experiences with a clear identity, a meaningful action, and an honest reason to play again.

Every prototype must work simultaneously as:

1. A game that is understandable and enjoyable on its own.
2. An experiment testing a specific play hypothesis.
3. A reusable piece of knowledge for future games.
4. Evidence for improving Hermes's game-generation process.

## 2. Guiding principle

> A small game should do only a few things, communicate them clearly, and make at least one of them feel excellent.

Content volume must never be used to hide a weak core. Before adding levels, narrative, progression, collectibles, or customization, the first minute must contain a satisfying decision or action.

## 3. Mandatory requirements

Every prototype must satisfy the following requirements before it can be considered complete.

### 3.1 An identity that fits in one sentence

The game must be explainable using this structure:

> You are **[fantasy or role]** and must **[primary verb]** to **[objective]** while **[pressure or constraint]**.

Examples:

- You are an orbital shield and must deflect a sphere to destroy fragments while protecting a core.
- You initiate a constellation and must place pulses to create chain reactions while managing a limited number of interventions.

If the sentence must explain currencies, statistics, skill trees, or several exceptions, the concept has not been distilled enough.

### 3.2 Emotional intent

Every game must declare:

- One primary emotion.
- One secondary emotion.
- One emotion or dynamic it deliberately avoids.

Available emotional engines include, but are not limited to:

- Mastery: I am improving.
- Curiosity: I want to discover what happens next.
- Resolution: I turned chaos into order.
- Tension: I nearly lost.
- Wonder: one action produced something unexpectedly beautiful.
- Cleverness: I found an elegant solution.
- Power: my actions feel forceful and consequential.
- Expression: this outcome reflects my choices.
- Connection: we experienced something together.

The first prototype should not attempt to combine more than three primary emotional engines.

### 3.3 Limited verbs

The first playable version must use between one and four primary verbs.

Examples include:

- Move.
- Jump.
- Deflect.
- Aim.
- Dodge.
- Place.
- Arrange.
- Combine.
- Build.
- Explore.
- Choose.
- Negotiate.
- Deceive.
- Cooperate.

Each verb must change the game state in a visible and meaningful way. An action that only plays an animation or increases a number does not count as a meaningful verb.

### 3.4 Rapid comprehension

A new player must understand the essentials in less than 20 seconds.

The opening screen must answer:

1. What am I, or what do I control?
2. What am I trying to accomplish?
3. How do I act?
4. What threatens or limits me?

Opening instructions should contain no more than approximately 45 words, excluding control labels.

### 3.5 A short, complete loop

The prototype must provide a complete arc in a session lasting between 30 seconds and 3 minutes:

1. Introduction.
2. First action.
3. Rising pressure or complexity.
4. Recognizable climax.
5. Outcome.
6. Immediate restart.

The player should not wait several minutes to reach the interesting part.

### 3.6 Real agency

The outcome must depend on observable decisions or skills.

The team must be able to answer:

- What distinguishes a strong attempt from a weak one?
- What can the player learn after failing?
- Is there more than one reasonable way to approach a situation?
- Can the player explain, at least partially, why they won or lost?

Randomness may create variety, but it must not determine success on its own.

### 3.7 Immediate response

Every primary action must produce perceptible feedback within 100 milliseconds whenever the platform allows it.

Feedback may combine:

- Movement.
- Shape or color changes.
- Sound.
- Particles.
- Brief impact pauses.
- Haptics.
- Environmental changes.
- Trajectory changes.
- Reactions from other entities.

Feedback must communicate information, not merely decorate the screen.

### 3.8 Legible and fair failure

When the player fails, the game must communicate:

- What happened.
- Which rule caused it.
- What the player could try differently.

The penalty must be proportional to the game's duration. Short prototypes should favor nearly instantaneous restarts.

Post-failure assistance—such as additional time, temporarily reduced speed, or a larger defensive area—is acceptable when it does not hide the rules.

### 3.9 Immediate restart

After the outcome, one obvious action must start another attempt.

Technical target: less than one second between selecting “try again” and regaining control.

Do not insert:

- Advertisements.
- Long mandatory animations.
- Unnecessary menus.
- Redundant confirmations.
- Rewards that must be opened individually.

### 3.10 A distinct audiovisual identity

Each game must differ from previous games in at least three of these dimensions:

- Primary mechanic.
- Temporal structure.
- Intended emotion.
- Visual language.
- Relationship with space.
- Input method.
- Sound design.
- Fantasy.

Changing colors, characters, or setting without changing the experience does not constitute a new game.

## 4. Ethical boundaries

The Play Lab optimizes for **the desire to return**, not compulsion.

### 4.1 Acceptable engagement

- Mastery and learning.
- Genuine curiosity.
- Personal expression.
- Systemic surprise.
- Fair competition.
- Cooperation.
- Clear goals.
- Meaningful variation.
- Progression that opens new possibilities.

### 4.2 Prohibited in prototypes

- Streaks that punish players for leaving.
- Artificial time scarcity.
- Monetized random reward boxes.
- Hidden probabilities that materially affect decisions.
- Difficulty manipulation intended to provoke purchases.
- Anxiety-driven notifications.
- Redundant currencies designed to obscure value.
- Punishment for attending to responsibilities outside the game.
- Dark patterns that make leaving difficult.

### 4.3 Ethical control question

Before approving a retention mechanic, answer:

> Does the player want to return because the game still contains something valuable to learn, discover, create, or share, or because they fear losing something artificial?

Only the first reason is acceptable.

## 5. Required game genome

Every game must include a `genome.json` file separate from its implementation.

Minimum template:

```json
{
  "id": "game-name-003",
  "title": "GAME NAME",
  "version": 1,
  "identity": {
    "fantasy": "Description of the player fantasy",
    "primary_emotion": "mastery",
    "secondary_emotion": "tension",
    "excluded_emotion": "collection",
    "target_session_seconds": 90
  },
  "verbs": ["move", "deflect", "aim"],
  "ancestry": ["technical reference 1", "technical reference 2"],
  "world": {
    "topology": "spatial description",
    "time": "continuous",
    "information": "complete",
    "physics": "primary rules"
  },
  "pressure": ["constraint 1", "constraint 2"],
  "feedback": ["response 1", "response 2"],
  "fairness": {
    "instant_restart": true,
    "random_failure": false
  },
  "ethics": {
    "monetization": false,
    "streak_pressure": false,
    "artificial_scarcity": false,
    "variable_ratio_rewards": false
  },
  "evaluation": ["clarity", "agency", "feel", "fairness", "retry_intent"]
}
```

The genome must describe what the game actually implements. It is not an aspirational design document.

## 6. Minimum deliverables

Every prototype must contain:

```text
game-name/
├── README.md
├── genome.json
├── game code and assets
└── tests or a validation mode
```

The `README.md` must document:

- Play hypothesis.
- How to run the game.
- Controls.
- Expected session length.
- Success condition.
- Failure condition.
- Locally recorded data.
- Known limitations.

## 7. Minimum instrumentation

Telemetry must remain local during prototyping unless external collection is explicitly authorized.

Record when relevant:

- Attempts started.
- Attempts completed.
- Restarts.
- Session duration.
- Primary actions.
- Successes and mistakes.
- Best combo or sequence.
- Furthest level or stage.
- Time until first action.
- Abandonment before the outcome.

Do not record:

- Personal identity.
- External browsing or activity history.
- Keystrokes unrelated to the game.
- Information unnecessary for evaluating the hypothesis.

Telemetry describes behavior; it does not prove enjoyment.

## 8. Automated validation

Hermes must be able to verify at least the following:

1. The game loads without errors.
2. The opening screen appears.
3. The start control works.
4. The primary action changes the game state.
5. Pause and resume work, when present.
6. The game can reach an outcome screen.
7. Restart begins a clean attempt.
8. The browser or runtime reports no errors.
9. `genome.json` is valid.
10. The application requests no undeclared permissions, accounts, or connections.

Web games must provide a short validation mode, for example:

```text
?test=1
```

This mode may shorten a round or activate reproducible conditions, but it must not alter normal play.

## 9. Human evaluation

After playing three to five attempts, each evaluator should answer:

1. Did you understand what to do without additional help?
2. Which action or moment felt best?
3. What caused tension, surprise, pleasure, or frustration?
4. Did you understand why you won or lost?
5. Did you immediately want to try again?
6. If you retried, what did you attempt to do differently?
7. What would you remove?
8. How would you describe the game in one sentence?

Question 6 is especially important. If a player restarts without a new intention, the game may be producing compulsion or inertia rather than interesting learning.

## 10. Evaluation scorecard

Score each dimension from 0 to 5:

| Dimension | Evaluation question |
|---|---|
| Clarity | Is it immediately apparent what to do? |
| Agency | Do player decisions materially change the outcome? |
| Response | Do actions feel immediate and legible? |
| Mastery | Is there something meaningful to learn or improve? |
| Depth | Do simple rules create varied situations? |
| Fairness | Do outcomes feel explainable and consistent? |
| Pacing | Does the session have a beginning, escalation, climax, and ending? |
| Identity | Is the game memorable as something distinct? |
| Surprise | Does it produce interesting consequences that are not entirely obvious? |
| Retry intent | Does the outcome generate a new hypothesis for the next attempt? |

### Approval threshold

A prototype may be approved when:

- No critical dimension—clarity, agency, response, or fairness—scores below 3.
- Its overall average is at least 3.5.
- Identity scores at least 3.
- At least half of evaluators want to play another attempt.
- Returning players can explain what they intend to change.
- No technical defect prevents completion of the loop.
- It complies with every ethical boundary.

A high numerical score does not replace qualitative observations.

## 11. Construction order

Hermes must build in this order.

### Phase 1: Hypothesis

Define the emotion, verbs, pressure, and one-sentence identity.

### Phase 2: Toy

Implement only the primary action and its response. Do not add menus, levels, or progression yet.

Exit question: Is the action interesting for 20 seconds?

### Phase 3: Minimum game

Add an objective, failure, a short arc, and restart.

Exit question: Can someone complete a session and learn something from the outcome?

### Phase 4: Legibility and feel

Tune controls, animation, sound, color, camera, pacing, and danger signals.

Exit question: Is the game understandable and satisfying without verbal explanation?

### Phase 5: Variation

Add only enough variation to keep several attempts from being identical.

Exit question: Does the variation create new decisions or merely more content?

### Phase 6: Validation

Run automated validation and human evaluation.

### Phase 7: Distillation

Record:

- What worked.
- What failed.
- Which parameter changed the result.
- Which module can be reused.
- What Hermes should avoid in the next game.

## 12. Iteration rules

1. Change one important variable per experiment whenever possible.
2. Do not add a mechanic to solve a clarity problem.
3. Do not add progression to solve a monotonous core.
4. Do not add effects to hide a lack of agency.
5. Do not increase difficulty to manufacture depth.
6. Remove before expanding.
7. Preserve playable versions for comparison instead of keeping only the latest version.
8. Document why every significant change was accepted or rejected.

## 13. Difference test between games

Before starting a new prototype, compare it with the previous three.

The new concept must change at least:

- The primary verb, and
- The primary emotion, or
- The decision structure.

Example of a valid contrast:

| Game | Central verb | Emotional intent | Primary decision |
|---|---|---|---|
| ORBITA | Deflect | Mastery and tension | Where to position a moving shield |
| CONSTELLATION | Ignite | Wonder and cleverness | Where and when to begin a reaction |

A concept cannot be approved when it is merely “ORBITA with a different appearance” or “CONSTELLATION with different colors.”

## 14. Antipatterns

Stop and simplify development when any of these signals appear:

- The tutorial is longer than the game.
- There are more systems than decisions.
- The player watches numbers instead of the world state.
- The primary reward happens outside active play.
- The first interesting action takes longer than one minute to reach.
- Winning depends on information that was never communicated.
- Every problem is solved by adding another currency, upgrade, or menu.
- The concept is described mainly through references to other games.
- Effects feel satisfying, but decisions do not matter.
- The only reason to repeat is an external reward.

## 15. Definition of done

A prototype is complete when:

- It can be opened and played without assistance from its creator.
- It communicates its objective and controls.
- It contains a complete loop.
- Its primary action feels deliberate.
- Success, failure, or closure is clearly legible.
- It restarts immediately.
- It has passed automated validation.
- It has been played by at least one person who did not implement it.
- Its `README.md` and `genome.json` are current.
- It records concrete lessons.
- It contains no mechanic that violates the ethical boundaries.

“Complete” does not mean large or perfect. It means the hypothesis can be evaluated honestly.

## 16. Future contract for Hermes

When this standard becomes a skill, Hermes must:

1. Read this document before designing a game.
2. Propose the genome before implementation.
3. Compare the concept with previous prototypes.
4. Build the toy before the minimum game.
5. Test the result visually and interactively.
6. Adjust parameters using evidence rather than intuition alone.
7. Deliver the game ready to open and play.
8. Request human evaluation using the eight defined questions.
9. Incorporate lessons without turning one person's preference into a universal rule.

## 17. Per-game learning record

After every prototype, add a file or entry using this structure:

```markdown
# Learning Record — GAME NAME

## Hypothesis
What we believed would create enjoyment.

## Observed result
What actually happened during play.

## Strongest moment
The most satisfying action, decision, or consequence.

## Weakest moment
Confusion, waiting, frustration, or monotony.

## Decisive change
The parameter or rule whose modification improved or harmed the experience.

## Reusable pattern
A mechanic, architecture, signal, or tool worth preserving.

## Warning
What Hermes should not repeat without reconsideration.

## Next question
The experiment that should follow.
```

---

This standard must evolve from observed games rather than isolated theory. Every rule may be revised, but each revision must identify the evidence that motivated it.