# PALM HARBOR — High-fidelity miniature open-world game

Act as a senior real-time 3D engineer, technical artist, environment artist, and gameplay programmer. Build a playable game in this repository, not a landing page, design document, prerecorded video, or static scene that pretends to be interactive.

## 1. The goal and the most important tradeoff

Create an original, GTA-inspired miniature open-world experience called PALM HARBOR: a small, believable South Florida coastal neighborhood where I can drive a beautiful car, explore on foot, and enjoy cinematic, realistic-looking surroundings.

The ambition is the atmosphere and visual credibility of a modern open-world driving game, NOT its enormous map or feature count. Use original names, branding, characters, and layouts. Do not use ripped GTA assets, logos, UI, music, or proprietary game files.

“Miniature” means a small playable area at realistic human scale, not a toy city, diorama, tilt-shift scene, or low-poly art style.

Prioritize, in this order: visual credibility; satisfying driving and camera behavior; reliability and performance; environmental richness; additional features.

One excellent street and one excellent car are better than twenty mediocre streets and ten crude cars. Reduce scope before sacrificing visual quality. A technically functional scene of plain boxes and primitive cars does not meet the visual goal.

The first milestone must be a beautiful, drivable street. Walking, traffic, missions, and photo mode come afterward. Never weaken the first milestone merely to check off secondary features.

## 2. Platform and technical approach

Assume a desktop-browser game, suitable for a browser-based development preview and normal deployment. Keyboard and mouse are the primary controls. No installation, account, backend, paid service, or API key should be required to play.

First inspect the existing repository, instructions, dependencies, available tools, and supplied assets. Preserve useful working code and respect existing project conventions.

For a new project, prefer Vite, TypeScript, Three.js, and Rapier. Use a thin HTML/CSS interface; React is acceptable for the interface if the project already uses it. Keep per-frame simulation outside React state.

Use a coherent WebGL2 rendering path as the baseline. Do not mix WebGL postprocessing with incompatible WebGPU/node-material examples. Do not promise engine-specific features such as Lumen or Nanite in a browser implementation.

Inspect the actual installed package APIs and documentation. Pin mutually compatible versions and commit the lockfile. Do not invent imports, use obsolete renderer flags, or assume an API from memory works with the installed release.

Use glTF/GLB for imported models. Include required decoders and physics initialization in the project and test them in production builds. Prefer local, optimized runtime assets over third-party hotlinks.

## 3. Art direction and opening shot

The setting is a fictional coastal neighborhood shortly after a light summer shower, with low, warm late-afternoon sun, a luminous blue sky, and distant ocean haze.

Make the scene feel photographed rather than illustrated. Maintain readable shadows, natural exposure, restrained saturation, and plausible material contrast. Do not cover weak geometry with heavy bloom, excessive fog, darkness, or an orange filter.

The palette is warm off-white stucco, faded coral, pale mint, turquoise signage, dark asphalt, weathered concrete, deep green palms, and a rich blue sky. Use bright colors as accents, not on every surface.

Compose the starting view deliberately. The player begins seated in the hero car, parked outside a small coastal hotel. A low third-person camera looks down a palm-lined street. The frame includes detailed road texture in the foreground, the car in the lower center, interesting storefronts on both sides, long shadows across the road, and a glimpse of the coast beyond the next intersection.

The first controllable frame should already be worth taking a screenshot of. Avoid an empty parking lot, overhead editor view, featureless horizon, or opening shot staring into a wall.

Create depth in layers: detailed foreground, attractive mid-distance street, simplified background architecture, then sky and atmospheric distance. Stage the sun so the car and architecture have readable shape rather than becoming silhouettes.

## 4. Small, deliberately designed map

Target approximately 250 × 250 meters, with two to four compact blocks and a connected driving loop. Start with an approximately 80-meter showcase street before expanding. Shrink the final area if available assets or performance require it.

Include a palm-lined main boulevard, a narrower side street, a service alley, a small hotel forecourt, and a coastal overlook. Connect them into a route the player can navigate repeatedly without constantly reversing.

Use three recognizable landmarks: Palm Harbor Hotel, Sunset Market, and the coastal overlook. Make each distinguishable through architecture and composition, not only floating labels.

