made a tiny town with opus 5.5 where you type what happens and 224 people react to it.

play with it here

full prompt: # Build an Interactive World Model Playground Build a complete, working browser experience called **Small World**. It is a beautifully rendered miniature town that people can change through natural language and direct interaction. The world responds through connected systems: pedestrians, traffic, weather, destinations, water, and lighting. The central experience: **Change one thing. Watch everything react.** Act as the product designer, creative coder, simulation engineer, and art director. Make implementation decisions independently within the constraints below. Implement the experience in the current environment. This is a request for functioning software, not a proposal, mockup, video, or implementation plan. ## 1. The creative premise Imagine a meticulously designed architectural model that has come alive. Tiny people have destinations. Cars travel between neighborhoods. A river passes through town. Bridges connect its banks. People visit the park and gather in the square. Then the user types: > “Start a festival in the park.” A small stage and lights appear. People change destinations and begin converging on the park. Nearby paths become busier. The user continues: > “Now make it rain.” Cloud shadows move across the town. Rain begins. Umbrellas appear. Festival visitors leave exposed areas and walk toward reachable shelters. Then: > “Close the north bridge.” Barriers appear. Approaching vehicles stop and choose another route. Pedestrians change their paths. The longer crossing becomes busier. **These are not separate visual effects. They are consequences unfolding inside the same persistent world.** That connected behavior is the product. The experience should be compelling as a silent screen recording, but remain genuinely interactive when someone uses it themselves. ## 2. Priorities and scope Build one small, exceptionally polished world rather than a sprawling, incomplete city builder. Prioritize, in this order: 1. A visually distinctive, living miniature. 2. Real, legible cause and effect. 3. Reliable language commands and direct interaction. 4. Smooth motion and immediate feedback. 5. A reproducible showcase sequence. The required scope is one town and the six interventions described below. Do not add accounts, multiplayer, a large procedural map generator, economic systems, extensive dashboards, or a general-purpose construction editor. The ambition belongs in the quality and connectedness of the experience, not the number of menus. ## 3. Art direction: a living architectural miniature Use an elevated, orthographic or near-orthographic 3D view. The town should feel like a carefully composed physical diorama, not a generic low-poly asset pack. Create a compact landscape with: - A river separating two neighborhoods. - Two bridges, with visibly different alternative routes. - Approximately 12–20 buildings with varied silhouettes. - A park, a small market square, and a riverside parking lot. - Roads, sidewalks, crossings, and connected pedestrian paths. - Trees, benches, streetlights, and a few sheltered gathering places. - A lower riverbank and higher ground so flooding has a readable spatial effect. Name the important locations consistently: **North Bridge, South Bridge, Central Park, Market Square, Riverside Parking.** Compose the world so the viewer can identify these places without a forest of labels. Both bridges should support vehicle and pedestrian crossings. Give the road and pedestrian networks meaningful alternative routes. A closed bridge should create a visible detour rather than immediately disconnecting everything. ### Visual character Use simple geometry with intentional detailing: rooflines, window recesses, awnings, bridge railings, curbs, layered tree canopies, and recognizable miniature vehicles. Buildings should not all be differently scaled copies of the same box. Aim for: - Soft, convincing contact shadows. - Matte architectural materials. - Restrained reflections on water. - Gentle tree movement. - Clear separation between roads, paths, and buildings. - Small warm lights that become visible at dusk. - Enough detail to reward looking closely without losing readability. The scene should look appealing even while paused. Avoid photorealism, Minecraft-style voxels, thick cartoon outlines, excessive bloom, heavy depth of field, and noisy textures. Keep the people and routes legible. The default camera must be excellent. The user should not need to discover a flattering angle. ## 4. Interface design The interface should use the restrained visual language of ChatGPT-like product software, while the world itself provides the color and personality. Use these as starting design tokens, not as a claim about an official brand palette: - Page background: `#F7F7F8` - Surfaces: `#FFFFFF` - Primary text: `#202123` - Secondary text: `#727272` - Borders: `#E5E5E5` - Primary controls: near-black with white text For the world, use muted sage vegetation, desaturated blue water, warm gray buildings, and occasional terracotta details. Use a clean sans-serif, careful spacing, tabular numerals, subtle borders, and restrained corner radii. ### Composition The world should occupy approximately 80% of the initial viewport. Use a minimal header: **Small World** *Change one thing. Watch everything react.* Place a compact command bar near the bottom center: **“Change the world…”** Nearby, provide a few contextual example commands. These should execute real actions, not open explanatory dialogs. Keep playback controls and world settings compact. Put secondary information in a small inspector or disclosure, not a permanent large sidebar. Do not create a marketing landing page above the experience. ### Specifically avoid No purple gradients, glassmorphism panels, oversized marketing headlines, italic accent words, numbered editorial sections, monospace micro-labels everywhere, excessive pill buttons, or a grid of dashboard cards. Do not spend more visual attention on the interface than on the world. Night changes the lighting of the world, not the theme of the surrounding interface. ## 5. The living simulation The world should already be active on first load. Start with approximately 100–160 pedestrians and 20–30 vehicles, adjusting these counts for legibility and performance. ### Pedestrians Each pedestrian needs a persistent identity, position, destination, behavioral state, and valid route. Support a small coherent set of behaviors: - Traveling to an ordinary destination. - Visiting a park or attending the festival. - Seeking shelter. - Waiting when no route is available. Use modest variations in speed and departure timing. People should follow navigable paths, avoid buildings and water, and maintain reasonable separation. At a destination, distribute them across available space instead of stacking them into one point. When conditions change, update their actual goals or routes. Do not simply rotate their visual models while they continue following the old path. ### Vehicles Vehicles should use a road network, maintain spacing, queue behind stopped traffic, and negotiate intersections through a simple consistent rule. A closed route must affect routing. Vehicles already crossing a bridge when it closes should finish crossing safely. Vehicles approaching it should stop or reroute. Do not teleport vehicles to their new route. ### Inspectability Clicking a person should reveal a tiny inspector with their actual current state, such as: **Heading to Central Park** **Seeking shelter at Market Square** **Waiting for an accessible route** Optionally highlight that person's real route while selected. This is a useful way to demonstrate that the world contains persistent agents rather than decorative particles. ## 6. Six required interventions Each intervention must change simulation state and produce visible consequences. ### A. Start or stop a festival Example: > “Start a festival in Central Park.” A small stage, bunting, or light installation appears in a short, tasteful construction animation. A meaningful subset of pedestrians changes destination and walks toward the park. The gathering should visibly build over time. When the festival ends, attendees resume other activities. Attendance must respect reachability and weather. People should not keep walking into a closed or flooded route just because a festival is active. ### B. Change the weather Examples: > “Make it rain.” > “Start a thunderstorm.” > “Clear the weather.” Transition the atmosphere smoothly: lighting, cloud shadows, rain, subtle wind, and surface appearance. Weather must also affect behavior. Exposed pedestrians seek reachable shelter, some open umbrellas, and vehicles use a reduced target speed. When the weather clears, people gradually resume ordinary activities. Keep rain and umbrellas readable at the default camera distance. Avoid flashing lightning and screen shake. The scene should remain comfortable to watch. Rain alone should not automatically cause an arbitrary catastrophic flood. Water level is a separate intervention. ### C. Close or reopen a bridge Examples: > “Close the north bridge.” > “Reopen it.” Place visible barriers and modify the relevant navigation connections. Agents approaching the closure should choose reachable alternatives. Congestion should emerge from the changed routes and vehicle spacing, not from artificially spawning a traffic jam. If no route exists, agents should wait in an appropriate place rather than cross forbidden geometry. Reopening the bridge should restore its connections. ### D. Convert the parking lot into a park Example: > “Turn Riverside Parking into a park.” Transform the selected site with a coordinated animation: parking markings disappear, planted areas and paths appear, then trees and benches settle into place. Update its function in the simulation. It becomes an accessible destination, not just a different mesh. Handle existing vehicles or pedestrians consistently. Do not build trees through occupied cars or leave agents trapped inside new geometry. This does not require arbitrary city editing. A well-designed transformation between supported site types is sufficient. ### E. Raise or lower the river Examples: > “Raise the river by one meter.” > “Return the river to normal.” Show water spreading from the river into connected low ground. Use a simplified elevation-based inundation model. Flooded areas should connect to the river rather than appearing randomly across the map. Affected road and pedestrian connections become unavailable at explicit depth thresholds. Agents choose safe reachable alternatives or wait when necessary. Give the town enough elevated space for this interaction to remain interesting. Treat this as a stylized sandbox. No injury simulation, disaster footage, or claims of predictive flood accuracy. ### F. Change the time of day Examples: > “Make it sunset.” > “Make it night.” > “Bring back the morning.” Transition sunlight direction, shadows, ambient color, windows, streetlights, and festival lighting together. Night should look beautiful without making the simulation unreadable. This is the visual finishing moment: the same town, recognizably transformed by light. ## 7. Natural-language interaction without pretending The app must work immediately without requiring an API key. Implement a capable local command interpreter for the supported action vocabulary. It should understand: - Common paraphrases and synonyms. - Named locations. - Numeric parameters within sensible bounds. - References to a selected object, such as “turn this into a park.” - Follow-up references such as “reopen it.” - Simple compound commands such as “close the north bridge and make it rain.” Do not implement only exact string matching against the displayed examples. Use a typed, validated action representation. Both language commands and direct UI interactions must go through the same action executor. If a command is ambiguous, offer a concise target choice. If it is unsupported, explain the supported possibilities without silently substituting another action. Do not use artificial typing delays, fake model responses, or “AI is thinking” animations for locally parsed commands. Make the mode discoverable with a small label such as **Local commands** and a brief explanation in Help. If the environment already provides a documented, secure model integration, you may add genuine AI interpretation into the same validated action schema. The local mode and complete showcase must still work without it. Never put API secrets in browser code, invent an unavailable host API, or execute generated JavaScript as commands. The simulation itself should run locally. Individual pedestrians do not need LLM calls. ## 8. Connected systems and readable consequences Use one authoritative world state. Weather, navigation, destinations, water, agents, and rendering should reference the same state instead of maintaining contradictory versions. Resolve competing goals consistently. For example, seeking shelter during a storm should take precedence over attending an exposed festival. Recompute affected routes when the network changes. Avoid recalculating every agent's entire path on every render frame. Whenever an intervention occurs, briefly identify the cause and make its consequences visible. Useful feedback could include: **North Bridge closed. Traffic is taking the southern crossing.** Only show a numerical claim when it is computed from the simulation. Do not invent happiness scores, environmental improvements, emissions reductions, or safety ratings. A few quiet live values are enough: people outdoors, vehicles waiting, and unavailable routes. The world should explain more than the metrics do. The animations may be carefully choreographed, but the outcomes must come from the simulation. ## 9. Direct manipulation and recovery Support: - Selecting landmarks and agents. - Opening a compact action menu on a landmark. - Closing a bridge directly. - Converting the supported parking site directly. - Adjusting weather, water level, and time through secondary controls. - Pausing, resuming, and changing simulation speed. - Resetting to the original world. Provide gentle camera pan, zoom, and limited orbit, with a clear reset-view control. Avoid letting casual gestures lose the town completely. Add **Undo last change**. Implement this as restoring a snapshot of the world immediately before the last intervention, including simulation time and random state. Explain this behavior in its tooltip. Do not pretend that undoing an old action can reverse every downstream consequence without restoring state. A full timeline editor is not required. ## 10. A reproducible showcase, not a fake video Include a **Play showcase** control that runs a roughly 30-second demonstration. Suggested sequence: **Opening:** The town is already alive. The camera establishes the whole scene. **First intervention:** “Start a festival in Central Park.” People begin converging on the park. **Second intervention:** “Now make it rain.” Weather changes. Umbrellas appear. People redistribute toward shelter. **Third intervention:** “Close the north bridge.” Barriers appear and approaching traffic visibly reroutes. **Final moment:** “Make it night.” Windows, streetlights, and festival lights illuminate the miniature. Tune pacing and simulation acceleration so each consequence is visible before the next command. Display each actual command in a readable, restrained caption. The sequence must be understandable without sound or narration. The showcase must call the same command and simulation systems used during normal interaction. Do not animate agents along special demonstration-only paths. Use a seeded initial state and timestamped actions so the sequence can be replayed reproducibly. User interaction should stop the showcase cleanly and leave the current world playable. Provide a **Cinema mode** that hides secondary controls while keeping the world and current command legible. Keep this simple; an in-app video editor or export pipeline is unnecessary. ## 11. Motion and feedback Treat motion as part of the explanation. Use: - Smooth turns and believable acceleration. - Gentle, coordinated site transformations. - Weather transitions rather than abrupt visual switches. - Subtle selection outlines. - Short route highlights when an agent is inspected. - Controlled camera movement during the showcase. - Clean transitions between day and night. Do not make everything bounce. Preserve enough visual continuity that people can follow an individual car or pedestrian through a change. A command should acknowledge immediately. Its visible effect should begin promptly; its downstream consequences can unfold over time. Respect reduced-motion preferences. Reduce decorative motion and camera movement without breaking the simulation's meaning. Keep sound off by default. The experience must stand entirely on its visuals. ## 12. Engineering and performance Use the existing project structure and supported runtime. For an empty standard frontend environment, React, TypeScript, and Vite are a suitable starting point. Three.js, directly or through React Three Fiber, is a suitable rendering direction when available. Choose the renderer early and commit to it. Do not build multiple rendering stacks. If the host imposes a different format, adapt while preserving the experience. Generate the essential geometry programmatically. Do not make the first usable experience depend on downloading external model packs, paid assets, maps, or fonts. Keep clear boundaries between: - World configuration and geometry. - Simulation state and updates. - Navigation. - Command interpretation and execution. - Rendering. - Interface and inspectors. Use a fixed simulation timestep with rendering interpolation. Keep simulation time independent of display frame rate. Use seeded randomness for simulation behavior. Snapshots and showcase replay must preserve it. Batch repeated geometry and use instancing or equivalent techniques where helpful. Avoid rerendering the whole React tree for every agent on every frame. Target smooth desktop rendering, with a graceful lower-detail mode for smaller devices. Reduce cosmetic particle counts and expensive effects before compromising the behavior. Handle resize, background-tab pauses, and restart cleanly. Prevent large time jumps when the tab becomes active again. Do not introduce a generic engine framework or elaborate infrastructure that this single world does not need. ## 13. Responsive design and accessibility On desktop, prioritize an unobstructed world and readable commands. On mobile, reframe the camera and collapse secondary controls. Do not merely shrink the entire desktop layout. The main interaction should remain usable at a narrow viewport without horizontal scrolling. Provide labeled controls, keyboard access to primary actions, visible focus states, and sensible touch targets. Do not rely solely on color to identify a closed bridge or flooded path. Avoid stealing keyboard shortcuts while someone is typing into the command bar. Keep a discreet About note: **A rule-based interactive sandbox, not a predictive model of real cities, human behavior, or flooding.** Do not imply that the app is a trained world model or that its local command interpreter is a live connection to Claude. ## 14. Implementation and completion Make reasonable design and engineering decisions without asking me to choose between libraries, palette variants, or minor layout options. Build the connected experience, not isolated placeholder sections. During longer work, provide concise milestone updates and continue implementation. Do not end at a progress summary that only announces the next step. Keep a short implementation checklist. A blocked optional enhancement should not prevent completing the required experience. Do not deploy publicly, purchase services, or alter unrelated project files. ### Completion criteria The deliverable is complete when: - The world loads in motion with a strong default composition. - All six interventions work through the shared action system. - Supported paraphrases and a compound command work. - Closing and reopening a bridge produces valid route changes. - Weather changes pedestrian behavior, not just the rendering. - Flooded navigation links become unavailable. - Reset and undo restore coherent state. - The showcase runs through the actual simulation. - Primary controls remain usable at desktop and mobile widths. - The app builds and has no observed blocking runtime errors. Run proportionate verification: type checking, a production build where applicable, focused logic tests, and a browser smoke test when browser tools are available. Inspect the actual rendered result, especially agent visibility, command readability, default framing, night lighting, and responsive controls. Fix observed defects and rerun the relevant checks. Do not claim to have tested visuals or performance that you could not inspect. Avoid unbounded review loops or unrelated refactoring. At delivery, provide the runnable result, concise startup instructions where needed, and any material limitations. Keep the explanation secondary to the app. ## Final creative direction This should not feel like a dashboard that happens to contain a city. It should feel like a small place that exists, continues moving, and reacts when someone intervenes. The defining moment is not simply that rain appears. It is that someone can follow a tiny person heading toward the festival, make it rain, watch that person seek shelter, close their bridge, and see them choose another path. **Build the world so the viewer's next instinct is: “What happens if I change this?”**

it started with a simulation of small world...

Du hast echt zu viel Zeit hahah

The premise make me snicker 🤭

Lmao what the helly? 😂

this stuff addictive haha

this is the version of “AI made a website” that I want more of. not a landing page. a toy. I went the other way: a coming soon page you drag until it shatters / turns to sand.

I see potential. Future of city building games maybe?

already working on it 🤡

Ok I’ll be your first beta tester, city builders are my thing

HOLY raise taxes

Fun

Are you using jev for decision making of each person independently?

adding this right now lol

Lovely. why 224?

guess claude just liked the number

could be interesting to feed in the events based on things happening in the world.

yeah there is so many more things i could do with it. might play around some more let’s see

This is gorgeous. Small World was my main reference for the world design in Latentown, an AI news town where every story becomes a building and couriers carry the day's news across the river 🏙️ Thank you for the inspiration!

My fck. Im blown. Followed.

interesting🔥

224 simulated residents feels way past tiny, you built a whole neighborhood council lol

Amazing job ! Feel of the city is really nice. What's missing in my opinion is chill soundtracks that changes based on weather and actions in the city. You could generate pretty good audios with gemini.

But how !!