Wickward v0.7

Current version

Wickward 0.7

Engine

Three.js 0.183 · Web

Technology

TypeScript · 3D · Solo

Game built with

OpenAI Codex · GPT-6.1 Sol · Max

Iterations

7

Art style

Stylised, Low-poly

Initial draft = 1. Each subsequent creation or revision round until the finished result adds 1.

# Wickward game creation prompt

Build a complete, polished, playable browser game with Three.js and TypeScript using the specification below. Deliver working source code, a reproducible local build, useful tests, original or licensed assets, and a clear handoff. The first delivery must be playable locally on desktop and mobile browsers.

Work through gameplay, visuals, content, persistence, and verification until the local game works. Make sensible implementation decisions and record material deviations.

## Product identity

Use Wickward as the working title.

Wickward is an endless crowd-routing puzzle game. The player guides little living ceramic lantern creatures, called Wicks, through broken floating worlds to a sanctuary beacon. The creatures move automatically. The player changes their environment using limited tools, controls the flow of the crowd, and combines mechanisms to create a safe route.

The broad genre reference is the old game Lemmings: indirect control of a vulnerable crowd trying to reach an exit. Create Wickward's own world, characters, art, audio, puzzles, interface, terminology, animations, and concrete tool system. Do not copy recognizable characters, silhouettes, hair, outfits, level layouts, logos, UI arrangements, sound effects, music, source code, extracted assets, or text from that franchise. Do not use its name in the public title, logo, promotional copy, or metadata.

Our distinguishing identity is a miniature world of clay, plants, copper, and light, with tools placed in the environment that guide entire groups. Keep an asset provenance and license list. Create original assets or use assets with a suitable documented license.

## Art direction

Create a stylized 3D diorama with rounded low-poly forms, bevels, matte ceramic surfaces, mossy stone, copper details, warm amber lantern cores, and cool atmospheric backgrounds. Aim for a coherent, appealing small game that looks intentionally designed.

Wicks have rounded ceramic bodies, short feet, a small copper handle, and an expressive face formed by openings in the clay. Give them a readable silhouette at mobile scale. Animate walking, turning, waiting, lifting, falling, rescue, and failure. Their handle should wobble and their light should react subtly to their state. Failure is gentle and non-graphic: the light fades into a few sparks.

Use genuine Three.js meshes and lighting. Procedurally modeled assets are welcome if they are finished and distinctive. Plain cubes may help during development, but replace temporary visual scaffolding before calling the game complete. Make the entry gate, sanctuary, tools, and hazards recognizable without relying on color alone.

Render the world in 3D, but keep gameplay on a deterministic side-view plane. Use an orthographic camera with a slight angle that reveals depth without hiding the walkable surface. Decorative depth must not introduce ambiguous traversable lanes. Avoid free camera rotation during normal play. Fade or remove foreground objects that would obstruct a puzzle.

Use restrained particles, soft shadows, layered backgrounds, subtle fog, and small environmental animations. Keep glow readable without requiring expensive postprocessing. Low quality mode must preserve all gameplay information and the same rules.

## Core loop and run rules

A run starts at level 1 with zero completed levels. Before each level, show the route, sanctuary, rescue quota, available tools, and relevant hazards. Let the player inspect the level and place the permitted tools before starting the creature stream.

Once started, creatures walk automatically. They turn at solid walls, fall at unsupported edges, react to tools and hazards, and are rescued when they enter the sanctuary. Define the exact movement, collision, fall safety, trigger, and rescue rules centrally. Use stable creature IDs and ensure each creature can be rescued or lost only once.

When the required rescue count is reached, mark the level as cleared exactly once, stop further gameplay input for that level, save progress, and show the result. Allow a short celebration and continue to the next generated level. When rescued plus surviving active creatures plus unreleased creatures is less than the quota, end the run immediately with a clear explanation. Provide an explicit option to abandon a stuck attempt.