Use believable proportions: roughly 3.2-meter traffic lanes, 2–3-meter sidewalks, 0.15-meter curbs, a roughly 4.5-meter car, and a roughly 1.8-meter person. These are starting design dimensions, not inflexible measurements.

Use meters consistently. Document the coordinate system, with +Y up, and explicitly map imported vehicle and character forward axes to the controllers.

Design roads, traffic paths, collisions, mission locations, and the minimap from shared world-layout data. Do not maintain contradictory copies of the street layout.

Hide map edges with coherent geography: building fronts, roadworks, fences, a seawall, or a road bend. Add a lightweight distant skyline for depth, but do not create an enormous inaccessible city.

Buildings do not need playable interiors. Recessed shopfronts and simple interior silhouettes are enough. Ocean water is scenic, not a swimming or boat simulation.

## 5. Asset acquisition is part of the task

Do not assume adjectives such as “photorealistic” can substitute for assets. Before extensive environment work, establish a working asset pipeline and obtain the essential visual ingredients.

Prioritize a realistically proportioned car with separately controllable wheels; convincing palms; asphalt, concrete, stucco, and metal materials; an appropriate environment map; and a small set of street props. Obtain a rigged character with compatible idle, walk, and run animations before promising finished third-person walking.

Look for suitable downloadable assets with verified redistribution rights. Consider Poly Haven and ambientCG for relevant materials, lighting environments, and models. Check the actual license of every chosen asset, including assets from other providers. “Free to view” is not sufficient.

Do not assume those libraries contain every required vehicle or character. Search specifically for missing categories, verify the download, and check the model in the renderer before depending on it.

Create an asset manifest recording each asset’s local path, source page, creator, license, attribution requirements, modifications, approximate file size, and intended use. Keep required attribution in an asset credits file and accessible credits panel.

Downloads must use verified URLs, sensible timeouts, and bounded retries. Save assets locally. Validate file types, referenced texture files, model scale, orientation, mesh structure, and actual loading. Never leave invented asset URLs or nonexistent files in the final project.

Provide an idempotent preparation script when conversion or optimization is needed. If Blender or another asset-processing tool is available, use reproducible scripts for beveling, UV preparation, wheel separation, collider proxies, or export. Do not assume those tools exist without checking.

Procedural geometry is appropriate for roads, architectural modules, collision proxies, and some props. Finished visible geometry still needs credible proportions, depth, bevels where useful, appropriate materials, and detail. A flat cube with random windows is not a finished building.

If essential assets cannot be acquired, keep the application runnable with clearly identified temporary substitutes and document exactly what is missing. Continue improving the available scene, but do not claim placeholder art meets the realism target. Do not stall indefinitely on blocked downloads or silently bypass licenses.

## 6. Environment detail that sells realism

Roads should show material variation at several scales: aggregate texture up close, larger patches and wear at street scale, faded markings, occasional tire marks, and restrained dampness variation. Avoid obvious texture repetition and oversized noise.

Add curb edges, sidewalk expansion joints, drainage grates, manhole covers, driveway transitions, and crosswalks. Geometry and collision surfaces must agree so the car does not float above the road or strike invisible steps.

Architecture should include recessed windows, doorframes, ledges, balconies, awnings, roof parapets, gutters, and wall thickness at visible edges. Use a compact modular kit with several authored variations rather than endless random boxes.

Shop windows need believable reflections and a hint of depth. Small noninteractive interior cards or shallow rooms are acceptable. Do not make every window a glowing flat rectangle or perfect mirror.

Place streetlights, traffic signs, benches, trash bins, utility boxes, parked cars, and a few restrained posters or shop signs. Use clusters that look intentionally placed. Preserve clear driving lanes and useful walking space.

Palms should have convincing trunks and layered frond silhouettes, not cylinders topped with cones or solid green spheres. Add slight, coherent wind movement without making entire trunks wobble like rubber.

Use a small number of carefully placed puddles where water would collect. Most of the road should remain rough and only partly damp. Do not turn the entire neighborhood into a reflective floor.

Apply the most detail along the opening view, main route, and landmarks. Use simpler materials and geometry where the player will not inspect closely.

## 7. Lighting, materials, and rendering

Establish lighting and material quality before adding expensive effects.

Use physically based materials with deliberate base color, roughness, metalness, and normal information. Use clearcoat selectively for automotive paint. Concrete, rubber, painted walls, metal, and glass must read as different materials.

