# Framework-Free HTML Game Production Line

**Version:** 0.1  
**Scope:** Small, original browser games made without frameworks or build tools  
**Quality standard:** `PLAYABLE_PROTOTYPE_STANDARD.md`

## 1. What this production line makes

This production line creates small games that:

- Run directly in a modern browser.
- Use standard HTML, CSS, and JavaScript.
- Require no framework, game engine, package manager, or compilation step.
- Can be opened locally or served by a basic static server.
- Are understandable within approximately 20 seconds.
- Provide a complete playable arc in 30 seconds to 3 minutes.
- Have a distinct mechanic, emotional target, and visual identity.
- Include automated validation and a human learning record.

This line is intended for rapid exploration of play, not for producing reskinned templates.

## 2. Default output contract

Every generated game must use this structure:

```text
game-name/
├── index.html
├── style.css
├── game.js
├── genome.json
└── README.md
```

Optional files are allowed only when the game genuinely needs them:

```text
game-name/
├── assets/
│   ├── images/
│   └── audio/
└── LEARNING.md
```

Do not create a package manifest, dependency directory, bundler configuration, or framework project unless the user explicitly requests one.

## 3. Technical palette

Use the browser platform as the engine.

### Rendering

Choose the smallest appropriate surface:

- Canvas 2D for movement, particles, grids, collisions, and custom drawing.
- HTML and CSS for menus, instructions, HUDs, cards, buttons, and text-heavy games.
- DOM elements for accessible turn-based, card, word, or interface-driven games.
- WebGL only when the concept cannot be expressed adequately with Canvas 2D.

Avoid SVG-authored game scenes unless vector structure is essential to the mechanic.

### Input

Support the input methods appropriate to the game:

- Keyboard.
- Pointer or mouse.
- Touch.
- Gamepad only when explicitly required.

Primary play must not depend on hover.

### Audio

Prefer Web Audio for small procedural effects:

- Hits.
- Confirmation tones.
- Escalating chains.
- Danger signals.
- Short generative ambience.

Audio must begin only after a user gesture. Include a visible sound toggle.

### Persistence

Use `localStorage` only for device-local information such as:

- Best score.
- Best combo.
- Attempts played.
- Last result.
- Sound preference.

The game must remain playable when persistence is unavailable.

### Timing

Use `requestAnimationFrame` for continuous games. Calculate movement using delta time and cap unusually large frame gaps.

Turn-based games do not need a permanent animation loop unless visual effects require one.

## 4. Inputs to the line

A request may provide any of the following:

- Intended emotion.
- One or more verbs.
- Historical ancestor or technology.
- Visual direction.
- Session duration.
- Audience.
- Input constraint.
- Accessibility constraint.
- Theme or fantasy.

When information is missing, choose it deliberately rather than generating a generic arcade game.

Minimum internal brief:

```yaml
primary_emotion: wonder
secondary_emotion: cleverness
excluded_emotion: power
primary_verb: ignite
supporting_verbs:
  - observe
  - place
session_seconds: 90
input: pointer
technical_constraint: canvas-2d
visual_direction: editorial-cosmic
```

## 5. Production stages

### Stage 1: Distill the game

Write the one-sentence identity:

> You are **[role]** and must **[verb]** to **[objective]** while **[pressure]**.

Define:

- Primary and secondary emotion.
- Excluded emotion.
- One to four verbs.
- Primary decision.
- Success condition.
- Failure or ending condition.
- Target session duration.

Reject the concept if its identity depends mainly on theme, lore, upgrades, or references to another game.

### Stage 2: Create the genome

Write `genome.json` before implementing the complete game.

The genome is the design contract. It must state:

- Identity.
- Emotions.
- Verbs.
- Ancestry.
- Spatial and temporal rules.
- Pressures.
- Feedback.
- Fairness choices.
- Ethical boundaries.
- Evaluation dimensions.

### Stage 3: Build the toy

Implement only:

- The primary input.
- The primary state change.
- Immediate feedback.
- Enough world behavior to make the action meaningful.

The toy should become interactive as quickly as possible.

Exit test:

> Is the primary action interesting for 20 seconds without score, progression, or narrative?

If not, change the action or rule. Do not hide the problem with effects or content.

### Stage 4: Build the minimum game

Add:

- Opening explanation.
- Start action.
- Goal.
- Pressure or limitation.
- Escalation.
- Outcome screen.
- Immediate restart.

Do not add settings panels, accounts, shops, unlock trees, or multi-page navigation.

### Stage 5: Add feel and legibility

Tune:

- Input latency.
- Movement curves.
- Collision response.
- Timing windows.
- Color hierarchy.
- Sound hierarchy.
- Particles and impact.
- Danger telegraphs.
- Score and objective readability.

Every effect must either communicate state or strengthen the intended emotion.

### Stage 6: Add controlled variation

Create variation through rules and systems before adding content.

Preferred sources:

- Different starting arrangements.
- Changing spatial relationships.
- Speed or density curves.
- Limited resources.
- Alternative tactical opportunities.
- Deterministic seeded layouts.

Avoid uncontrolled randomness that makes outcomes impossible to explain.

