Learning Arena
A local playable experiment inspired by simple roguelike combat. Move, dodge,
and clear one room while an enemy neural policy practices between rounds.
The game uses original visuals, deterministic physics, and fresh domain weights.
Play
Live game: https://matiz-learning-arena.vercel.app. No installation or login
is required. This is a separate Vercel project alongside Matiz. Gameplay,
training, and saved progress run in your browser; checkpoints are not shared
between devices or with the local version.
For a local copy:
From this directory, run:
npm startOpen local-service. Python 3 serves the static app; gameplay and training
run locally in the browser. No runtime package installation or external service
is needed. Closing the server stops access until it is restarted.
- Move with WASD, arrow keys, or drag within the arena on a touch screen.
- Your weapon aims and fires automatically, including while moving.
- Coral warning lines show the enemy's upcoming aim. Cover blocks projectiles.
- Defeat the enemy before losing your health or the 60-second timer expires.
- Pause with the button, Escape, or Space. Leaving the tab pauses the round.
- After a round choose Sharper shot (+20% damage), Quick feet (+18%
movement speed), or Second wind (+25 maximum health). One loadout is
active at a time; upgrades do not stack. A chosen loadout persists into later
rounds until replaced.
- Automatic practice is enabled by default. You can also practice before a
round or stop a practice session without changing the current checkpoint.
Progress is saved under learning-arena-v1 in this browser's local storage.
Different browsers and origins have separate progress. Invalid saved weights
are rejected; storage failures leave the game playable with temporary progress.
What actually learns
The enemy's movement is selected by a real actor-critic neural network:
32 observed features -> 64 ReLU -> 64 ReLU
-> 9 movement probabilities + scalar value estimateThe 6,922 parameters begin with seeded random weights, clearly labeled in the
game. Observation features include relative player motion, health, cooldowns,
boundaries, cover distance, and the three nearest incoming projectiles with
presence flags. The enemy cannot read future player input. Its policy acts at
5 Hz; shared physics runs at 30 Hz. Diagonal speed is normalized.
Each practice session performs PPO updates in a separate browser worker:
eight rollouts of 128 decisions, two epochs, minibatches of 64, and 32 Adam
updates. This is 1,024 ANN decisions, with at most 6,144 training physics steps,
plus separate evaluation. Training is capped and cancellable. Adam state is
fresh for each practice session; saved progress is an inference checkpoint,
not a full optimizer-resume artifact.
The interface separates attempted optimizer updates from accepted checkpoint
versions. A rejected candidate can change thousands of weights but none of
those changes reach your next opponent. Candidate reports show parameter and
movement-head changes, plus baseline-to-candidate damage, wins and timeouts.
Those diagnostics establish that optimization ran, not that the enemy became
stronger. A persisted attempt counter prevents the training seed from repeating
merely because the saved report list was capped and the page reloaded.
The most recent human round supplies a coarse movement summary: orbit, chase,
zigzag, or dodge. Training biases a mixed pool of simulated players toward that
style. It does not directly train on recorded human transitions, infer a
person's overall skill, or prove that the human learned.
Weapons, damage, collision rules, and reaction interval are ordinary fixed
game mechanics. Neural policies only control enemy movement. A validated
checkpoint is frozen for an entire round. Updates are applied between rounds.
Inference errors activate an explicitly labeled scripted movement fallback.
Candidate checks and their limits
Baseline and candidate policies play the same eight fixed rooms with four
scripted styles, balanced equipment, 20-second limits, and matched random
action-sampling seeds. Both use the same stochastic movement selection as
live play. Reports retain individual outcomes, reward, damage dealt/taken,
combat participation, timeout frequency, paired differences, and standard error.
A candidate is retained only when it gains mean enemy reward, engages in at
least half the evaluation rounds, and loses no more than 12.5 percentage points
of participation relative to the baseline. Participation means at least five
combined damage points were exchanged. Rejected candidates leave the active
checkpoint unchanged, although attempted training updates remain in the record.
This is a small exploratory gate, not statistical proof of general strength or
enjoyment. The suite is reused for selection, so it is not an untouched final
test. A reward gain can reflect longer survival or more timeouts rather than
more damage or wins. The UI reports those distinctions; upgrade-dependent human
round scores are not a skill benchmark. Larger held-out suites and human play
testing are the next quality checks.
Architecture
| File | Responsibility |
|---|---|
game.js | Seeded environment, fixed physics, observations and scripted reference players |
neural.js | Validated JSON model, inference, GAE, PPO gradients and Adam |
train-worker.js | Bounded simulated practice, paired evaluation and promotion decision |
app.js | Human input, rendering, per-round policy freezing and saved progress |
index.html, styles.css | Responsive playable interface and learning record |
tests/ | Physics, numerical gradient, training and browser integration checks |
Matiz supplied the architectural starting point: configurable MLPs, separate
policies, seeded experiments and opponent comparisons. Poker inputs, action
heads, weights and Deep CFR training are not used in this domain. Existing
Matiz repositories and running experiments were not edited.
Verify
The app itself has no JavaScript runtime dependencies. For development checks:
npm ci
npm test
npm run test:browserBrowser tests use an installed Google Chrome through Playwright. They cover
keyboard movement, pause, full round completion, upgrades, actual worker
training, saved checkpoint restoration, narrow mobile layout, pointer movement,
and corrupt-storage/worker-failure behavior. Numerical tests compare analytic
PPO gradients against finite differences and verify actual parameter updates.
Production verification is recorded in LIVE-VERIFICATION.json. It checks
anonymous access, exact runtime asset hashes, module MIME types, actual worker
training, checkpoint restoration, keyboard/pause controls, and mobile layout
and pointer movement. To repeat it:
node scripts/verify-live.mjs https://matiz-learning-arena.vercel.appDeployment
deploy/ contains only the six runtime files and Vercel configuration. Tests,
development dependencies, receipts, and credentials are excluded. Deployment
metadata is recorded in DEPLOYMENT.json. To publish a reviewed update, copy
the six runtime files into deploy/, verify them, and run:
cd deploy
npx vercel@62.1.0 deploy --prod --yes --scope kulbirminhas-5072Use this project's existing Vercel link. Do not copy Matiz's project link or
deploy this bundle into the Matiz project. A source edit alone does not update
the published game; refresh the static bundle before deploying.
Next experiments
Keep the single-room baseline while adding an untouched evaluation suite and
player feedback. Add attack patterns one at a time, then multiple enemies and
an AI companion. A later player-plus-two-allies versus three-enemies mode can
exercise the six-agent interactions without changing the initial controls.
Learning check, 2026-10-01
The user's concern is supported by the behavioral tests: optimization is real,
but reliable improvement has not been demonstrated. A real automatic local
round changed 5,984 of 6,922 parameters, advanced v0 to v1, used v1 in the next
round, and restored it after reload. The published worker also completed real
training and checkpoint restoration during an independent browser check.
A separate 50-attempt orbit-style training lineage retained six candidates.
Its reused eight-room selection score improved from -1.6163 to -1.1833.
On 32 fresh, balanced, 20-second rooms, the same lineage produced:
| Metric | Fresh policy | Accepted policy after 50 attempts |
|---|---|---|
| Mean enemy reward | -1.4192 | -1.6209 |
| Mean enemy damage dealt | 36.00 | 31.88 |
| Mean enemy damage taken | 95.25 | 98.78 |
| Enemy wins | 0 / 32 | 0 / 32 |
An additional 80 previously unused 60-second rooms, balanced across four
loadouts and five movement styles including a stationary control, also failed
to show a gain: enemy wins changed from 12.5% to 8.75%, with almost identical
mean damage dealt. These are limited scripted-opponent tests of one training
lineage, not results from the user's saved policy or a human enjoyment study.
The initial policy is nearly uniform over nine moves. After 50 attempts its
average most-probable action rose from 11.20% to 17.35% on fixed observation
probes; actor gradients and action probabilities change, but movement remains
highly exploratory. Training uses a short simulated style approximation rather
than human transitions. Stationary human play currently selects a movingdodge simulation, and practice uses shorter rounds and balanced equipment.
The promotion gate also permits reward gains from damage avoidance, which
need not make the enemy more threatening.
Feedback for the next learning revision: first establish competence by
training an ANN to imitate the existing scripted reference enemy, which was
stronger on these tests; validate that checkpoint on separate rooms. Match
practice duration, loadouts, and stationary behavior to the actual game. Use a
larger, separate promotion suite and reserve an untouched final test. Increase
training only with measured combat gains. The diagnostic fixes do not change
the ANN, rewards, or promotion gate and do not claim to solve those weaknesses.
Evidence is recorded in LEARNING-CHECK.json,artifacts/automatic-learning-check.json,artifacts/rl-diagnostic-20261001-agent-results.json, andartifacts/live-duration-holdout.json. Diagnostic scripts are retained underscripts/ and artifacts/; experimental checkpoints are excluded from the
deployment bundle. The 80-room check can be repeated withnode scripts/learning-holdout.mjs using the retained diagnostic checkpoint.