Configure color management correctly for the installed Three.js version. Treat color textures and data textures appropriately. Ensure exposure, tone mapping, and output conversion are applied exactly once across the chosen render/postprocessing pipeline.

Use a suitable HDR lighting environment with prefiltered environment lighting where supported. Coordinate its orientation and brightness with the main sun. Do not introduce contradictory sun directions or overly bright ambient light that removes all depth.

Use one main directional sun and a controlled shadow budget. Prioritize crisp-enough nearby shadows around the car, curbs, palms, and building contact points. Fit and stabilize shadow coverage around the playable view instead of spreading one small shadow map across the whole city.

Add subtle ambient occlusion only if it materially improves grounding and remains within the frame budget. Do not stack multiple AO techniques or crush shadow detail.

Use one intentional antialiasing approach, restrained highlight bloom, and optional light color grading. Avoid excessive vignette, chromatic aberration, film grain, sharpening halos, and motion blur. Keep depth of field off during normal driving.

Prefer stable environment reflections first. Local reflection probes or a limited planar puddle reflection are optional improvements, not prerequisites. Do not enable expensive full-scene reflection effects everywhere to compensate for poor materials.

For distant water, use a lightweight surface with restrained wave normals, plausible sky reflection, and a coherent horizon. No ocean simulation is required.

Control foliage transparency and overdraw. Favor appropriate cutout materials when practical. Check shadow artifacts, transparent sorting, z-fighting, and texture seams in actual screenshots.

Expose lighting, exposure, fog, and material tuning in a development-only panel. Hide all editing helpers in the normal game.

## 8. The hero car and driving feel

Use one attractive, unbranded coupe or sports sedan. Spend effort on body proportions, wheel arches, wheels, tires, windows, lights, panel definition, and believable paint. The silhouette must not resemble a rectangular block on cylinders.

Give the car convincing acceleration, braking, steering, tire grip, and body response. Aim for accessible, believable arcade handling rather than either a frictionless toy or a demanding racing simulator.

Use a dynamic physics chassis and a raycast/suspension vehicle controller when supported by the installed Rapier version. Consult the actual API rather than guessing method names. Keep the visible model separate from simplified colliders.

Run physics at a fixed timestep, initially 60 Hz, with bounded catch-up steps and interpolated rendering. Clamp unusually large elapsed times. Handle hidden tabs and pause transitions without explosive physics updates.

Explicitly configure the vehicle axes, wheel connections, suspension direction, tire radius, and center of mass. Exclude the vehicle’s own colliders from wheel ground queries. Initialize the world and colliders before spawning the car, then allow it to settle correctly.

Implement progressive throttle, speed-sensitive steering, braking, rolling resistance, and a modest top speed appropriate for this tiny neighborhood. Reverse should engage only after slowing sufficiently; pressing brake while moving forward must not instantly reverse the car.

Space applies a handbrake with controlled loss of rear grip. Make steering recover predictably. Use modest stability assistance if needed, without removing all body motion.

Animate wheel rotation from movement and steering angle from actual control state. Add restrained suspension movement and body pitch/roll. Wheels should remain aligned with their contact positions rather than floating or clipping through the body.

Use suitable collision detection for the car’s speed and obstacle sizes. Test corners, curbs, lamp posts, and parked cars. Do not move a dynamic car by directly rewriting its position every frame. Reserve teleporting for explicit recovery/reset actions.

Provide a safe reset that restores the car to a known clear road location and clears velocity, angular velocity, control state, and problematic camera state. Recover automatically if it falls outside the world.

## 9. Camera quality is a core feature

Create a smooth third-person chase camera with frame-rate-independent damping. Follow an interpolated vehicle transform to avoid physics jitter.

Start around 5–7 meters behind and 2–3 meters above the car, then tune by inspecting the result. Look slightly ahead of the vehicle rather than directly at its center.

Allow mouse orbit and smooth recentering after the player stops adjusting the view. Support click-drag orbit when pointer lock is unavailable in an embedded preview. Do not repeatedly force pointer lock after the player exits it.

Use a modest vertical field of view, initially around 60 degrees, with only a small speed-related increase. Avoid a distorted ultra-wide camera that makes the world look miniature.

Use a swept camera collision volume, or an adequately robust equivalent, to shorten the camera arm near buildings. A single thin ray that still lets the camera clip through corners is insufficient.