Use approximately 12 creatures in introductory levels and increase within a maximum of 60 active creatures. Tune ordinary levels for about two to four minutes of play. Keep release spacing controlled by the level rules; an unrestricted release-rate control is not needed for this version.

Provide pause and 0.5x, 1x, and 2x speed. Planning and tool placement while paused are allowed for everyone, including normal highscore runs. Speed changes advance the same simulation; they must not change collision outcomes or tool durations measured in simulation time. Do not reward fast physical tapping over good planning.

Failure ends the normal run. A new normal run starts at level 1. Allow retrying the failed seed in a clearly labeled practice mode whose results cannot update the normal personal best. A short interactive tutorial is also separate from scored runs. Do not add purchases, ads, permanent power advantages, an account requirement, or unrelated game modes.

## Six environment tools

Implement all six tools with distinct icons, short explanations, visible remaining charges, placement previews, and clear invalid-placement feedback. Invalid placement consumes nothing. Costs belong to the level's starting budget; tools do not create a cross-run economy.

1. Waymark: place a directional light sign on a valid surface. A passing Wick adopts the indicated left or right direction. Prevent repeated trigger handling from trapping a creature in a rapid oscillation.
2. Rootspan: grow a persistent bridge between compatible nearby anchors. Preview the actual bridge, its endpoints, and its valid range. It cannot pass through solid terrain or bridge arbitrary distances.
3. Lift Bloom: place a lifting plant at a compatible socket. It sends passing Wicks along a predetermined, visible trajectory to a valid landing area. The result must be deterministic and independent of frame rate.
4. Chime Gate: deploy a holding point that safely gathers Wicks. The player can toggle hold and release after placement without paying another placement charge. Make its state obvious and define how the entire queue exits. Any capacity limit must be visible and considered by the generator.
5. Burrow Lantern: open a predefined tunnel through marked soft material. Restrict terrain modification to authored cells or regions whose collision and visuals can be updated consistently. Full freeform voxel destruction is outside this version's scope.
6. Shield Lantern: create a temporary protection field against explicitly marked water or heat hazards. Show its covered area and remaining duration. It does not prevent arbitrary falls, crushing, or every hazard type.

Prefer placing tools on generous world targets over selecting individual tiny moving characters. On touch, selecting a tool and tapping a target shows the preview; a second tap or a reachable confirm control commits it. Provide cancellation. Desktop may use faster direct placement when the preview is already visible.

Introduce the tools gradually and make their interactions useful. For example, hold a group with a Chime Gate, grow a Rootspan, then release the group during a safe hazard phase. Avoid puzzles that require undisclosed rules, a single exact pixel, or a one-frame action window.

## Worlds and authored content

Create five visually distinct biomes with meaningful gameplay differences:

- Mosslight Gardens: moss islands, roots, gentle waterfalls, basic gaps, and safe introductory routing.
- Copperworks: small copper machines, clearly telegraphed shutters, and mechanical timing puzzles.
- Rainbell Caverns: cool cave light, rain curtains that extinguish Wicks, and protection or timing decisions.
- Cloudroot Isles: airy islands, visible wind pulses, Lift Bloom routes, and vertical transitions.
- Emberglass Ruins: glowing glass and ceramic ruins, timed heat hazards, and combinations of earlier mechanics.

Change the main biome approximately every five levels. After the first full cycle, revisit worlds with deeper combinations and compatible transition modules. Introduce new hazards safely before combining them under pressure.

Deliver at least 30 authored puzzle modules across the five worlds, covering at least 12 structurally different puzzle patterns. Color changes and decorative reskins do not count as distinct puzzle patterns. Include safe entry and exit modules, connective modules, teaching modules, decision points, and advanced combinations. Reuse meshes where useful, but vary the actual decisions, route shape, elevation, timing, and tool dependencies.

Provide a development-only module gallery or equivalent inspection route so each module can be tested independently. Keep content definitions separate from renderer code, and document how to add a module and a biome without rewriting the generator.

## Procedural generation and solvability

Endless means a continuing sequence of newly assembled levels from the existing content library, with no designed final level. It does not mean downloading or generating new assets with an AI API during gameplay. All required generation must run locally and deterministically.

