# Themepark Benchmark Extended Prompt The primary challenge below takes precedence over the secondary extension that follows. # Coaster Maps Exceptional 3D Theme Park Challenge ## The prompt Build an exceptional, visually stunning, fully playable 3D theme-park simulation that runs in a modern desktop browser. The park is called **Coaster Maps**. This should impress me. Do not stop at a basic scene, static model showcase, shallow prototype, or collection of decorative rides. Create a cohesive park that feels alive, rewards exploration, and is genuinely fun to play. Push the limits of what you can accomplish while keeping the result stable, responsive, and understandable to a first-time player. You are responsible for the complete experience: creative direction, park layout, gameplay, simulation, original visual identity, 3D assets, textures, lighting, animation, audio where appropriate, user interface, performance, and testing. Make strong creative decisions without waiting for me to specify every detail. Pay close attention to scale, motion, readability, atmosphere, interaction feedback, and small environmental details. ## Core experience Create a theme park that the player can freely explore in first person or a similarly immersive perspective. The player must be able to: - Walk around a substantial, thoughtfully designed park. - Discover distinct themed areas, paths, landscaping, terrain, scenery, signs, lighting, and landmarks. - Board and ride multiple functioning attractions from an appropriate loading area. - Play at least one interactive midway or skill game with a real objective, controls, outcome, and feedback. - Enter or approach shops and purchase meaningful items through an actual in-game transaction flow. - Understand the controls and nearby interactions without reading source code. - Pause, resume, and recover cleanly from ride, game, shop, and movement states. The experience should have an intentional opening, an inviting park entrance, clear navigation, satisfying discovery, and enough variety that exploring feels worthwhile. The park must feel like one authored place rather than unrelated objects scattered across flat ground. ## Roller coasters and ride physics Roller coasters are the centerpiece. Include at least two substantially different, fully rideable roller coasters. They must have complete track layouts, stations, supports, trains, boarding behavior, and convincing motion. Coaster speed must respond believably to the track. Trains should accelerate downhill, lose speed uphill, and use a deliberate propulsion system such as a lift hill, launch, tire drive, or chain. Avoid moving a train around the entire course at one constant speed. Use a physics-based or carefully modeled energy system with appropriate friction, braking, acceleration, gravity, and minimum-speed handling. Across the coaster collection, include several interesting elements such as: - A lift hill or launch sequence. - Meaningful drops and airtime hills. - Banked turns and changes in elevation. - At least one inversion, such as a vertical loop, corkscrew, or zero-gravity roll. - Brakes, a final brake run, and a believable return to the station. - Track routed around, through, above, or beneath other scenery so the layout feels integrated with the park. The ride camera must remain correctly oriented to the train and track. The player should feel the changing pitch, banking, speed, height, and direction without excessive clipping, camera jitter, broken orientation, or an obstructed view. Coaster trains must follow the track accurately and should not visibly detach from it. ## Additional attractions Include several additional working attractions with visibly different motion and ride experiences. Strong candidates include: - Ferris wheel or observation wheel. - Swinging pirate ship. - Carousel or merry-go-round. - Drop tower. - Park railroad with a train that travels through the park. - Drivable go-karts on a complete track with steering, acceleration, braking, collision boundaries, and a lap or time objective. You do not need to use every suggestion, and you may invent better attractions. Prioritize depth, polish, and variety over filling the park with many shallow objects. At minimum, the finished park should contain two roller coasters, three other ride types, one playable game, and one meaningful shop experience. ## Living park simulation The park should operate as a simulation, not merely a backdrop. Include guests who move purposefully through the park and visibly participate in it. Guests should have enough behavioral variation to feel alive: choosing destinations, walking paths, forming or joining queues, riding attractions, visiting shops or games, and leaving destinations afterward. They should not all move in identical loops or stand in random places. Include park employees in recognizable roles, such as ride operators, shop workers, custodial staff, mechanics, security, or entertainers. Add at least one type of entertainer or ambient performance that contributes to the park atmosphere. Employee and guest behavior may be lightweight, but it should be observable, coherent, and connected to the park systems. Track and display useful simulation state such as attendance, guest happiness, queue length, ride throughput, park funds, purchases, game results, time of day, or weather. These values should be driven by real events in the simulation rather than arbitrary counters. Shops must support actual purchases. The player should have money or another clear resource, see prices, choose an item, complete or cancel the transaction, receive feedback, and have the result affect inventory, status, score, appearance, or another visible part of the experience. Guests should also be able to visit shops in the simulation. ## Visual direction and original assets Create an original visual identity for **Coaster Maps**, including an original logo, park signage, color system, map-inspired motifs, and consistent attraction branding. The park should look authored and premium. Generate the models, materials, textures, logos, signs, icons, and other visual assets specifically for this project. Procedural geometry and textures are encouraged. Image-generation tools may be used when available, but all resulting work must be original and appropriate for the park. Do not use copyrighted characters, existing theme-park brands, third-party logos, or unlicensed asset packs. Do not rely on remote assets that can disappear after delivery. Use terrain, elevation, foliage, architecture, props, queues, fences, lighting, shadows, particles, water, atmospheric effects, and environmental storytelling to create depth. Avoid an empty flat field, primitive-only appearance, repetitive scenery, unreadable darkness, excessive bloom, or visual effects that hide the rides. Lighting should be a deliberate part of the experience. Use a compelling time of day or a dynamic day/night cycle, readable path lighting, attraction lighting, shop illumination, emissive signs, and balanced contrast. The park must remain navigable and visually clear. Animations must communicate weight and mechanical purpose. Ride vehicles, wheels, restraints, platforms, gates, signs, guests, entertainers, and environmental effects should move consistently with their roles. Sound and music may be procedural or generated, but must be original, controllable, and not required for understanding the game. ## User experience Provide a polished, responsive interface using Material 3 design principles where interface elements are needed. The UI should complement the world rather than cover it. Include: - A strong loading or entry experience with Coaster Maps branding. - Concise control instructions. - Clear interaction prompts that change with context. - Ride, queue, game, shop, money, and simulation feedback where relevant. - A pause surface and settings for essential comfort or audio options. - Legible typography, accessible contrast, visible keyboard focus, and sensible touch targets. - Helpful error states when a required capability is unavailable. Desktop keyboard and mouse controls are required. Touch support is strongly preferred if it can be implemented without reducing desktop quality. Avoid trapping the player in pointer lock, dialogs, rides, shops, or paused state. ## Technical and architectural expectations - The finished experience must run in a modern browser and be launchable with documented local commands. - Use an appropriate browser 3D technology such as WebGL, WebGPU, Three.js, Babylon.js, or a comparable stack. - Keep the project self-contained and reproducible from the delivered files. - Use clean code and clean architecture. Separate simulation state, input, rendering, ride behavior, UI, and composition responsibilities. - Model ride and interaction states explicitly. Invalid transitions and malformed required data should fail fast with actionable errors. - Address the real cause of defects. Do not add silent fallback behavior merely to hide broken systems. - Use deterministic or seedable behavior where it materially improves testing and reproducibility. - Maintain responsive frame pacing with a meaningful number of guests and active rides. Use instancing, pooling, level-of-detail decisions, or other appropriate optimizations. - Prevent obvious collision failures, walking through major structures, leaving the playable park unintentionally, broken ride boarding, duplicated event handlers, runaway animation loops, and resource leaks. - Document the project structure, controls, prerequisites, start command, verification command, and known limitations. ## Required self-testing and iteration Do not treat compilation as proof that the park works. Run the experience in a real browser, inspect the rendered result, interact with it, and iterate on problems you observe. Before declaring completion, verify at minimum: 1. The project installs, type-checks, tests, and builds successfully. 2. The loading and entry flow reaches the playable park without console errors. 3. The player can walk, look around, navigate paths, and collide with major boundaries. 4. Every required ride can be found, boarded, experienced through a full cycle, and exited safely. 5. Coaster speed changes visibly and correctly with hills, drops, propulsion, and brakes. 6. The playable game accepts input, produces an outcome, and can be replayed or exited. 7. A shop purchase can be completed and visibly affects the player's state. 8. Guests, employees, entertainers, queues, shops, and simulation metrics behave coherently over time. 9. Pause, resume, settings, pointer lock, and escape behavior do not trap the player. 10. The layout works at common desktop sizes and, if supported, a narrow mobile viewport without overflow or unusable controls. 11. The final scene is visually inspected for clipping, scale errors, broken materials, unreadable UI, poor lighting, empty areas, and camera obstruction. 12. The production build works from its documented served path with no missing local assets or unexpected remote dependencies. Create automated tests for deterministic simulation and critical state transitions. Keep browser-visible proof of the important flows. Fix problems discovered during testing before presenting the result. ## Definition of done The project is complete only when it is a polished, playable, browser-based 3D theme park—not merely a plan or mockup—and the delivered build demonstrates all mandatory features: - An original, visually cohesive Coaster Maps park. - Immersive player exploration. - Two physics-informed rideable roller coasters. - Three additional working ride types. - Purposeful guests, employees, and at least one entertainer behavior. - A playable game. - A shop with a real purchase flow. - Original models, textures, logos, signage, and branding. - A functioning simulation with event-driven park metrics. - Clear controls and polished Material 3 interface surfaces. - Successful automated verification and hands-on browser testing. After satisfying these requirements, use your remaining judgment and capability to add memorable details, surprises, interactions, environmental storytelling, and polish. The goal is not just to meet a checklist. The goal is to create a park I am excited to explore, a coaster ride that feels thrilling, and a result that makes me say: **I am impressed.** # Themepark Benchmark Extended Prompt ## Priority and scope The original Coaster Maps Exceptional 3D Theme Park Challenge is the primary prompt. Satisfy and verify its mandatory systems first. This extension is secondary: deepen the finished park without compromising the original prompt's playability, physics, simulation, visual quality, performance, or testing. If requirements conflict, the original prompt wins. Report unfinished extension features honestly. Choose your own creative direction, implementation strategy, and use of available tools. Do not replace working core systems with shallow versions to increase feature count. This extension adds goals to the same cohesive park. ## Terrain and two themed areas Create at least two substantial, distinct themed park areas. Choose original themes and names. Give each area its own architecture, materials, planting, attraction branding, soundscape, landmarks, and environmental story. Connect them with believable transitions, readable paths, sightlines, and signs. Both areas must contain functioning attractions and observable guest activity. Shape the park around varied terrain: elevation changes, slopes, rock formations, planted ground, and water features. Route paths, coaster tracks, structures, and scenery deliberately through this landscape. Ground buildings, supports, vegetation, and props correctly; align rendered terrain with collision geometry. Provide accessible paths through elevation changes. Avoid disconnected scenery, exposed world edges, floating supports, and terrain clipping into vehicles or cameras. Use detailed scenery and environmental animation to reward exploration. Include foreground, middle-distance, and distant composition, with enough open space for navigation and clear views of attractions. Preserve readable daytime and nighttime lighting. ## Dark ride with animatronics and music Add a complete rideable dark ride that belongs to one themed area. Include an entrance, themed queue, loading and unloading areas, vehicles, and a continuous route through at least three distinct story scenes with an opening, progression, and finale. Create original animatronic characters or creatures with recognizable mechanical articulation and coordinated motion. Give them purposeful performances with movement, lighting, sound, and scene timing. Avoid figures that only spin or bob without communicating a role in the story. Compose an original soundtrack and add original character dialogue or narration. Trigger scenes from vehicle progression so performances remain synchronized when vehicles stop or the game pauses. Use spatial sound, smooth transitions, balanced mixing, and captions. The rider must experience the full sequence, return to unloading, and exit without camera clipping or interaction traps. ## Player controlled go karts Add a complete go-kart circuit with a pit or loading area, a starting grid, track boundaries, varied turns, and clear checkpoints. The player must directly control steering, acceleration, and braking. Use believable acceleration, drag, steering response, and collision behavior. Provide a countdown, a lap or time objective, validated checkpoint order, a finish result, and replay and exit actions. Do not award laps from repeated finish-line crossings without completing the circuit. Recover a stuck kart through an explicit player action that preserves fair timing and checkpoint state. Include opponents or ambient racers if they improve the experience after the basic driving flow works. ## Rotor or Roundup ride Add one of these two working ride types and identify which you chose: - **Rotor:** a cylindrical drum with standing riders against its inner wall. Show boarding, closure, spin-up, a floor that lowers after sufficient rotation, a sustained ride, floor return, spin-down, and unloading. Represent riders staying against the wall convincingly without unexplained levitation. - **Roundup:** a circular standing-rider platform that rotates and then tilts upward. Show loading, restraint or gate closure, spin-up, controlled tilt, a sustained ride, return to horizontal, spin-down, and unloading. Keep the machinery, passenger placement, boarding state, and ride camera consistent throughout the complete cycle. Explain the operating principle through visible motion and optional concise ride information. ## Top Spin ride Add a Top Spin style attraction with a passenger gondola suspended between two rotating arms. Model the relationship between arm rotation, gondola pivoting, gravity, and deliberate gondola locking or braking. Include a varied sequence with swings, elevation changes, and inversions rather than rotating the entire assembly as one rigid object. Include a station, loading platform, restraints, boarding, a full programmed cycle, return to the loading position, and safe unloading. Keep passengers attached to their seats and provide a correctly oriented rider camera with comfort controls. Avoid visible collisions between the gondola, arms, platforms, and scenery. The dark ride, go-karts, Rotor or Roundup, and Top Spin are extension goals. They may satisfy the primary prompt's additional-ride minimum when implemented and verified; preserve at least three distinct non-coaster ride types overall. ## Voice overs and park audio Add original voice overs for ride introductions, loading announcements, dark-ride storytelling, and the nighttime show where useful. Keep announcements concise and contextual. Provide captions for spoken information, separate music, effects, and voice volume controls, and a master mute. Do not require hearing a voice cue to complete an interaction. Give guests voiced comments tied to events they actually experience: anticipating or finishing a ride, waiting in a queue, buying an item, playing a game, discovering scenery, and watching the nighttime show. Vary voices, wording, and emotional delivery across guests. Comments must reflect the speaker's current experience and simulation state rather than play as an unrelated ambient loop. Give park employees voices appropriate to their roles. Ride operators greet riders and give boarding and unloading instructions; shop workers respond to purchases; entertainers perform or engage guests; other employees comment on tasks they are actually carrying out. Include contextual responses when the player interacts with employees, and audible exchanges between guests and employees where appropriate. Position speech at the visible speaker with distance attenuation and sensible overlap limits. Use cooldowns and varied line selection to avoid repetitive chatter. Prioritize nearby interactions and important announcements over background comments. Caption guest and employee speech with an identifiable speaker, and provide a separate guest-chatter volume control. Voice playback must pause and resume consistently without duplicating lines or continuing from unloaded characters. Use authorized synthetic voices or original recordings. Do not imitate a real person's voice without permission. Package the finished audio locally and document its source and usage rights. Resume audio coherently after pause and respect the browser's user-gesture requirements for starting playback. ## Firework laser and drone show Create a recurring nighttime performance combining fireworks, animated laser beams, and coordinated illuminated drones with an original musical score. Give it a clear beginning, buildup, climax, and ending. Synchronize all components to one show timeline so pause and resume preserve the choreography. Design a viewing area with clear sightlines. Let the player discover the schedule and attend or start the performance through a clearly labeled in-world interaction. The show must play visibly in the park, with guests gathering, watching, and dispersing afterward. Show several distinct firework effects, purposeful laser choreography, and drone formations that transform between recognizable original shapes. Use sound, reflected or nearby illumination where appropriate, and controlled particle budgets. Keep the park navigable during the show and offer reduced flashes and reduced effects settings. Verify the complete performance while ordinary park systems continue operating. ## Creative resources and tool access Blender is installed on this computer and is available for you to use if you want to. You also have access to an AI music-generation tool on this computer called Yue2. xAI text-to-speech is an optional voice-generation capability when the benchmark launcher verifies access for this run. Use these resources at your discretion to create original park assets, music, guest comments, employee dialogue, narration, and announcements. Their use is optional; choose the tools and workflow that best serve the primary challenge and this extension. Use xAI Text to Speech through its REST API when access is verified. The benchmark launcher must provide the credential to the process as the `XAI_API_KEY` environment variable. In Node.js, read it from `process.env.XAI_API_KEY` and use it only as the bearer credential in the `Authorization` header. Send `POST https://api.x.ai/v1/tts` a JSON body containing `text`, `voice_id`, `language` (such as `en`), and an `output_format` object (for example, `{"codec":"mp3","sample_rate":24000,"bit_rate":128000}`); save the response audio bytes as an MP3 asset. Use authenticated `GET https://api.x.ai/v1/tts/voices` to discover current built-in voice IDs. Never print, log, embed, commit, or otherwise expose the credential value. Do not include private credential-storage details in source, prompts, reports, screenshots, browser code, or deliverables. Verify a successful response and usable audio before claiming xAI TTS was available or used; if the variable is missing or the request fails, report that limitation. The execution environment also provides internet access, filesystem and terminal tools, browser testing, and the AI image-generation tools recorded for this run. The launcher must verify and disclose actual access before delivering the prompt. Tool names alone do not establish authenticated access, usable credits, supported export formats, or permission to retain generated assets. Use available tools at your discretion. Blender may be used to create original models, UVs, textures, rigs, and animations, exported into browser-compatible assets. Generative tools may create original textures, music, and voices. Optimize exported meshes, textures, animation, and audio for browser playback. Keep editable source assets where practical and package runtime assets locally. If a resource is unavailable, report it and its effect on the result. Do not claim access or successful use without evidence. Procedural or manually authored original assets remain valid creative choices; do not describe them as generated by an unavailable service. Missing tools do not waive the primary prompt's required functionality. Record the execution environment and version, exact root model and effort, speed tier, relevant permissions, available tools, tools actually used, delegated model identities where observable, and asset provenance. Keep external monitoring and evaluator evidence outside the candidate. Do not expose model identity in blind rating media. ## Extension verification After verifying the primary prompt, test and document: 1. Both themed areas are reachable, visually distinct, populated, and connected to operating park systems. 2. Terrain, paths, structures, ride vehicles, and collision boundaries agree in representative locations. 3. The dark ride completes its story, animatronic performances, soundtrack, loading, and unloading sequence. 4. Go-kart steering, acceleration, braking, collisions, checkpoint validation, results, replay, and exit work. 5. The Rotor or Roundup and Top Spin complete their mechanical and passenger cycles without clipping or trapped states. 6. Voice overs, event-driven guest comments, employee dialogue, spatial speech, speaker captions, volume controls, mute, and pause and resume work. Exercise guest reactions and employee interactions in several contexts; check repetition and overlapping speech with a populated park. 7. The complete firework, laser, and drone show remains synchronized, draws guest activity, and preserves usable frame pacing. 8. The production build loads its models, textures, music, and voices from packaged assets at the documented served path. Report primary completion separately from extension completion. Identify each delivered extension feature, its verification evidence, and any missing or partial behavior. A polished, verified primary park takes priority over an unfinished expansion. ## Benchmark reporting and reproducibility Deliver a RUN_RECEIPT.md and BENCHMARK_RUN_REPORT.json with the result. Report the exact root model, reasoning effort, speed tier, harness name and version, session IDs when observable, execution permissions, available capabilities, successfully used tools, delegated models, and known limitations. Preserve unknown fields as null with a reason. Never infer successful access from an installed application or a tool name. Report measured token usage with provider field names and sources: input, cached input, cache creation, output, and reasoning tokens when exposed. State whether cached input is included in input and reasoning is included in output; do not add subsets twice. Separate root and child usage and deduplicate requests or cumulative session totals before calculating aggregate usage. Do not estimate token counts from elapsed time, text length, or a model's recollection. If provider counters are inaccessible, explicitly report usage as unavailable and identify the telemetry source needed by the external monitor. Lack of telemetry does not justify fabricated values. Record UTC start and end timestamps and distinguish model execution duration, CLI lifetime, and interruptions. Distinguish measured provider costs from dated token-only estimates; cite model rates, cache treatment, speed tier, context thresholds, currency, and excluded tool or media-generation charges. Preserve unavailable costs as null. External monitoring owns authoritative session counters and timing; your report must identify which fields you can actually verify. Document install, build, test, and serve commands, exact versions, production URL or local served path, seeds, browser and viewport, tested flows, outcomes, and observed defects. Include an asset manifest with source, generating tool or manual/procedural method, runtime path, and rights for models, textures, music, and voices. Report primary and extension feature status separately as verified, partial, missing, or not tested, with evidence references. Do not claim that your own report establishes independent evaluator acceptance. The launcher assigns the run ID and preserves the exact delivered primary-plus-extension prompt and its SHA-256, registered protocol, and initial empty-workspace evidence outside the candidate. After the one-shot session ends, the evaluator freezes the source and assets with a file-hash manifest. Evaluator copies, captures, and any later repairs remain separately identified. Do not create capture-only controls or evaluator instrumentation in the delivered park. These runs join the existing Theme Park Benchmark's shared scoring, leaderboard, and voting pool. Their identified run metadata must say Themepark Benchmark Extended Prompt and retain the exact prompt variant and digest. The prompt variant is descriptive metadata, not a separate ranking or voting partition. Blind comparisons must not reveal the model, harness, effort, cost, or prompt variant. Record subjects delivered for evaluator capture; the evaluator applies the shared category definitions and media standards outside the candidate.