The car must remain readable while accelerating, reversing, turning, and passing through the alley. Camera shake must be subtle and optional. Prevent clipping through the car, road, or walls.

## 10. Walking and entering the car

Add this after the driving scene passes its quality and stability checks.

Use a realistically proportioned rigged character with cleanly blended idle, walk, and run animations. Use a capsule-based character controller with gravity, ground detection, slope handling, and reasonable curb traversal.

Character movement should be camera-relative, turn smoothly, and match animation speed well enough to avoid obvious foot sliding. No combat, climbing system, elaborate parkour, or ragdoll is required.

Press E near a car door to enter. Press E while stopped or nearly stopped to exit. Use a small interaction prompt only when an action is available.

A short camera transition or restrained fade is acceptable instead of a complex door-entry animation. Do not fake an animation that the asset does not contain.

Check both sides of the vehicle for a safe exit position. Prevent spawning inside walls, another car, or the road surface. Debounce the interaction and correctly enable/disable the character’s collider and controls during transitions.

The first frame still begins in the car so driving remains immediately available. If a suitable animated character is genuinely unavailable, retain the polished driving build and explicitly report walking as unfinished rather than presenting a block-person substitute as complete.

## 11. Small amounts of life, audio, and gameplay

Once the environment and player controls work, add a few ambient vehicles on predefined lane paths. Start with approximately three. They should maintain spacing, yield at basic conflict points, and avoid driving through the player. Do not build a general-purpose traffic simulation.

Add a handful of pedestrians only after suitable models and animations are available. Keep them on sidewalks, use simple paths and idle behavior, and avoid obvious duplication in the same frame. Do not spawn or teleport actors directly in view.

Use environmental audio to support the place: distant surf, light wind, occasional birds, restrained traffic, footsteps, and a car engine. Engine pitch and volume should respond smoothly to driving state; tire squeal should correspond to meaningful slip rather than playing constantly.

Audio must begin only after an appropriate user interaction, support mute and volume, and use original or properly licensed sounds. Do not include commercial songs or copied radio stations.

Default to free roam. Add one optional activity called “Coastal Run”: visit three landmarks in sequence, stopping briefly in a marked bay at each destination. Show the current destination and progress. Finish with a small completion message and allow replay without reloading.

Mission progress must use actual player/vehicle position and movement state, not a timer masquerading as gameplay. The activity should encourage exploration, not require a full quest framework.

## 12. Interface and controls

The game is the product. Do not spend the project on a promotional homepage, dashboard, giant title, or decorative menu system.

Use a minimal start overlay over the real rendered scene, with Play, basic controls, graphics settings, and credits. Loading indicators must represent real progress or clearly describe the current loading stage. Critical load failures need an understandable error and retry path.

During play, show a compact minimap generated from the actual map data, a speed readout while driving, a small objective label when relevant, and contextual interaction hints. Do not add fake money, health, wanted stars, or inventory systems that do nothing.

Controls: WASD for movement/driving; mouse for looking; Shift for running on foot; Space for the handbrake in the car; E for enter/exit; R for safe reset; H to hide the HUD; Escape to pause and release pointer capture.

Optional P toggles photo mode after the core game works. Freeze simulation, allow controlled camera positioning, hide the HUD, and restore the previous gameplay state cleanly when leaving. Photo mode is for real rendered screenshots, not substituted promotional images.

Prevent gameplay keys from scrolling the page while the game has focus. Clear held inputs on blur, pause, and visibility changes. Support window resizing and readable interfaces at common desktop resolutions.

## 13. Performance and loading discipline

Target smooth desktop play. Use 60 FPS at 1080p on a suitable test machine as an aspiration, with a lower-cost preset targeting 30 FPS where necessary. These are targets, not claims to make without measurement.

Provide Low, Medium, and High presets that actually change resolution scale, shadow quality/distance, effect cost, and ambient population where appropriate. Choose a conservative initial pixel-ratio cap instead of blindly rendering at full device pixel ratio.

Use practical starting budgets: a few hundred visible draw calls, moderate visible geometry, mostly 1K–2K textures, and 4K textures only where a close-up visibly benefits. Aim to keep the initial essential asset download around 30 MB and the entire small demo around 75 MB when feasible. Measure and explain deviations rather than sacrificing the hero scene blindly.

