Build your first theme and course in the Theme Workshop

Path Protocol (Eric Silver) — Tue, 18 Aug 2026 22:01:30 +0000

Build your first theme and course in the Theme Workshop

Path Protocol is an open-source browser precision game — 100 levels, MIT licensed. But the part I'm most excited for people to try is the Theme Workshop: a built-in editor for creating your own themes and courses.

This tutorial walks you through creating your first theme + course from start to finish and publishing it. No prior game-dev experience needed.

1. Register and open the Theme Workshop

Create an account (username, email, password), then open the Theme Workshop from the main menu. On first use you'll be asked to choose the official campaign or an enabled public theme as your starting point.

2. Create a demo theme and level

Use Create demo theme and level. This clones the default campaign and appends a showcase hole. "Cloned" here means the level JSON only — the geometry and rules are copied, not the visual assets. That's an important detail: the game keeps collision geometry and presentation separate.

3. Edit the course

The editor works on a 10-unit grid in a 1600 × 900 logical world.

Resize an object by dragging its edge/corner handles.
Right-click (or Shift+F10) for image, sound, and JSON actions.
Add obstacles from the Kenney Course Builder palette — fairway, green, ramp, and hazard templates. You can reshape them after placement.
Set the arena boundary to a rounded rectangle, ellipse, or polygon.

4. Assign visuals

Pick a GLB model from the 126-model Kenney Minigolf catalog (optional model3dId). The geometry stays JSON-owned — the model is just presentation.
Replace an object's image or sound via the media browser, which supports recursive folders, search, preview, and provenance.

5. Validate and save

Before a level is accepted, it passes schema validation plus generated-course gameplay checks. Invalid levels are rejected — this is what keeps community content safe and consistent. Fix what the validator flags and save.

6. Playtest

Run the level and watch the token-center trail. This shows the actual collision path your ball takes, which is the ground truth for how the course plays.

7. Publish and share

Go live as a public theme (moderation exists; the default campaign is read-only). Then copy the link and share it with the community.

What will you build? I'd genuinely love to see what courses people come up with — a wild obstacle, a themed arena, a brutal par-3. If you publish one, drop the link in the comments.

Build a deterministic browser game engine

Path Protocol (Eric Silver) — Tue, 18 Aug 2026 21:58:59 +0000

I built an open-source browser precision game called Path Protocol — 100 levels, a Theme Workshop for authoring your own courses, MIT licensed. Along the way, one constraint shaped every architectural decision: levels must replay identically so scores are comparable.

That single requirement turns determinism from a nice-to-have into the product itself. If two players run the same level and the physics drifts, the leaderboard is meaningless. Here's how I structured the engine to make that work, and what I'd do again.

The game loop: two clocks, not one

The most important decision was separating the simulation clock from the render clock.

requestAnimationFrame fires when the browser is ready to paint — which varies with monitor refresh rate, background tabs, and system load. If the simulation runs on that clock, the same level plays differently on a 60 Hz vs 144 Hz display.

Instead, the engine runs a fixed 60 Hz step with an accumulator:

let accumulator = 0;
const STEP = 1000 / 60;

function frame(now) {
  const dt = Math.min(now - last, 250); // clamp to avoid spiral of death
  last = now;
  accumulator += dt;
  while (accumulator >= STEP) {
    update(STEP);   // simulation advances in fixed increments
    accumulator -= STEP;
  }
  render();         // rendering can happen at any rate
  requestAnimationFrame(frame);
}

The simulation only ever advances in fixed STEP increments. Rendering happens as often as the browser allows, but it never changes the game state. This is what makes replays deterministic and scores comparable.

The level layout is also seeded: the same seed produces the same start position, targets, pickups, and hazards. No randomness leaks into the simulation.

Ownership: the engine never imports React, Three.js, or the DOM

The cleanest boundary I drew was that the engine is framework-neutral. It doesn't know React exists, doesn't touch Three.js, and never reads the DOM.

React owns the menus, HUD, and authoring UI.
Three.js owns presentation — rendering the arena.
The engine owns movement, collision, scoring, and targets.

The renderer exposes a thin surface to the engine: update, resize, screenToWorld, and a few others. The engine calls into it, never the other way around.

This separation made the engine trivially testable. I could run the entire simulation headless in Vitest — no browser, no WebGL — and assert that a given input produces a given outcome. That's the property that makes deterministic gameplay trustworthy.

Collision and scoring live in contracts, not visual assets

A common trap is deriving collision geometry from visual asset bounds. I avoided that by keeping collision geometry in JSON, separate from the rendered meshes.

Collision uses token shapes with swept tests to avoid tunneling at high speed.
Penalty and restart rules are explicit.
The scoring formula lives in exactly one module — there's no second copy to drift.

This matters for the Theme Workshop too: the same JSON contracts that power the player-facing levels also power community-authored courses. Before any level is accepted, it passes schema validation. That's how an open authoring system stays safe and consistent.

What AI-assisted development actually changed

I want to be honest here, because it's easy to overstate. AI helped me move quickly between idea → code → tests → docs. That iteration speed was real and valuable.

But the hard part stayed hard: defining the rules. Determinism, collision boundaries, scoring ownership, persistence, security, and what the Theme Workshop should allow — those were decisions I had to make deliberately. The AI was a fast pair-programmer, not a substitute for the architecture.

Try it and contribute

The project is open source under MIT. If you're curious about the fixed-step engine, the collision contracts, or the authoring system, the code is all there.

One question to end with: what's the first thing you'd want to see in a deterministic game engine's test suite? I'd love to hear how others approach replayability.

DEV Community: Path Protocol (Eric Silver)

Build your first theme and course in the Theme Workshop

Build your first theme and course in the Theme Workshop

1. Register and open the Theme Workshop

2. Create a demo theme and level

3. Edit the course

4. Assign visuals

5. Validate and save

6. Playtest

7. Publish and share

Build a deterministic browser game engine

The game loop: two clocks, not one

Ownership: the engine never imports React, Three.js, or the DOM

Collision and scoring live in contracts, not visual assets

What AI-assisted development actually changed

Try it and contribute