Use a seeded PRNG. Level generation depends on the run seed, level index, and generation/rules version. Keep gameplay randomness separate from visual randomness. The same inputs and version must reproduce the same puzzle and its rules.

Each module definition must include its ID, biome compatibility, dimensions, connectors, traversable geometry, tool sockets, hazards, difficulty contribution, resource requirements, safe entry/exit conditions, and a reference solution expressed as simulation actions. Connectors need more than a matching position: validate elevation, direction, clearance, arrival timing assumptions, and group throughput where relevant.

Generate from a constrained puzzle grammar. Choose a target difficulty, select a small set of compatible modules, establish a viable rescue route, derive a valid tool budget, and add only compatible optional alternatives and decoration. Keep alternatives within the same rescue and budget rules.

Validate the whole assembled level. Individually solvable modules can become impossible when connected. A simple connected path is not sufficient: tool availability, construction timing, moving hazards, lifts, falls, crowd spacing, and the rescue quota must all work together.

Use the actual shared gameplay simulation without rendering to replay a composed reference solution for every candidate that will be served. The witness must use legal player actions and the exact rules, inventory, spawn schedule, and timings of that candidate. Require success with a small timing or resource margin. Restrict the grammar when necessary to make this validation tractable; a general solver for arbitrary puzzles is unnecessary.

If validation fails, reject the candidate. Bound candidate attempts and simulation work. After a finite limit, use a prevalidated fallback appropriate to the difficulty band and record the fallback for QA. A generation failure must not leave the player waiting forever or facing a broken stage. Run expensive validation off the render loop and prepare the next level ahead of time where useful.

Keep a recent-history record to reduce repeated layouts and tool sequences. Rotate puzzle patterns rather than merely changing background colors. Preserve the seed and module IDs in diagnostic output so a reported problem can be reproduced.

## Difficulty progression

Increase difficulty through more dependent decisions, tighter but sufficient tool budgets, moderately higher rescue quotas, longer routes within sensible limits, and more coordinated hazard phases. Increase complexity gradually across biome cycles rather than resetting it when the world changes.

Use a transparent difficulty budget and tune it with actual playtests. Starting targets are a rescue quota near 60 percent, rising toward roughly 85 percent; early single-mechanic puzzles; and later combinations with several meaningful dependencies. These are tuning targets, not a requirement to force an invalid puzzle.

Keep hard limits on active creatures, simultaneous hazards, level length, and the narrowness of timing windows. Do not scale movement speed, crowd size, numerical values, or required precision without bounds. At very high levels, approach a human-playable ceiling and obtain further variety from combinations. Preserve solvability and readable input windows even when the run becomes demanding.

Do not secretly alter the puzzle, tool inventory, or difficulty based on whether the player uses touch or has a slower device. Quality settings affect rendering only.

## Desktop and mobile controls

Desktop controls must support mouse selection and placement, number keys for tools, Space for pause, Escape for cancel or menu, and convenient camera pan and zoom. Scope shortcuts to the focused game and ignore them while the user types in a form. Always retain visible controls so keyboard memorization is optional.

Touch controls must support one-finger camera dragging, pinch zoom, generous target snapping, and the preview-and-confirm placement flow. Distinguish taps from drags so moving the camera does not spend a tool. Use pointer events, handle pointer cancellation, and avoid hover-only information. Restrict gesture capture to the game area so the host page remains usable.

Use touch controls of approximately 44 to 48 CSS pixels or larger. Tooltips and instructions must fit narrow viewports. Keep the selected tool, remaining charges, pause, cancel, and confirmation reachable without covering the active puzzle.

Support both portrait and landscape layouts. Landscape can be recommended for more room, but portrait must remain playable. Pan across large levels instead of shrinking every creature into an unreadable speck. Respect safe areas, dynamic viewport height, browser chrome, and device rotation.