### Stage 7: Add local instrumentation

Record only the information needed to evaluate the hypothesis:

- Attempts.
- Completion.
- Duration.
- Primary actions.
- Successes and mistakes.
- Best chain or combo.
- Furthest stage.
- Restarts.

No network telemetry is part of this production line.

### Stage 8: Add validation mode

Every game must recognize:

```text
?test=1
```

Validation mode should shorten the normal arc so an agent can verify:

- Start.
- Active play.
- Outcome.
- Restart.

It must not replace normal play or expose testing controls in the regular interface.

### Stage 9: Validate

Perform all of the following:

1. Check JavaScript syntax.
2. Check that `genome.json` parses.
3. Serve or open the game locally.
4. Inspect the opening screen.
5. Start a game.
6. Trigger the primary action.
7. Test pause and resume when present.
8. Reach an outcome using validation mode.
9. Restart.
10. Inspect runtime errors.
11. Review the active-play screen visually.

Do not declare completion based only on static code inspection.

### Stage 10: Human play and learning

Ask the evaluator:

1. Did you understand what to do?
2. Which moment felt best?
3. What felt confusing, weak, or unfair?
4. Did you want to try again?
5. What would you do differently next time?

Create `LEARNING.md` after meaningful human feedback is available.

## 6. Required interface states

Every game must contain these states, even if their visual presentation differs:

### Ready

- Name and identity.
- Goal.
- Controls.
- Start action.

### Playing

- Playfield.
- Current objective or progress.
- Essential resource or time information.
- Legible response to the primary action.

### Paused

- Clearly indicates that simulation has stopped.
- Returns to play using a simple action.

Pause may be omitted from very short turn-based games when it has no meaning.

### Outcome

- Clear closure.
- Relevant performance information.
- One useful observation or hint.
- Immediate replay action.

## 7. Default accessibility requirements

- Support keyboard and touch when compatible with the mechanic.
- Do not communicate essential state through color alone.
- Maintain readable contrast.
- Provide accessible names for interactive HTML controls.
- Prevent browser scrolling from hijacking gameplay keys.
- Pause when the window loses focus, except in validation mode.
- Make text readable at narrow mobile widths.
- Respect reduced motion when extreme movement is not mechanically necessary.
- Never require sound to understand a rule.

## 8. Visual identity rules

Each game must receive a deliberate visual system containing:

- One dominant background treatment.
- One primary type treatment.
- Two to five functional colors.
- A consistent shape language.
- A clear hierarchy between playfield, HUD, and overlays.

Do not use the same visual system for consecutive games.

Possible directions include:

- Dark luminous instrument.
- Printed editorial diagram.
- Soft tactile toy.
- Monochrome terminal.
- Hand-drawn notebook.
- Geometric broadcast graphic.
- Minimal scientific interface.

Visual identity must support the intended emotion rather than merely decorate the game.

## 9. Difference gate

Before implementation, compare the concept against the previous three games.

The new game must differ in at least three of these dimensions:

- Primary verb.
- Primary emotion.
- Decision structure.
- Spatial topology.
- Input rhythm.
- Session structure.
- Visual language.
- Feedback style.

If it does not pass this gate, mutate the concept before building it.

## 10. Complexity limits

Default limits for the first complete version:

- One HTML page.
- One primary playfield.
- One to four verbs.
- One core resource or timer.
- One scoring model.
- One to three stages.
- One outcome screen.
- No external runtime dependencies.
- No backend.
- No login.
- No remote database.
- No monetization.

Exceed a limit only when the play hypothesis requires it.

## 11. Definition of done

A game exits the production line only when:

- It runs from its folder without a build step.
- Its opening state explains the experience.
- Its primary action works with appropriate input methods.
- It contains a complete short arc.
- It has clear feedback, outcome, and restart.
- It differs meaningfully from recent games.
- `genome.json` matches the implementation.
- `README.md` explains execution and controls.
- Validation mode reaches an outcome quickly.
- Syntax and runtime checks pass.
- The active game has been inspected visually.
- At least one human has played it.
- It complies with `PLAYABLE_PROTOTYPE_STANDARD.md`.

## 12. Invocation contract

The future skill should trigger on requests such as:

- “Make another Play Lab game.”
- “Create a small original HTML game.”
- “Generate a framework-free browser game.”
- “Make a one-minute game about curiosity.”
- “Create a game using the Playable Prototype Standard.”
- “Build the next game in the production line.”

Suggested skill name:

```text
make-html-game
```

Suggested invocation:

```text
Use $make-html-game to create a new framework-free browser game.
Primary emotion: curiosity.
Avoid reflex-based play.
Target session: 90 seconds.
```

## 13. Relationship to other tools

This production line does not require:

- Unity.
- Godot.
- Unreal Engine.
- Blender.
- An MCP server.
- A framework.
- A specialized Hermes profile.

Codex or Hermes only needs:

- File creation and editing.
- A local static server or direct file access.
- Browser interaction for validation.
- The `make-html-game` production skill.

Engine MCPs may form separate production lines later. They should not complicate this one.

---

The production line is successful when it produces distinct, playable experiments quickly and turns every human reaction into better instructions for the next game.