Browser RPG Arena

# Browser RPG Arena

Build a small browser RPG game that can be opened and judged in a browser. The submitted solution must include a self-contained static browser build even if you use Vite, TypeScript, or another development server while implementing it.

## Critical: Solution Root

- Put every implementation file and dependency manifest inside the provided **solution root**.
- In a live match, the solution root is `workspace/src/`. In a pulled Open Challenge, run `cd <challenge>` and use that directory's top-level `src/`.
- If your agent already runs in the solution root, create `index.html`, `package.json`, or other entrypoint files directly in the current directory.
- Do NOT create a nested `workspace/src/` or `src/`, and do not leave implementation assets beside the submitted Open Challenge `src/` directory.

**Difficulty:** medium  
**Estimated Time:** 45 minutes  
**Type:** Browser web app

## Runtime Compatibility

- The final solution root must contain a ready-to-serve `index.html` plus its browser-executable HTML/CSS/JavaScript/assets.
- If using Node.js for development or evaluation, it must work on Node.js 20 LTS and `package.json` must include a `start` script.
- If using Go, `go.mod` must specify `go 1.24` or lower.
- If using Python, use Python 3.12-compatible syntax.
- Do not use external network calls, CDNs, remote fonts, remote images, or online APIs.

## Critical: Public Preview Submission Contract

Open Challenge result preview is static-only. It serves files from the submitted solution archive in a sandbox and does **not** run `npm`, Vite, Node.js, Go, Python, PHP, or any backend process.

- `index.html` at the solution root must load directly from a plain static HTTP server.
- Reference scripts, styles, images, fonts, audio, and other assets with relative URLs such as `assets/main.js` or `./styles.css`.
- Do not use root-absolute URLs such as `/main.ts`, `/src/main.ts`, `/assets/main.js`, or `/favicon.svg`; they escape the submission preview path.
- Do not reference `.ts`, `.tsx`, or `.jsx` files from `index.html`. Browsers do not compile those files, and public preview serves only ready browser assets. Compile them to `.js` or `.mjs`.
- Do not depend on API routes, server-side rendering, runtime environment variables, WebSockets, or a development-server fallback. The complete playable game must work from the static bundle with network access disabled.
- Do not try to fix preview by allowing `Origin: null` or weakening CORS. A compliant submission does not require cross-origin requests.

If you use Vite or TypeScript:

1. Configure the production build to use relative asset paths, for example `base: "./"` in Vite.
2. Run the production build before submission.
3. Copy the **contents** of the generated `dist/` or `build/` directory into the solution root so the root `index.html` is the built file and its compiled assets are included. The submission collector excludes directories named `dist/` and `build/`.
4. Confirm the submitted root `index.html` references compiled `.js`/`.mjs` files through relative paths and does not reference source `.ts`/`.tsx`/`.jsx` files.

Before submitting, run a plain static server from the solution root, for example:

```bash
python3 -m http.server 8000 --bind 127.0.0.1
```

Open `http://127.0.0.1:8000/`, verify that the game is fully playable, and check the browser console and Network panel for missing files, blocked requests, or runtime errors. Passing through `npm run dev` or a Vite development server is not sufficient for this check.

## Game Requirements

- Show a playable RPG arena with a hero, an enemy, and a visible combat area.
- Implement turn-based combat with at least one basic attack and one ability or inventory action.
- Display hero stats and enemy stats, including HP and at least one additional stat such as attack, defense, mana, stamina, or armor.
- Use deterministic seeded encounters. The same seed must produce the same initial enemy/state.
- Show a combat log that records player and enemy actions.
- Show a clear win/loss/in-progress state.
- Include mouse controls. Keyboard shortcuts are optional but encouraged.
- Use responsive layout so the game remains usable on a phone-width viewport.

## Presentation and Gameplay Quality

This task will be reviewed by humans, so implementation quality should go beyond the minimum test hooks. Make the game look intentional, polished, and enjoyable to play.

- Prioritize visual quality: cohesive art direction, readable typography, clear spacing, strong contrast, and a deliberate color palette.
- Add meaningful animations and transitions for attacks, damage, healing, turn changes, status effects, victory, and defeat.
- Make combat feel interactive: actions should have immediate feedback, visible consequences, and enough pacing that turns are easy to follow.
- Think through game details such as ability cooldowns, resource costs, enemy behavior, item usage, tooltips, disabled states, and restart/retry flow.
- Keep the UI technically solid: no overlapping text, no layout jumps during combat, responsive controls, accessible button states, and clear focus/hover feedback.
- Use assets, CSS effects, canvas, or lightweight in-repo artwork where useful, but do not depend on external networks or CDNs.
- A complete, polished, playable experience should score better than a minimal interface that only passes automated smoke tests.

## Technical Quality Expectations

This is a dependency-free static browser game, so reviewers will judge the architecture proportionately. A framework, backend layering, build tool, or large component hierarchy is not required. Native browser modules loaded through relative URLs are fully acceptable.

- Keep deterministic game logic separate from DOM rendering and event orchestration. Separation may use focused ES modules or clear internal boundaries; file count alone is not a quality signal.
- Make the deterministic game logic independently testable. Deterministic engine tests should cover the same-seed contract, valid and rejected actions, cooldown/resource boundaries, and terminal win/loss behavior.
- Construct dynamic UI safely. Prefer `textContent`, `createElement`, `replaceChildren`, or equivalent safe APIs; avoid unsafe HTML injection with dynamic game or user-controlled values.
- Include browser-relevant defensive handling where the app has real failure boundaries: seed and action validation, missing required DOM hooks, unavailable optional browser APIs, repeated/locked actions, asynchronous enemy turns, and reset/retry races.
- Do not add fake backend, database, HTTP, or framework abstractions solely for review. Clear, maintainable boundaries and behavior-focused tests matter more than architectural ceremony.

## Required DOM/Test Hooks

Smoke tests and human reviewers will look for these stable hooks in the served page:

| Hook | Required selector | Purpose |
|------|-------------------|---------|
| App root | `[data-testid="app-root"]` | Main game mount point |
| Hero stats | `[data-testid="hero-stats"]` | Visible hero HP/stat state |
| Enemy stats | `[data-testid="enemy-stats"]` | Visible enemy HP/stat state |
| Combat log | `[data-testid="combat-log"]` | Action history |
| Attack button | `[data-testid="attack-button"]` | Basic action control |
| Ability button | `[data-testid="ability-button"]` | Ability or inventory action |
| Inventory panel | `[data-testid="inventory-panel"]` | Items, abilities, or resources |
| Encounter seed | `[data-testid="encounter-seed"]` | Deterministic seed display |
| Game status | `[data-testid="game-status"]` | Win/loss/in-progress state |

## Acceptance Criteria

- The app serves successfully at `/`.
- The first screen shows the actual game, not a landing page or instructions-only page.
- The user can take a turn and see the game state change.
- The enemy can respond or the game can advance deterministically after a player action.
- The game can reach a visible win or loss state.
-