Offer optional fullscreen with a visible exit, and a CSS theater-mode fallback when native fullscreen is unavailable. Start audio only after user interaction. Pause simulation and audio when the tab is hidden; resume only through an explicit player action. Do not fast-forward creatures through hazards after returning from another app.

## Interface and sound

Implement a polished title screen, New Run, Continue when available, tutorial/help, settings, in-game HUD, pause menu, level result, run result, and highscore display. The initial loading state needs real progress where measurable and a useful error state when assets or graphics initialization fail.

The HUD shows current level, biome, rescued/required creatures, remaining creatures, tools, speed, and pause. Run results prominently show levels completed and personal best. Explain why a run ended in a short readable sentence.

Provide English and German UI strings through a small, consistent translation structure. Use text and shape cues alongside color. Support keyboard focus, readable contrast, reduced motion, independent music/effects volume, and mute. Avoid screen shake or flashes that obscure puzzle state.

Add original or properly licensed audio with clear feedback for placement, invalid actions, rescued creatures, hazards, level completion, and run failure. Keep repeated creature sounds varied and quiet enough to avoid becoming irritating.

Do not place seeds, performance graphs, or iteration logs in the normal HUD. Put useful player settings in Settings and keep debugging details in a development overlay.

## Score and local persistence

The score is exactly the number of successfully completed levels in the current normal run. Example: reaching level 18 and failing it produces a score of 17. Do not count merely entered levels or combine unrelated statistics into an opaque weighted score.

Save the personal best locally using a versioned storage namespace. It must survive a page reload and must never decrease after a worse run. Keep practice, tutorial, debug skips, manually selected late levels, and reference-solution replays separate from normal results. Ensure that a level completion event increases the score exactly once.

Persist a resumable checkpoint after each cleared level and at safe pause/background boundaries. If resuming mid-level is supported, persist validated simulation state or reconstruct it from the seed and recorded actions. Otherwise clearly explain that Continue resumes the next uncleared level from the last completed checkpoint.

Handle corrupted or incompatible saves, unavailable or full storage, and private-browsing restrictions without crashing. Report when persistence is unavailable. A reload or duplicate completion event must not award the same level twice.

## Technical implementation

Use TypeScript and Three.js with reproducible dependencies and a lockfile. A small package with a straightforward build tool such as Vite is suitable. Keep editable source separate from generated output and document the actual startup/build workflow. Consult current official documentation for the installed renderer version.

Separate simulation, level definitions, generation/validation, rendering, input, UI, audio, and persistence with simple modules. Avoid building a general game engine or excessive abstractions.

Use a fixed simulation timestep, such as 60 ticks per second, with interpolated rendering. Prefer simple 2D collision data and integer or quantized state where it helps determinism. The same command stream must behave consistently across desktop and mobile. Keep rendering dependencies out of the headless simulation.

Keep logical collision and visual geometry in sync. Use pooled entities, shared materials, appropriate instancing, and spatial lookup for interactions. Keep normal crowd movement independent of a heavyweight 3D physics engine. Use a Web Worker or bounded scheduling for generation validation where needed.

Provide a WebGL rendering path suitable for supported desktop and mobile browsers. Do not require WebGPU. Detect unsupported graphics features and show a useful message. Dispose GPU resources, audio resources and event listeners when replacing levels or destroying the game. Recover from graphics context loss where practical.

All required assets and procedural content must be available locally. The game must not require runtime AI calls, remote asset generation, or a network connection once loaded.

## Performance and robustness targets

Target approximately 60 FPS on a typical modern desktop and a stable minimum near 30 FPS on a representative midrange phone, with automatic or selectable rendering quality. These are acceptance targets to measure on stated hardware, not numbers to claim without testing.

Cap internal render resolution, especially on high-DPI touch devices. Adjust resolution, shadows, particles, and postprocessing before compromising responsiveness. A starting touch-device pixel-density cap around 1.5 is reasonable; tune it from actual measurements and a total pixel budget.

