Public WIP game landing page

Lumina 3D

A cozy magical browser-game prototype about little helpers, environmental puzzles, love-letter story beats, and the satisfying feeling of making a tiny world come alive one playable slice at a time.

Watch the demo Tour the levels Open GitHub

7fresh screenshots captured from the local game build

8debug-routable scenes in the current level registry

YouTubefull demo hosted for sharper playback

First reveal

Watch the current build before reading the spellbook.

This is the full demo recording hosted on YouTube so the game stays crisp instead of being squeezed through GitHub Pages video limits. It gives a fast sense of motion, scale, tone, and direction while keeping the honest WIP boundary: progress with receipts, not a finished release trailer.

Lumina 3D gameplay poster frame from the demo video. — The demo now plays from YouTube using the original full screen recording instead of a heavily compressed GitHub Pages file. Open on YouTube

Second reveal

A numbered tour through the current world.

These started as numbered screenshot placeholders with capture briefs, then were replaced by real Playwright screenshots from the local dev build. Each card shows the scene, the debug key used to capture it, and the role that scene plays in the game arc.

Tutorial scene with Lumina on a floating green grid island and a movement instruction prompt.

Tutorial: the first spell is movement.

The smallest playable promise: movement instructions, a readable grid, and a first character moment.

Debug key 1Onboarding

Home Intro scene with Lumina near a small house, trees, and a greeting speech bubble.

Home Intro: the quest begins softly.

The cozy origin point: a house, a greeting, and the first signal that this is playful and story-led.

Debug key 2Story setup

Level One scene with Lumina, a river, lily pads, trees, and a large title overlay.

Level One: the world teaches with terrain.

The first full level identity: water, pathing, and terrain begin turning movement into environmental puzzles.

Debug key 3First route

Level Two scene with raised terrain, path tiles, a button pad, and a large title overlay.

Level Two: mechanisms start to matter.

More than walking: elevation, buttons, paths, and a structured route start to shape a compact puzzle space.

Debug key 4Puzzle language

Level Three scene with Lumina, islands, a bridge, lily pads, and water crossing space.

Level Three: the lake becomes a design lane.

The active lake lane: water routes, bridge logic, and a bigger sense of travel are coming into view.

Debug key 5Active WIP

Level Four scene with Lumina, blue block structures, lily pads, logs, water lanes, and a title overlay.

Level Four: a river-crossing slice appears.

A debug-playable river slice with moving-route ingredients and reusable component thinking starting to surface.

Debug key 6River system

City Level scene with roads, traffic, buildings, a traffic light, and Lumina.

City Level: a future pattern tests itself.

A forward-looking city shell that shows the world can grow beyond grass islands into traffic crossings and reusable challenge patterns.

Debug key 7Future shell

Open the level status notes

The Tutorial, Home Intro, Level One, Level Two, and Level Three are marked as editor-supported in the current level registry. Level Three is an active lake/island lane, not a finished route.

Level Four is a debug-playable river-crossing first slice. The City Level is a debug-only provisional future Level Five candidate and reusable traffic-crossing pattern. The Portal Cinematic exists as a noninteractive story bridge between Level Four and the City shell.

Third reveal

Where the project has been, where it is, where it is going.

The page should feel magical, but the project story should stay concrete. Lumina 3D is a growing browser-game prototype with a visible path from first playable movement to reusable level systems.

Has been

From sample world to playable language.

Established Vite and Three.js as the browser-game foundation.
Added a GLTF main character, KayKit and voxel assets, and orthographic camera language.
Built the first loop of movement, prompts, dialogue, buttons, terrain, water, and helper characters.

Is now

A public WIP with inspectable structure.

Eight scenes are routable through the debug registry.
Level Three and Level Four are active design/development lanes.
The repo documents commands, level patterns, asset handling, smoke tooling, and known caveats.

Going next

Toward a stronger playable release candidate.

Harden Level Three and Level Four into clearer routes.
Promote reusable Cubeling, river, and traffic patterns where they reduce duplication.
Complete an asset-license and attribution pass before any public playable release claim.

Open the build workflow

The working rhythm is small-slice game development: define the next playable moment, add or adjust the scene and systems, run the local dev build, visually inspect the result, then record what is proven and what is still WIP.

