The user wants a Temple Run-style endless runner game with a coin reward system where every "win" gives the user 20+ coins. Let me think about what this means: 1. A Temple Run-like game: an endless runner where the player character runs forward automatically, dodging obstacles, jumping, sliding, collecting coins. Typically 3-lane running with swipe/keyboard controls. 2. "For every win give the users 20+ coins" — I'll interpret "win" as completing a run / reaching distance milestones, or surviving a level. I'll add a coin system: coins collected during the run, plus a bonus of 20+ coins awarded each time the player "wins" (e.g., survives to complete a level — every 500m is a "zone cleared" win, or when they beat their best distance). I'll make it clear: every completed run / milestone gives a bonus of 20+ coins, with maybe a bonus chest animation. Technical approach: I could do this with Three.js for a real 3D Temple Run feel, or Canvas 2D with pseudo-3D perspective. Three.js via CDN would give a much more impressive result. Let me build a proper 3D endless runner: - Three.js scene: a running path/track through a jungle temple environment, 3 lanes - Player character: a stylized low-poly runner (built from boxes/capsules with running animation — arms/legs swinging) - Obstacles: barriers to jump over, overhead beams to slide under, full blockers to dodge sideways - Coins: spinning golden coins in lines/arcs - Controls: Arrow keys / WASD / swipe on touch — left/right lane switch, up = jump, down = slide - Camera: behind-the-shoulder chase camera - Score: distance + coins collected - Coin economy: persistent coin balance (localStorage), and "wins": every time the player survives to a checkpoint (e.g., every 400m = zone cleared) → +20 coins bonus popup; also on run end, if they beat their best distance → "NEW RECORD WIN" +25 coins. Actually let me define "win" clearly: completing a zone (checkpoint) counts as a win → +20 coins. Beating the high score → +30 coins. This satisfies "20+ coins". Wait — actually, maybe simpler interpretation: when the game ends (the run finishes), if they achieved something... Hmm. "for every win give the users 20+ coins" — I'll implement: each time you clear a zone gate (checkpoint at every 500m), you WIN that zone and get 20+ coins (20 + distance bonus). Plus game over screen shows coins earned. This creates the reward loop. Design considerations — I want to avoid the generic look. Let me think about visual identity: - Theme: ancient temple / jungle at dusk. Color palette: warm sandstone, deep teal-green jungle fog, gold coins, ember-orange accents. Avoid blue/purple defaults. - Fog for depth, warm hemisphere light, directional sun low on horizon. - Track: stone slab path with side walls/columns, occasional torches with flickering point lights? Point lights are expensive — maybe emissive torch flames without real lights, or 2-3 lights max. - Environment: procedurally recycled scenery chunks — trees, ruins, statues on the sides moving past. - UI: HUD with distance, coins, zone progress bar. Start screen with title treatment, game over screen with earnings breakdown. Use a distinctive font — maybe "Cinzel" for the temple/epic feel for titles and something like "Space Grotesk" or... for HUD numbers a mono-ish font. Google Fonts via CDN is fine. Let me use "Cinzel" (display, carved-stone feel) + "Rubik" or "Sora" for body. Cinzel fits the temple theme perfectly. Game mechanics detail: Lane system: 3 lanes at x = -2.2, 0, 2.2. Player lerps between lanes. Jump: parabolic y over ~0.55s. Slide: shrink collision box + character crouches for ~0.6s. Obstacles spawn ahead on the track, in patterns: 1. Low barrier (jump over) — stone log/fallen pillar spanning one lane or all lanes 2. Overhead beam (slide under) — hanging branch/stone lintel 3. Full block (must change lane) — tall stone wall/statue covering 1-2 lanes 4. Spike row maybe 5. Gaps in the floor? That's complex — skip or make simple: fire pit to jump. Pattern generation: every N meters spawn a pattern ensuring at least one survivable path. I'll generate patterns from a hand-authored set: e.g., "left+center blocked → go right", "low bar across all lanes → jump", "high bar across all → slide", mixed combos. This guarantees fairness. Coins: rows of 5-7 coins in a lane, sometimes arcs over jump obstacles. Coin = gold cylinder, rotating. Collect within radius → +1 coin, sound tick, floating "+1"? Maybe just a counter pulse. Speed increases gradually with distance. Collision: simple AABB in (laneIndex, y, z-space near player). Player z fixed conceptually — move world toward player instead of moving player forward (easier float precision). Actually typical approach: keep player at z≈0, move obstacles/scenery toward +z (camera behind at +z looking down -z). Let's set camera behind player at z = +6, looking toward -z. Obstacles spawn at z = -120 and move +z with speed. Remove when z > 12. Character: build from primitives — torso (rounded box), head, arms, legs with pivot animation. Running cycle: legs swing sin, arms opposite. Jump pose: legs tucked. Slide pose: torso pitched back/low. Add a scarf/cape? Maybe a little ponytail or scarf that flutters — a nice touch. Keep it low-poly stylized with flat shading. Environment chunks: track segments of length ~30m recycled: floor slabs, side walls with columns every few meters, occasional torch, palm trees / jungle foliage blobs, ruined statues. Use InstancedMesh where possible for perf, or just merged simple geometry with modest counts. Simpler: create a pool of segment groups, recycle. Sky: gradient via large sphere with vertex-color-ish shader or just scene background color + fog. I'll use a big dome with a custom shader gradient (dusk: deep teal top → warm amber horizon). Fog color matches horizon. Signature moment: the "ZONE WIN" gate — a big temple archway/gate spanning the track every 500m; passing through it triggers a burst: golden particle shower, gate glows, "+20 COINS" carved banner flies up, chime sound, brief slow-mo? Maybe a quick time-scale dip and camera FOV pulse. That's memorable. Also coin magnet? Keep scope reasonable. Audio: WebAudio-generated sounds (no external assets): coin tick (short sine blip), jump whoosh (noise sweep), crash (low thud), win chime (arpeggio). All synthesized locally. Persistence: localStorage for total coin bank "templeCoins" and best distance. Show bank on start screen with a coin vault. "For every win 20+ coins" — I'll show on start screen: "Clear a zone gate → WIN 20+ coins". Let me also handle: pause (Esc / P), restart button, mobile touch swipes. Performance: keep draw calls moderate. Use MeshLambertMaterial / MeshStandardMaterial? Lambert is cheaper and fits flat stylized look with flatShading. Use one directional light + hemisphere light. Shadows: maybe just a fake blob shadow under player (dark circle) — cheaper and reliable. Could enable renderer shadows for player only... blob shadow is fine and stylish. Resolution scaling: renderer pixel ratio min(devicePixelRatio, 2). Now UI/HUD design: - Top-left: distance meter (big numeral, meters) with a thin zone progress bar beneath showing progress to next gate with a gate icon at the end. - Top-right: coin count with small coin icon (SVG inline, not emoji), animated pulse on collect. - Center flash messages: "ZONE CLEARED +20 COINS", "NEW BEST!". - Bottom hint on start: controls. - Start overlay: Title "TEMPLE DASH" — hmm, name it something. "EMBERGATE"? "SUNKEN RUN"? Let's call it "GILDED RUN — Temple of the Ember Gate"? Keep simpler: "EMBER TEMPLE RUN"? Avoid trademark-ish; call it "RELIC RUSH" or "TEMPLE OF EMBERS". I'll go with "RELIC RUNNER" — nah, generic. "EMBERGATE" is distinctive: the win gates are ember-lit archways. Title: EMBERGATE — subtitle "a temple run". Good. Icons: I should use an icon library or inline SVG rather than emoji. Inline SVG is cleanest for a single file (coin icon, arrows). I'll hand-draw a few tiny SVGs (coin, trophy/gate, arrows for controls). That avoids CDN icon lib dependency, though using one is allowed. Inline SVG it is. Fonts: Google Fonts link: Cinzel (700/900) + something like "Outfit" or "Sora" for UI. I'll use "Sora" (geometric, not overused-default). Actually numbers look great in Cinzel too for the title, but HUD numbers need tabular feel — Sora fine. Color system: - Background/fog: deep jungle dusk — #10231e / horizon amber #e8863a... Let me define: sky top #0d2b26 (deep teal-green), horizon #f2a45c (amber). Fog color ~ #1c3a33 blending... Hmm, fog should blend to horizon-ish; I'll pick fog #274b41 or warm dusk #6e5340? Let me test mentally: warm dusk fog #b06a3f might wash everything orange; a misty green-teal #2e5548 feels jungle. I'll use fog color #35594d and make sky shader go teal→amber at very low horizon so distant objects fade into teal-green mist with amber rim near ground line. Fog color #3a5f50. - Stone: sandstone #c9a86a, darker #8a6f45. - Accents: ember orange #ff7a3c for torches/gate glow, gold #ffcf5c for coins. - UI: parchment/ivory text #f4e8cf on translucent dark panels rgba(10,20,17,.72), hairline borders rgba(255,210,140,.25). HUD shouldn't look like a dashboard — keep it minimal: big distance numeral top-center or top-left with fine labels; coin counter top-right. Zone progress as a thin ruler under the distance. Fine. Game over overlay: "THE TEMPLE CLAIMS YOU" style — stats: distance, coins collected, zone wins, total earned, bank. Buttons: RUN AGAIN. All wired. Win logic recap: - Zone gates every 500m. Passing gate = WIN: +20 coins base + 2 coins per 100m of zone? So zone 1 → 20, deeper zones give more (20 + 5×zoneIndex?) — "20+" satisfied: bonus = 20 + zone×5. Show "+25 COINS · ZONE 2 CLEARED". - New best distance at run end → +30 "RECORD BONUS". - All coins added to persistent bank. Also maybe smaller "win": collecting every coin in a row? Skip. Now, code structure (single HTML file): ```html meta, title Google fonts link (Cinzel, Sora)