Use instancing, geometry/material reuse, culling, and level of detail for repeated scenery. Avoid giving every small prop a unique large texture or every light a dynamic shadow.

Load the hero area first and defer nonessential content. Ensure all critical assets and colliders are ready before allowing movement. Avoid per-frame allocations, duplicate animation loops, leaked listeners, and unreleased GPU resources.

Keep a debug overlay with frame time, draw calls, visible geometry, entity counts, active quality preset, and useful load information. Distinguish CPU-observed frame timing from true GPU timing.

If the available browser uses software rendering or lacks a suitable GPU, report that limitation. Do not present headless software-renderer results as representative gaming performance.

## 14. Build order and quality gates

Work in small, runnable increments. Preserve the project’s working state and document decisions. Do not return only a plan when implementation is possible.

Stage A — Asset and visual proof: establish the renderer, asset loading, one short street, the hero car, lighting, materials, and the opening camera. Render and inspect the actual result. Correct scale, exposure, floating objects, flat materials, and obviously primitive silhouettes before expanding.

Stage B — Playable driving: implement vehicle physics, collision, chase-camera behavior, input, pause, and recovery. Make a complete drivable loop. Verify forward motion, braking, reversing, cornering, and resetting.

Stage C — Environmental polish: add the remaining small neighborhood, landmarks, street dressing, foliage, and scenic coast. Compare screenshots against the art direction. Fix the three largest visible realism problems before adding effects.

Stage D — Secondary systems: add walking/entry, the small ambient population, audio, the optional route activity, and minimal interface. These must not regress the core scene or driving.

Stage E — Optimization and verification: measure the build, implement quality settings, test asset failures, inspect representative views, and document verified results and remaining limitations.

Do not expand the map while the first street still looks unfinished. Do not claim visual success based only on code compilation or the number of features implemented.

## 15. Test the actual experience

Run the available type checks, tests, and production build. Start the application and use browser inspection or automation when available. Do not claim tests ran if the environment prevented them.

Check that the game loads without missing textures, decoder failures, unhandled promises, or recurring console errors. Test production asset paths, not only the development server.

Test driving a full loop, reversing, braking from speed, clipping a curb, colliding with an obstacle, recovering after a rollover, and resetting after leaving the world. Confirm the camera stays outside geometry.

Test repeated entry/exit, including a blocked door side; pausing while a key is held; switching tabs; resizing; restarting the optional activity; changing quality settings; and leaving photo mode. Confirm inputs, physics, and sound recover correctly.

Record actual frame-time measurements after warm-up during a repeatable route. Include the machine/browser/rendering context where available, viewport, quality setting, and median and slow-frame timing. Label estimates and untested targets clearly.

Capture actual in-engine screenshots of the opening view, a moving street-level view, an intersection, and the coastal overlook. Inspect them for scale, material quality, shadows, foliage, camera composition, and obvious visual bugs. Do not substitute generated concept art for implementation evidence.

If screenshot or interaction tooling is unavailable, provide reproducible manual test steps and explicitly identify the checks that remain unverified.

## 16. Deliverables and final instructions

Deliver the runnable project, local assets or reproducible authorized asset preparation, asset credits, a concise README, controls, graphics settings, and the commands needed to develop and build it.

Provide the appropriate development command, configured for the hosting environment’s address and port requirements. Document any unavoidable prerequisites rather than hiding them.

Keep environment layout, rendering, assets, input, physics, vehicle behavior, character behavior, camera, audio, and UI reasonably separated. Do not create a complex engine framework or a monolithic file that makes tuning impossible.

Save this brief in the repository. Preserve existing project instructions; add a concise project-local AGENTS.md note pointing to the brief and recording the build/test commands and quality priorities. Maintain a short progress file for unfinished work.

The final summary must distinguish implemented and tested behavior, implemented but unverified behavior, and missing work. Include real screenshots and performance measurements only when actually captured.

Begin by inspecting the project and establishing the first visual-and-driving milestone. Make reasonable decisions without asking me to choose every minor technical detail. Ask only when a genuine blocker requires credentials, paid assets, or a consequential decision you cannot resolve from the project.

The central standard is simple: deliver a tiny place that feels convincingly real and good to drive through, rather than a large place that merely contains many objects.