For this Shareable update, the workflow was deliberately placeholder-first: create numbered image slots with capture intent, open the game locally, route to scenes with debug keys, capture screenshots, compress them for web, and replace the placeholders with real images.

Open the QA workflow

The quality bar is not just "the HTML exists." The page needs playable media, real screenshots, public-safe language, no private local paths, no layout clipping, mobile readability, live GitHub Pages verification, and browser automation cleanup.

Fourth reveal

The code map, revealed in layers.

A nontechnical reader can stop at "it is a Three.js browser game." A technical reader can keep opening panels until the project shape becomes inspectable.

Plain English

Scenes are worlds. Systems make them move.

The project separates scene IDs, level data, scene builders, runtime systems, UI, debug hooks, and documentation. That makes it possible to add a new level without turning every idea into a one-off patch in the entry file.

src/config/scenes.js names the scene IDs.
src/config/levelRegistry.js maps scenes to debug keys, smoke IDs, and source files.
src/levels/ stores level layout data.
src/scenes/ builds scene objects and flow behavior.
src/systems/ holds runtime systems such as movement, collisions, dialogue, audio, river crossing, and city traffic.

Representative structure

Level routing is explicit.

export const SCENES = {
  TUTORIAL: "tutorial",
  HOME: "home_intro",
  LEVEL_ONE: "level_one",
  LEVEL_TWO: "level_two",
  LEVEL_THREE: "level_three",
  LEVEL_FOUR: "level_four",
  POST_LEVEL_FOUR_PORTAL: "post_level_four_portal",
  CITY_LEVEL: "city_level"
};

// The level registry connects each scene to:
// display name, debug key, catalog ID,
// smoke ID, editor support, and source files.

Open the new-level recipe

The README's recipe is intentionally procedural: add layout constants in src/levels/newLevel.js, build logic in src/scenes/newLevelScene.js, add a scene ID, register metadata in src/config/levelRegistry.js, add catalog/tooling coverage, wire only the smallest needed runtime handoff through src/main.js, then add scene smoke coverage.

Open the reusable-component direction

The project is moving away from one-off gameplay objects. Cubeling Echo, Totem, actor factories, traffic-crossing contracts, and river-crossing contracts live under src/components/ and companion docs. That is the path from "cool prototype" to "world that can keep growing."

Open the technical honesty note

The repo currently has active WIP changes. This Shareable treats the game repo as runtime and evidence, not as a polished release branch. The page links to the public source trail and keeps caveats visible instead of implying a finished game.

Fifth reveal

How I prompted the process without dumping the private transcript.

The useful public lesson is the workflow pattern: ask for a playable slice, require proof, protect WIP truth, and make the artifact explain itself at more than one depth level.

1. Start with the player moment.

Prompts framed the next slice as something visible: a route, a helper, a bridge, a crossing, a level identity, or a story beat.

"Make the next playable moment obvious before adding more systems."

2. Ask for proof, not vibes.

The workflow pushed for screenshots, smoke checks, browser validation, and repo evidence before saying the work was shareable.

"Open the game, capture the scene, and tell me what was actually verified."

3. Turn process into public story.

This Shareable uses sanitized prompt patterns and progressive disclosure so the reader can learn the method without seeing private chat logs.

"Reveal the technical details only as the reader asks for more."

Open the screenshot prompt pattern

Pattern: create numbered placeholders first, name what each image should prove, then replace each slot only after capturing the actual running game. That keeps the page from becoming decorative. Every image has a job.

Open the public-safety rule

Representative process details are public; raw private transcripts, secrets, local machine paths, and unreviewed personal material are not. The page uses relative repo paths and public GitHub links where a reader needs proof.

Final reveal

Open source trail, clear caveats, real next step.

The useful public posture is simple: Lumina 3D is real, visible, and growing. It is not yet a finished playable release.

RepoJonathanKHobson/Lumina3D

Public source trail for the browser-game prototype.

StackVite + Three.js

Browser-native runtime with local development and smoke tooling.

ScenesDebug keys 1-8

Temporary QA shortcuts, not final player-facing UI.

StatusPublic WIP

Portfolio/process visibility with release caveats.

NextPlayable milestone

Harden routes and complete asset attribution before stronger launch claims.