(or renderer appends) HUD elements overlays (start, gameover, pause) toast layer

``` Three.js CDN: use https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js (r128 is a classic global-script version, widely cached). Or unpkg three@0.128.0/build/three.min.js. cdnjs r128 is reliable. I'll use cdnjs. Note: r128 uses THREE.Geometry removal? r128 still has BufferGeometry standard; fine. flatShading available on materials. OK. Let me now carefully design the code. ### Constants & state ```js const LANES = [-2.3, 0, 2.3]; const BASE_SPEED = 14; // units/sec const MAX_SPEED = 30; const GATE_SPACING = 500; // meters ``` Distance mapping: 1 world unit = 1 meter. Speed units/sec = m/s, starts 14 (~fast), ramps +0.35 per second up to max? Or ramp with distance: speed = min(MAX, 14 + dist*0.02). At 800m → 30. Good. World scroll: obstacles & scenery have worldZ decreasing... Let's store objects with `z` position; each frame z += speed*dt; mesh.position.z = z. Spawn at z = -140. Player at z=0. Camera at (0, 4.6, 7.5) looking at (0, 1.6, -8) roughly, with slight lateral follow of player x * 0.4 and slight tilt — adds life. ### Scene setup ```js renderer = new THREE.WebGLRenderer({antialias:true}); renderer.setPixelRatio(Math.min(devicePixelRatio,2)); renderer.outputEncoding = THREE.sRGBEncoding; // r128 supports scene.fog = new THREE.Fog(0x35594d, 30, 130); scene.background = null; we use sky dome mesh (fog:false material) ``` Sky dome: SphereGeometry(300, 16, 12) with ShaderMaterial: ```glsl varying vec3 vPos; // fragment: float h = normalize(vPos).y; vec3 top = #12312b; horizon warm = #e8934f; mid teal #3a5f50 color = mix(horizon, mid, smoothstep(0.0,0.25,h)); color = mix(color, top, smoothstep(0.25,0.7,h)); ``` Also a big sun disc: add emissive circle sprite near horizon — a mesh circle at far -z with basic material, fog false, color #ffd9a0, plus glow ring? Keep subtle. Add a few distant silhouette mountains? The fog handles depth; skip mountains, maybe dark temple silhouette far ahead is nice — a large dark shape at z=-125 that never moves (since fog would hide at 130... fog far 130, silhouettes barely visible). Skip; keep dome + sun. Lights: - HemisphereLight(0xfff2d8 sky, 0x2e4a3c ground, 0.85) - DirectionalLight(0xffb36b, 0.9) from (-6, 9, -4)? Sun ahead-left gives rim. Position (-5, 8, -6), target origin. - Maybe subtle DirectionalLight fill from behind camera (0x9fd8c0, 0.25). Materials: MeshLambertMaterial mostly; flatShading true on low-poly rocks. ### Track & scenery chunks Chunk length L = 24. Pool of chunks covering z from +24 down to -168 → about 9 chunks. Each chunk group contains: - Floor: box (width 8.4, height 0.4, depth L) sandstone color; plus per-chunk random slab tint variation — use 2-3 floor slabs per chunk alternating shades to fake slab rhythm. Actually simpler: one floor box + thin darker "seam" strips every 4m: could do 6 thin boxes on top. Fine, cheap. - Side walls: low stone curb (0.35 h) along both edges + columns every 8m: column = box(0.6, 3.2, 0.6) at x=±4.6, with capital box on top. Occasionally broken (random height). - Beyond columns: jungle — random dark-green cones/icosahedron blobs (trees) at x ±(6..14), plus palm-ish: trunk cylinder + 4-5 flattened cone leaves. Keep each tree ~3-5 meshes... With 9 chunks × maybe 6 trees × 4 meshes = 216 meshes; plus columns etc. Total maybe 500-700 draw calls — that's heavy-ish but Three can handle simple materials fine on desktop; mobile might chug. Optimization: merge static geometry per chunk using BufferGeometryUtils? r128 has BufferGeometryUtils as separate file (examples/js/utils/BufferGeometryUtils.js). I can include that CDN too, and merge each chunk's floor+columns into 1-2 geometries with vertex colors. That's real craft but adds complexity. Alternative: use fewer meshes and InstancedMesh for trees across all chunks. Simplest performant approach: build everything with vertex-colored merged geometry manually — I can write a tiny merge helper: create geometries, apply matrix, set color attribute, merge into one BufferGeometry per chunk, one material with vertexColors:true. In r128, geometry.merge isn't available on BufferGeometry without utils; but I can implement merge by concatenating position/normal/color arrays of non-indexed geometries (use .toNonIndexed()). That's ~20 lines. This gives 1 draw call per chunk for static stuff. Trees also merged in. Torch flames animated separately (few). Actually — I'll write helper: ```js function boxGeo(w,h,d){ return new THREE.BoxGeometry(w,h,d).toNonIndexed(); } function coloredGeo(geo, color){ add 'color' attr filled with color rgb per vertex; return geo } function mergeGeos(list){ concat positions/normals/colors into one BufferGeometry } function addBox(list, w,h,d, x,y,z, color, ry=0, sx..) { create geo, rotate, translate, colorize, push } ``` Chunk builder uses addBox for floor slabs, curbs, columns, tree trunks (cylinder → I can approximate with boxes or use CylinderGeometry toNonIndexed — fine, use cylinders and cones too). Then each chunk = new THREE.Mesh(mergedGeo, vertexColorLambert). One material shared. Torch flames: separate small meshes (cone, emissive orange) with flicker scale — one per chunk occasionally, 2-3 flames total alive; flicker via scale/intensity of a single PointLight that follows the nearest torch? Simpler: flames are just emissive meshes with slight scale pulsing; plus add 1 PointLight attached near player path that pulses warm — subtle. Might skip point light for perf; emissive + bloom-ish? No postprocessing. Emissive orange cones read fine. Recycling: chunk z += speed*dt; when chunk.z > 24 (its far edge passes camera), chunk.position.z -= 9*L... wait chunks positioned at z = -i*L. Move group.position.z += speed*dt; when position.z - L/2 > 30 → position.z -= 9*24 (total span) and optionally rebuild randomness? Rebuilding geometry is costly; keep same content but shuffle tree placements? Static is fine — variation across 9 chunks is enough that recycling isn't noticeable. Actually with only 9 chunks cycling, player might notice repetition every ~200m. Mitigate: build 12 chunks (span 288m) and add random rotation/mirror on recycle? Mirroring via scale.x = -1 flips geometry — with vertex colors & Lambert fine (normals flip — need side handling... negative scale flips winding; Three handles with material side? It can cause inside-out lighting. Use scale.x = ±1 and material side: FrontSide might cull wrongly... Actually Three.js handles negative scale by flipping? It doesn't automatically fix winding; meshes appear inverted. Safer: rebuild only tree decoration layer as separate merged mesh per chunk so we can regen trees cheaply on recycle: chunk = { baseMesh (floor+columns, static), decoMesh (trees, rebuilt on recycle) }. Rebuilding deco merge of ~8 trees occasionally is cheap. Coin bob/rotation animation each frame for active coins. ### Player character Group `player` at (laneX, y, 0). Sub-parts: - torso: box(0.7,0.85,0.45) color ivory shirt #e8dcc0 with strap? Add belt. - head: box(0.5,0.5,0.5) skin #d9a066 + hair cap dark + tiny ponytail box that rotates with run bounce. - arms: 2 groups pivoted at shoulder (±0.45, 1.5): arm box(0.22,0.7,0.22) offset y-0.35. Skin + sleeve color. - legs: 2 groups pivoted at hip (±0.2, 0.95): leg box(0.26,0.85,0.26) offset -0.42, color pants #6b4a2f, feet small box gold-ish boots. - scarf: red/orange #ff7a3c plane/box trailing behind neck — flutter animation: rotate with sin + speed. Signature detail! Run cycle: t = time * (speed factor). legL.rotation.x = sin(t)*0.9; legR = -; armL = -sin*0.7; armR opposite; torso slight lean forward rot.x = 0.12 + sin(2t)*0.03; whole player y bounce = |sin(t)|*0.08. Jump: vy physics: on jump vy=9.2, gravity -26; while airborne legs tuck (lerp to fixed pose). Land: small squash (scale y 0.9 for 80ms). Slide: duration 0.65s; torso rot.x → -1.1 (lean back) and lower y, legs forward; scale/pose lerp. Hitbox height reduces 1.7→0.8. Blob shadow: circle mesh (CircleGeometry, black 0.35 opacity) at y=0.02 under player, scales smaller when airborne, follows lane x. Dust particles at feet when grounded & running: small puffs (sprite-like planes) — could do simple: a few planes with opacity fading, spawn every 90ms. Nice polish. Implement tiny pool of 12 puff meshes (circle geo, additive? no—normal transparent, color sandstone). Spawn at feet, drift up-back, fade. Coins: gold cylinder radius 0.32, height 0.08, rotated to face player (rotation.z? cylinder axis y; want coin standing facing camera → rotate x by 90° so axis points along z... standing coin: axis along z? A coin standing upright facing the player: its flat faces face ±z → cylinder axis along z: rotation.x = Math.PI/2. Then spin around its own axis: rotate around world y → set mesh.rotation.y? If geometry axis along z after x-rotation, spinning like Temple Run coins = rotate around vertical world axis: put coin mesh (rot.x=π/2) inside a parent group and rotate group.rotation.y. Simpler: mesh.rotation.set(Math.PI/2, 0, 0) then each frame mesh.rotation.z += ... hmm rotations order XYZ: rotation.x=π/2 then increasing rotation.y rotates around object's local y which after x-rot points along world -z → spins the coin about z-axis world → looks like spinning around horizontal axis = flipping. Not what we want. Use parent group: group.rotation.y += 3*dt; child mesh rotation.x = π/2. Good. Material: MeshStandardMaterial? Lambert emissive: color #ffcf5c emissive #7a4a00 * small. Add point? no. Also a subtle rim: torus? overkill. Add emissive intensity so coins pop in fog: emissive #b26a1a with lambert (emissive works on Lambert). Good. Obstacle meshes: - Low barrier "fallen pillar": cylinder lying across lane(s): cylinder r=0.55 length 2.0 rotated z=π/2, plus broken ends. Jumpable (needs jump). Color sandstone dark with moss? add moss cap boxes green. - Overhead "stone lintel/branch": box spanning lane at y 1.55..2.3 with hanging vines (thin green boxes dangling) → slide under. Occupies y from ~1.35 up. - Tall block "statue/wall": box 1.9w × 2.6h × 0.8 sitting on lane, can't jump (too tall) → must dodge. Style as ruined idol: stack of boxes + head. Or a spiky log wall. Make it clearly solid. - Fire pit: low wide box with emissive flame cones → jump. Variant of low barrier with flames — reuse low class with flame deco. - Full-width low bar? full-width low barrier across all 3 lanes (jump), full-width overhead (slide). Keep lane-based mostly. Pattern definitions (each: list of {lane, type} plus coins). Ensure solvable: I'll hand-author: ``` P1: low bar center only → coins arc over it in center lane P2: tall left+center → survive right, coins right line P3: overhead all lanes → slide, coins low line center P4: low all lanes → jump, coin arc center P5: tall left, low center → right open / jump center P6: tall right, tall center → left open P7: overhead center + low left → right open or slide center P8: zigzag: tall left at z, tall right at z-8 (sequential) → weave P9: coin shower only, no obstacle (breather) ``` Spawner: next pattern scheduled at distance intervals that shrink with speed (min gap ensures reaction time). Gap meters between patterns: base 26 + speed*0.6? As speed rises keep time-gap ~constant: gap = speed * 1.15 (≈1.1s between patterns) with variance. Coins fill gaps sometimes. Coin rows: line of 5 coins spaced 1.6m in a lane; arc: 5 coins y = jump parabola matching obstacle. Place coins as objects with z, lane, y; move & recycle. Obstacle/coin object pool: arrays `active` with {mesh, type, lane, z, ...}; meshes pre-built per type pool or create/dispose (creation cheap since shared geometries/materials — just new Mesh). Use shared geometry & materials; new Mesh per spawn, remove on pass. Fine. Collision detection: for each obstacle with |z| < depth threshold: if obstacle.z > -1.0 && obstacle.z < 1.0 (player depth ~1.0) and lane matches player's current lane (use rounded x within 0.8) then check vertical: low bar: collide if playerY < 0.9 (not high enough); overhead: collide if not sliding (playerTop > 1.35 → if !sliding); tall: always collide. On collide → crash sequence: slow-mo, character tumble, camera shake, then game over overlay after 900ms. Also near-miss detection? skip. Lane switching: targetLane; player.x lerp with speed 12/s or exponential smoothing x += (target-x)*min(1,dt*12). Add slight z-rotation tilt while switching (bank) and scarf flare. Input: keydown: ArrowLeft/A → lane-1; Right/D → +1; Up/W/Space → jump; Down/S → slide (if airborne → fast-fall slam to slide on land? nice: down in air → vy = -20 and queue slide). Touch: track touchstart/touchend delta; swipe threshold 30px; direction by dominant axis. Also tap = jump? Tap (small delta) → jump. Buttons? no. Pause: Esc/P toggles overlay; also auto-pause on blur. ### Zones & wins distance += speed*dt. nextGateDist starts 500. Gate visuals: an archway object spanning track at spawn position corresponding to z where it will be when player crosses: since world moves, spawn gate at z = -(nextGateDist - distance) roughly (i.e., place so it reaches 0 exactly when distance hits gate distance). Spawn gate early: when remaining = distanceToGate < 150 → spawn at z = -(distToGate). Each frame gates z += speed*dt. When gate.z >= 0 → WIN: bonus = 20 + zoneIndex*5; coins += bonus; flash "ZONE N CLEARED"; particle burst; chime; save bank. Gate mesh: two pillars + arch top spanning all lanes, ember braziers on pillars (emissive), banner plane with texture? Text via canvas texture "500m"? Could do CanvasTexture with "ZONE 1" — nice touch. Make banner canvas texture per gate (cheap, few gates). Gate passes by; remove at z>15. Win particles: burst of ~40 gold shards (small tetrahedron/plane meshes) from gate top, physics scatter, fade. Pool them. Also each gate pass → speed +1.5 nudge & maybe new deco palette slightly? Keep speed ramp formula-based. First-time hint: after start, show "swipe / arrows to dodge — jump ▲ slide ▼" fading after 4s. No emoji — use SVG chevrons or text. ### Game over flow On crash: - state = 'crashed'; crash time; player tumble animation (rotation.x += , fly back slightly, fall); camera shake 0.5s; speed → 0 over 0.3s? World stops quickly (speed lerp to 0 fast). After 1.1s show overlay. - Compute earned this run: coinsCollected + zoneBonuses + recordBonus(if best beaten: +30). - Show breakdown table; bank += earned; localStorage. - Buttons: RUN AGAIN (restart immediately), also show best distance. Persist bank under key 'embergate.bank', best 'embergate.best'. Guard localStorage in try/catch (sandboxed iframes may throw). ### Audio (WebAudio synth) ```js AC = new (AudioContext)(); master gain 0.35. coin(): osc sine 880→1320 quick, gain env 0.15 exp decay 0.12s + tiny square blip. Alternate pitch per combo? Simple two-tone ping. jump(): noise buffer through bandpass sweep up? simpler: osc triangle 300→600, 0.15s. slide(): filtered noise short low. crash(): osc saw 160→60 0.4s + noise burst. win(): arpeggio 3 notes (523,659,784) staggered sine, + shimmer. step sounds? skip. ``` Create noise buffer once. Resume context on first user gesture. ### HUD layout & CSS - font stacks: `--font-display:'Cinzel', serif; --font-ui:'Sora', sans-serif`. - HUD top bar: left cluster: "DISTANCE" microlabel + big number (Sora 600, tabular-nums) "0m", zone progress ruler: thin 140px line with tick marks and a small gate glyph at end that fills. Right cluster: coin SVG (gold disc with inner ring) + count. On collect: count scales pop (CSS class w/ transition, remove on animationend). - Center message layer: big Cinzel text with letter-spacing, amber, text-shadow subtle dark (no glow — use solid offset shadow / dark outline only for legibility; avoid glow effect. A slight dark drop for contrast is fine, not a glow). - Overlays: dark translucent panel, thin gold hairline border, carved feel via double border? Use border + inset outline offset. Title in Cinzel 700 with wide tracking, ivory; small rule ornament (SVG diamond line). Buttons: solid ember/ivory? Button style: transparent bg, 1px gold border, ivory text, hover fill gold with dark text — restrained. Primary button: gold fill (#e8b45a) dark text. - Controls legend: row of key caps (styled kbd) + labels: ◀ ▶ dodge (use SVG arrows or characters? characters ◀ are fine—they're glyphs not emoji; better small inline SVGs). I'll use small inline SVG chevrons for polish. - Vignette: radial-gradient overlay? That's a gradient... a subtle dark vignette is legitimate photographic treatment, not a decorative gradient banner. I'll keep a very subtle vignette for focus. Hmm, I prefer to be careful: a barely-there vignette via radial gradient black transparent is craft, not "gradient decoration". Keep it extremely subtle (0.35 alpha edges). Also film grain? skip. Coins SVG icon: circle with inner circle + notch, gold stroke. Mobile: media queries shrink HUD; tap zones? swipes cover it. Add "fullscreen"? skip. ### Scoring pacing - distance meter: Math.floor. - speed = min(MAX, 14 + distance*0.018 + zone*0.5?) — simple: 14 + dist*0.018 → at 890m hits 30. plus small jump each gate? formula fine. ### Crash fairness Reaction: obstacle visible from z=-130 with fog starting 30... fog near 30 fully clear to 130. Spawn at -120, becomes clearly visible ~-60 → at speed 30 that's 2s. OK. Fog far maybe 120; spawn -125 hidden then emerge. Fairness in patterns: ensure no pattern requires lane change + jump same instant; gap between sub-rows ≥ 8m at low speed... distances scale with speed: subGap = max(8, speed*0.55). I'll compute pattern spacing in meters scaled: patterns defined in lane/z offsets multiplied by gapScale = clamp(speed/16,1,1.8)? Simpler: define patterns with relative dz units; spawn converts dz*speedScale where speedScale = speed/16. Keep simple: dz base 7, scaled. Let me also add coin magnet pickup? Scope control — no. ### Detailed geometry helper ```js const _tmpMat4 = ... function pushGeo(arr, geo, color, x,y,z, rx,ry,rz, sx=1,sy=1,sz=1){ geo.applyMatrix4(compose)... } ``` Implementation: ```js function addPart(parts, geo, hex, x=0,y=0,z=0, rx=0,ry=0,rz=0, s=1){ const g = geo.toNonIndexed ? geo : geo; // ensure nonindexed const gg = geo.index ? geo.toNonIndexed() : geo.clone(); const m = new THREE.Matrix4(); const q = new THREE.Quaternion().setFromEuler(new THREE.Euler(rx,ry,rz)); m.compose(new THREE.Vector3(x,y,z), q, new THREE.Vector3(s,typeof s==='number'?s:s, ...)) ``` I'll pass scale as single number or array. Then color attribute: ```js const c = new THREE.Color(hex); const n = gg.attributes.position.count; const col = new Float32Array(n*3); for(i...) col set c.r,g,b gg.setAttribute('color', new BufferAttribute(col,3)); parts.push(gg); } function mergeParts(parts){ concat position, normal, color arrays → BufferGeometry } ``` Normals: after applyMatrix4 with rotation, need normals transformed — applyMatrix4 on geometry updates normals automatically (BufferGeometry.applyMatrix4 handles normal matrix). Yes, r128 BufferGeometry.applyMatrix4 transforms normals. Good — so apply matrix to geometry (position+normal), then set color attr. Use gg.applyMatrix4(m). Watch memory: clone geometries each call then discard — fine at build time; dispose merged sources? They're garbage collected; also call gg.dispose()? Non-indexed clones of primitives — okay to dispose after merge to free GPU? They were never uploaded (no mesh) so just JS GC. Fine. Geometries to reuse: define once: BOX = new BoxGeometry(1,1,1), CYL = CylinderGeometry(1,1,1,7), CONE = ConeGeometry(1,1,6), ICO = IcosahedronGeometry(1,0), etc. Then addPart(..., geo) but must clone & scale via matrix scale (s params) — using unit geos with scale params. toNonIndexed for BOX (indexed by default? BoxGeometry is indexed). Cylinder/Cone indexed. So in addPart: `const gg = geo.index ? geo.toNonIndexed() : geo.clone()`. toNonIndexed returns new geometry — good, original untouched. If non-indexed (Icosahedron detail 0 is non-indexed) → clone(). Merged chunk stats: each chunk maybe 60 parts × 36 verts avg = ~2k verts. Trivial. Vertex colors + Lambert with white material color: `new THREE.MeshLambertMaterial({vertexColors:true})`. Lighting will shade. FlatShading option for Lambert in r128? Lambert is per-vertex (Gouraud); flat shading needs flatShading:true — supported via material.flatShading? Lambert historically didn't support flatShading until later versions? In r128 MeshLambertMaterial ignores flatShading I think (it's vertex-lit). MeshPhongMaterial supports flatShading. For low-poly facets, MeshPhongMaterial({flatShading:true, shininess:0, specular:0x000000, vertexColors:true}) ≈ lambert flat. Or MeshStandardMaterial flatShading with roughness 1 — costs more but fine. I'll use MeshPhongMaterial specular black for chunk world; looks like flat lambert. Good. Player character: use separate small meshes with Phong flat + distinct colors, easy anim. ### Scenery content per chunk (L=24) Ground base: main slab box(9, 0.5, 24) top at y=0 → center y=-0.25, color varies slightly per chunk (#b98d55 base; jitter ±). Side dirt: wider thin box(16,0.3,24) at y=-0.4 color dark jungle floor #3c4a2c? Actually sides beyond path: make jungle ground slightly lower & darker: box(30, 0.4, 24) y=-0.45 #2f4433. Slab seams: 5 cross strips box(9.2, 0.06, 0.5) y=0.01 z=-12+i*4.8... wait chunk-local z from -12..12: strips at z=-9,-3,3,9? spacing 6? do z=-8,0,8? Let's spacing 4: -10,-6,-2,2,6,10 → 6 strips color darker #8a6238. Curbs: box(0.5,0.5,24) at x=±4.5 y=0.2 color #7c5c34, plus top thin lighter. Columns: at z = -8, 0, 8 (3 per side): x=±5.4; shaft box(0.7, h, 0.7) h=2.6+rand*1.4, y=h/2; capital box(1.0,0.3,1.0) on top; 20% chance broken (no capital, shorter). color #a8834f shaft, capital #b8905a. Wall fragments behind columns occasionally: box(2.2, 1.8, 0.5) at x=±6.2 some z. Torches: 40% per chunk: pole box(0.14,1.6,0.14) at curb top (x=±4.5,y=1.0? on top of curb y 0.45+0.7), bowl cone inverted? flame handled separately as animated mesh: store flameMeshes list on chunk with local positions; flame = cone(0.16,0.5) emissive material (MeshBasicMaterial color #ffb347? Basic ignores fog? Basic respects fog by default fog:true). Flicker: scale.y = 0.8+0.35*noise, and swap color intensity. Trees: N=5-9 per chunk per side? Budget: positions x ±(7..16), z random in [-11,11]; types: - palm: trunk = cylinder r0.14 h2.5-3.6 slight tilt; leaves: 5 cones flattened (scale z? cone radius 0.9 height 0.35) rotated around top, color greens (#3f6b3a, #4c7a3f, #2f5b33). - blob tree: trunk cylinder + 2 icosahedron blobs (r 0.9-1.4) stacked. - fern: 3 small cones. Since deco layer rebuilt on recycle, keep tree count modest (8/chunk). Also occasional ruins: tilted broken column, stone ring? A big idle "head" statue far side rarely: box stack with face? Keep: broken column + fallen slab. Deco merged into one mesh per chunk (trees etc.), base merged (floor, columns, curbs, torch poles). Torch flames separate array. Chunk recycle: when group.position.z > 28 (fully behind cam at z≈7.5+margin), group.position.z -= CHUNK_COUNT*L; rebuild deco: dispose old deco geometry, build new parts, new mesh. To reduce hiccups, rebuild is small (8 trees × ~7 parts). Fine. Initial placement: chunks i=0..11, z = 12 - i*L (front edge ahead). Let's define group z meaning center: chunk i center z = 12 - L/2 - i*L... simpler: place centers at z = -i*L for i=0..11 then shift all +L*? We need coverage from behind camera (+14) to far (-140). With 12 chunks × 24 = 288 → centers from +14-12= ... set centers z_i = 14 - 12 - i*24 → i=0: +2? Let me just do centers at z = 12 - 24*i, i=0..11 → i=0 center 12 (covers 0..24 behind cam? camera at 7.5 so covers up to 24 behind ok), i=11 center = -252? That's way past fog 130 — wasteful but fine (hidden by fog, still drawn). Reduce to 8 chunks (192 span): centers 12 - 24i, i=0..7 → farthest covers -168..-192; fog far 130 → last visible chunk boundary -130 covered by chunk i≈5.9... need coverage to -130+some: 7 chunks (168): centers 12..-156, covers -144..-168 lowest. Coverage continuous from +24 down to -156. Fog far 130 — good with 7-8 chunks. Use 8. Recycle when center z - ? When chunk center z > 24+12=... its front edge (z+12) beyond camera 7.5 + margin → when center > 20? center 20 means near edge 32, far edge 8 — chunk still visible at z 8 behind player? Player at 0, camera 7.5; chunk far edge at center-12: if center=20 → far edge 8 > 7.5 → still slightly visible behind camera? Camera at 7.5 looking -z; objects at z>7.5 behind camera not visible. So recycle when center - 12 > 8 → center > 20. Then z -= 8*24=192. ### Coins & obstacles movement Everything in `movers` array with update: z += speed*dt; if z > 14 → despawn. Obstacle spawn scheduling: `nextObstacleZ` as remaining meters: use distance-based: `spawnDist` — track `distToNextObstacle`; each frame distToNextObstacle -= speed*dt; when ≤0 → spawnPattern() and set distToNextObstacle = gap(speed). Spawned objects placed at z = -SPAWN_Z (=-125) minus intra-pattern offsets. But gate timing uses distance too — consistent since world speed uniform. Coins scheduling similar with own timer; coin arcs attached to some patterns. Pattern spawn implementation: choose pattern function from list (weighted, avoid repeat same twice). Each pattern adds obstacles via `addObstacle(type, lane, dzOffset)` where actual z = -125 - dzOffset*scale... Wait obstacles further along should be more negative: offset increases distance ahead → z = -125 - off. Hmm but then they'd spawn beyond spawn plane; fine (they're just numbers; fog hides). Or spawn base nearer: place pattern start at -125 with later items more negative. Despawn at z>14. OK. Vertical positions: low barrier: cylinder r 0.55 center y 0.55 → top 1.1; jump apex: vy 9.4, g 26 → apex = vy²/2g = 88/52 ≈ 1.7, airtime 0.72s, horizontal at speed 20 = 14.5m — jump distance generous. Player cleared if y > 0.95 when crossing. Overhead lintel: bottom edge y=1.4; player standing top = 1.85 (head at ~1.55+0.25). Slide height 0.85 → cleared. Collide overhead if !sliding and playerY < 1.2? If jumping into it also collide (y bottom of lintel 1.4, jumping raises player but top up to ~1.55+1.7... collide if !sliding basically, but if player jumps early and is above? Lintel occupies 1.4→2.4; jumping player passes through that band → collide unless sliding. So rule: if !sliding → hit. Even mid-air. OK but feel unfair? It's classic — slide only. Fine, mark visually with hanging vines. Tall block height 2.6 > jump apex+height → can't clear: collide always when lane matches. Also "gap in floor"? skip. Collision z-window: obstacle has depth d (e.g., 0.9). Check overlap: |obs.z - player.z(0)| < (d/2 + 0.35). Lane match: |obs.x - player.x| < 1.0. Player y: manage py, vy. sliding timer. During slide hitbox low. Now think about coin collection: coin at (laneX, y=0.55 or arc up to 2.0), collect if |z|<0.9 && |x diff|<0.9 && |playerCenterY - coinY| < 1.0 (player center y = py + 0.9). Generous. Coin count UI += 1 per coin; runCoins counter. ### Gate details Gate object: group with two pillars box(0.8, 4.4, 0.8) at x=±4.4, arch top box(10,0.9,1.0) y 4.6, plus center keystone, two brazier bowls with flames (animated like torch), banner plane (2.2×1.2) at y 3.1 center with CanvasTexture text "ZONE n" ivory on dark with border. Pillar color dark stone #6e5636, ember brazier emissive. Gate added to movers with type 'gate'; when gate.z crosses 0 (prev<0, now≥0) → triggerWin(zoneIndex). Since gates spaced 500m and speed ≤30, plenty of room; only one gate active at a time mostly. Win burst: spawn particles at gate position (x0,y4.6,z0) → 36 shards: small tetra (ConeGeometry? use PlaneGeometry 0.12 or TetrahedronGeometry(0.12)) gold material basic color #ffd977; velocity random up/out; gravity; life 1s fade via material opacity — need per-particle material clone or use vertexColors... simple: shared geometry, material per particle clone (36 mats fine) or set transparent with opacity per mesh material clone. OK. Also small coin fly-to-HUD animation? DOM: spawn absolutely-positioned gold dot that transitions to coin counter. That's slick & cheap: for win, 5 dots staggered; for coin collect, skip (too many). Nice touch on win + record. Slow-mo on win: timeScale = 0.35 for 0.4s then ease back. Implement global timeScale multiply dt. Camera FOV pulse: fov 62→70→62 quick? subtle: on win fov +6 decay. ### Camera juice - cam.x = player.x*0.55 smoothed; cam.y = 4.4 + jump*0.25? slight; lookAt(player.x*0.7, 1.4, -10). - Running shake: tiny y bob sin(t*2)*0.05. - Crash shake: random offsets decaying. ### Start state Idle scene: world slowly drifts (speed 6) with player running in place — cinematic behind-title. Overlay with title; PRESS to start (button "BEGIN THE RUN" + key Enter/Space). On start: reset distances, hide overlay, speed ramps. Restart resets movers, chunk positions? Keep chunks cycling (they're ambient). Clear obstacles/coins/gates/particles; reset distance/nextGate/speed/player pose/lane. ### Persistence & bank UI Bank shown on start & game-over: coin icon + amount, with label "COIN VAULT". Wins counter maybe "gates cleared lifetime"? Add stat: total wins stored. Show "WINS: n → each pays 20+". Keep minimal: vault coins + best distance on start overlay. Edge: localStorage may throw in sandboxed iframe — wrap. ### Sounds detail ```js function beep({type='sine',f0,f1,t=0.15,g=0.2,delay=0}) osc + gain env exp ramp. coin: f 1046→1568 two quick? Use two oscs: sine 1318 (E6) 0.09s + slight second at delay 0.06 f 1760. gain 0.12. jump: triangle 250→520 0.18 g0.15. slide: noise burst lowpass 400, 0.25 g 0.12. hit: sawtooth 150→55 0.5 g0.4 + noise 0.3. win: notes [659, 831, 988, 1319] staggered 0.09, sine, g0.18, 0.35s decay + high shimmer triangle 2637 quiet. record: extra fanfare. ``` Noise: create 1s buffer white noise once. Mute toggle button in HUD (small speaker SVG) — nice. Store pref. ### HTML skeleton ```

DISTANCE label, #dist value, zone ruler (#zoneFill), #zoneLabel "ZONE 1 · 500m"

mute btn, coin chip (#coinCount)

(win banners maybe centerMsg suffices + side "+20" float) Start overlay #startOv: title EMBERGATE, sub "OUTRUN THE CURSE OF THE EMBER TEMPLE", vault stats row, controls legend, button. Game over #overOv: "THE RUN ENDS", stats rows (Distance, Coins gathered, Zone wins, Record bonus, TOTAL EARNED +N), vault total, new best badge, button RUN AGAIN. Pause #pauseOv simple.

EMBERGATE

THE TEMPLECLAIMS YOU

THE TEMPLE
CLAIMS YOU

Temple claude