Keep the initial compressed playable download near 10 MB or below if practical, and load later-biome art when needed. Report actual sizes and justified deviations. Avoid unnecessary network requests and expensive per-frame allocations. Long sessions must not accumulate old meshes, textures, handlers, audio nodes, or completed-level state without bounds.

Profile the maximum supported crowd and a late-game hazard combination. Report FPS or frame times, draw calls, and observable memory behavior where the tooling supports reliable measurement. Do not invent a hardware model or describe desktop emulation as a real phone test.

## Implementation sequence

Start with a short plan and establish the iteration log. Build one complete vertical slice: one attractive world, automatic creatures, representative tools, a clearable puzzle, failure, restart, and local personal best.

Playtest that slice. Add the shared deterministic simulation, module format, full-level reference-solution validation, remaining tools and worlds, and difficulty progression. Test the complete run loop as these pieces become available.

Finish touch behavior, persistence, audiovisual polish, and performance checks. These are delivery stages rather than predetermined iteration counts. Revise the game when tests expose defects. Do not replace required functionality with a roadmap or silently reduce the content minimums.

## Verification and local handoff

Provide exact startup/build commands and a working local browser URL. Verify a real interactive run, not only a screenshot of a menu.

- A new player can learn the controls, start a run, clear several generated levels, fail, and restart.
- All six tools preview and act correctly, consume the correct charges, and reject invalid actions without spending them.
- Every world and authored module can be inspected independently.
- The shared simulation validates generated candidates, and fallback generation is deliberately tested.
- Run a reproducible batch of at least 300 generated seed/level combinations across early, middle, and advanced bands, including levels 100 and 1000. Report rejection and fallback counts.
- Compare identical seeded action replays across different render rates and speed settings. Rendering quality must not change puzzle outcomes.
- Check quota failure, duplicate rescue/completion events, practice isolation, and score off-by-one cases.
- Personal best survives reload, a worse score cannot replace it, Continue works as described, and damaged or unavailable storage is handled.
- Test portrait near 360 x 800 and 390 x 844, landscape near 844 x 390, tablet and desktop near 1440 x 900. Controls must remain reachable and readable.
- Test touch dragging, pinch zoom, placement confirmation/cancel, rotation, fullscreen fallback, audio unlock, and background/resume.
- Use available browsers and devices. Identify which checks used real hardware or emulation, and state any unverified iOS Safari behavior.
- Test offline play after loading, a long sequence of level transitions, resource cleanup, and the maximum supported creature/hazard load.
- Verify the generated build, its asset URLs and console output.

Report actual performance and download size on identified test hardware. Do not invent measurements or describe desktop emulation as a real phone test.

## Creation iterations and revisions

Record actual creation iterations from the first draft. The initial draft counts as iteration 1. Each subsequent completed game revision round increments the game version and the recorded iteration count together, including fixes, visuals, controls, gameplay and score changes.

For ordinary revisions, use a minor-version increase, for example 0.3.0 to 0.4.0 while iteration 4 becomes 5. Multiple file edits, tool calls, tests and builds within the same round do not each add an iteration.

Maintain ITERATIONS.md with timestamps including a timezone, the reason for each round, changes and verification. Store known game version and creationIterations in authoring.json. Preserve actual records across resumed work; leave unknown historical information unknown.

The final handoff must explicitly state "Actual game creation iterations: N" and summarize each recorded round. If the earlier count cannot be verified, report that gap instead of inventing N.

## Deliverables

Deliver complete editable source, reproducible dependencies/build output, original or licensed assets, all world/module definitions, simulation/generation checks, and a concise README with exact local startup and build commands.

Include a guide for adding modules and worlds, ASSET_LICENSES.md, ITERATIONS.md, authoring.json with verified information, and a QA report with commands, results, viewports/devices, measurements and remaining limitations.

Provide actual gameplay screenshots of introductory and advanced levels and a mobile layout. In the handoff, give the local URL first, then startup instructions, implemented features, score/Continue behavior, verification results, actual iteration count and any remaining issues. The recipient must be able to open and play the game locally.

Local preview · built with GPT-6.1 Sol on Max.