Road Trip: Ahead One

Take the slow lane.

Road Trip: Ahead One is a browser-based idle and companion game about making steady progress on a journey, collecting small reminders of the trip, and sharing quiet company. The scenery supports that experience: a changing roadside world makes the passage of idle time feel like travel and gives players an immersive sense of presence. I developed it independently as an AI-assisted project, bringing together game design, technical art, procedural systems, and the engineering needed to keep a journey running.

Work in progress. This case study covers development through September 8, 2026, including newer implementation work that is not yet documented as a verified public release.

Table of Contents

• Project Overview
• Designing for the Slow Lane
• Art-Directed Procedural Worlds
• Tools for Safe Visual Iteration
• From AI Geometry to Runtime Vehicles
• Materials, Lighting, and Visual Continuity
• Profiling and Runtime Optimization
• Persistent Journeys and Quiet Social Play
• Directing an AI-Assisted Development Workflow
• Current Results and Next Steps

Project Overview

The road network connects 20 cities through 26 bidirectional roads, stretching from the Pacific coast toward the Midwest. Players choose a destination, follow a multi-city itinerary, visit shops, customize vehicles, and earn mileage while the journey advances both online and offline.

Crimson Cap in the roadside world — a local production-renderer QA capture showing the vehicle, road, vegetation, ground and lighting together.

My responsibility extends from the experience and visual direction to the systems that support them: procedural world generation, asset specifications, Blender-to-Three.js integration, rendering, artist-facing tools, interface implementation, persistence, and release validation.

The project began as a smaller road-trip prototype and grew into a persistent Three.js world backed by Cloudflare D1 on ChatGPT Sites. That growth introduced the central production problem: each new landscape, vehicle, or visual adjustment had to coexist with existing saves, active journeys, and earlier content revisions.

For me, the most valuable part of the project is that connection between content and runtime. A convincing landscape is not only a collection of models; it also depends on placement rules, camera composition, resource ownership, and tools that make iteration practical.

Designing for the Slow Lane

The phrase "Take the slow lane" became the design filter for the whole game. I wanted a sense of companionship and forward movement without racing pressure, constant objectives, or an interface that demanded continuous attention.

The visual direction developed into a warm, low-saturation Low Poly world. Oat, cream, terracotta, sage, and mist blue carry through the scenery and interface. Road signs, tickets, stamps, paper textures, and display plinths give menus a travel-related identity while leaving the road as the main visual focus.

Ahead One world-style concept showing friendly vehicles and a warm Low Poly roadside landscape

Visual-development reference, not an in-game screenshot. The concept establishes silhouette, color, scale relationships, and the intended roadside atmosphere.

Figma Make and concept exploration helped establish the direction, but the production interface was rebuilt around real game state. A single Three.js world remains mounted behind the map, shop, garage, and other floating panels. Opening a menu changes the information hierarchy without restarting the scenery or interrupting the journey.

The same principle shaped the surrounding experience. Loading uses the approved branded road illustration, but its progress comes from actual initialization and resource readiness. Scenic Pass hides the interface for an unobstructed drive. Procedural road audio and licensed music support the atmosphere; sound starts after player interaction, and music lowers beneath functional panels without resetting its timeline.

Responsive design was part of that work rather than a separate skin. Desktop panels preserve a broad view of the road, while narrow screens share a coordinated bottom safe area so navigation, journey actions, and expanded details do not compete for the same space.

The in-game Garage — a fresh local main-application capture showing the selected vehicle and decoration slots while the journey continues behind the panel.

Art-Directed Procedural Worlds

The world needs variety, but its variation also needs structure. A roadside town, a field, and a forest should read as places along a journey rather than unrelated objects scattered beside an endless strip of asphalt.

I organized each canonical route into continuous regional spans, including suburban frontage, towns, agriculture, energy infrastructure, and natural scenery. Within those spans, reusable assets form recognizable arrangements: civic anchors and residential lots, aligned crop fields, paired grain infrastructure, compact solar fields, and grouped ranch facilities.

Roadside props from the integrated asset library — a grain elevator, billboard, wind turbine and twin grain silos. Isolated model renders show the silhouettes and structural details without terrain tiles.

These landmarks do different compositional jobs. Buildings and grain infrastructure give a location a recognizable identity, billboards create roadside accents, and wind turbines add distant vertical rhythm. Their measured dimensions let the planner place them as coherent groups while keeping their silhouettes readable from the driving camera.

Stable rules beneath the variation

The planner and asset pipeline share a Y-up coordinate system, a 3.5-meter grid, and quarter-grid placement increments. Assets carry measured footprints, front directions, permitted rotations, and conservative occupancy bounds. Multi-part arrangements are placed as a unit so a ranch or paired facility cannot be left half-built by a collision rejection.

Stable seeds reproduce the same roadside composition after a refresh. Separate random streams isolate vegetation, buildings, rocks, and other content categories, allowing one category to change without unnecessarily rerolling the others. Forward and reverse travel share a canonical layout, and objects crossing streamed-chunk boundaries have a single owner.

The farm windpump shows the preparation behind a reusable animated prop. Its generated source contains 999,766 triangles. The delivered 20,000-triangle model carries baked 1024-pixel PBR maps and separates the stationary body from a 7,000-triangle rotor. That separation gives the runtime an explicit moving part while preserving the asset's footprint.

Farm windpump: generated high mesh → baked low mesh → topology review → separated body and rotor. Newly rendered from the existing source and delivery GLBs with a shared camera; wireframe, colors and exploded offsets are diagnostic views.

Composition remains an art decision

Determinism does not decide what looks good. I iterated on near-road density, building scale, mountain bands, road-facing orientation, and the relationship between foreground detail and distant silhouettes.

Recent work replaced sparse solar scattering with compact two-sided fields and brought forest and meadow backdrops closer to the road. Correcting an undersized motel also meant updating its placement bounds, not simply enlarging its rendered mesh into neighboring content.

Camera-side suppression and frustum culling happen after planning. An object hidden to improve the view retains its spatial reservation, keeping composition adjustments from destabilizing the underlying world.

Tools for Safe Visual Iteration

As the asset library expanded, editing values in code became an increasingly poor way to judge a scene. I developed Environment Lab to bring placement, material, lighting, and weather decisions into the running world.

The tool separates environment assets, regional ground, road surfaces, vehicles, rain, and lighting into independent tuning areas. Color, contrast, surface response, and visual scale can be evaluated in context. Shader adjustments use stable uniforms where appropriate, and assets that finish loading later inherit the active settings.

Farmer's market stall — placement specification and a newly rebuilt low-poly preview derived from the original high mesh. The marked footprint, front edge and origin connect authoring to placement.

The workflow supports automatic generation alongside manual placements and exclusion regions. Draft preview, section-level restoration, and publishing are separate operations. Closing the tool can retain the last successfully loaded or saved preview, while unsaved edits fall back to that known state.

Versioning is part of the tool design

Asset manifests record file identity, measured bounds, orientation, and runtime behavior. New binaries use new public paths, and published environment revisions remain immutable. A visual change therefore does not silently replace the assets behind an older journey.

Release behavior is explicit: some migrations deliberately upgrade active drives, while ordinary publishing can leave a current leg pinned to its existing revision. Restore produces a new draft instead of rewriting history.

This separation matters because a live world has more than one valid state. The latest artistic direction, an administrator's draft, and the environment attached to an existing trip must be able to coexist. The tools make those states visible and allow iteration without treating every adjustment as a destructive replacement.

From AI Geometry to Runtime Vehicles

The latest eight-car integration became a focused example of the gap between an appealing generated model and a controllable game asset.

The asset-generation workflow moves from Seed3D or Meshy into Blender for review and preparation, then into semantic part separation and game integration. Separating the body, glass, trim, lamps, and wheels makes it possible to add wheel animation and steering while tuning paint, glass, and lighting responses independently in the game.

Vehicle asset pipeline — Seed3D or Meshy → Blender → semantic parts → game integration → animation and material tuning.

I used multi-view references and AI-generated geometry to explore vehicle forms, then evaluated them from fixed views before moving into runtime preparation. Several technically valid approaches failed that visual review: procedural reconstruction lost important proportions, while automatic splitting and remeshing could damage silhouettes or introduce visible seams. Passing a mesh check was not enough to preserve the character of the design.

Petal Hopper's approved multi-view design reference — side, front, rear, top and three-quarter views establish the proportions before geometry review.

Petal Hopper preparation records — the dense textured shape master and the accepted 29,020-triangle remesh input. These offline views show different material states; the remesh is an input to semantic assembly.

After semantic preparation in Blender, the accepted handoffs were adapted to a shared runtime contract while preserving their geometry. The current fleet uses a textureless material setup with separately identified body, glass, trim, lamps, and wheel components.

Making the model respond correctly

Body paint is isolated from glass and trim. Lamp materials follow the existing day/night behavior, and measured headlamp anchors connect the models to the game's practical lights. A normalized wheel template supports rolling, front-wheel steering, and grounded placement.

Accepted Petal Hopper part review — semantic colors and an exploded view expose the assembly; red-paint and wheel-transform tests check independent controls. The completed assembly contains 55,544 triangles after cuts, closures and wheel preparation.

The five existing accessory types also needed per-car mount measurements. Curved roofs, luggage height, and antenna conflicts made a single shared offset unreliable. The new mounts connect those decorations to each vehicle while retaining the player's existing inventory and equipment relationships.

The five accessory assets — roof rack, surfboard, travel luggage, antenna and spoiler. These are UI thumbnails rendered from the actual GLBs, linking the menu representation to the equipped model.

Checking the attachment after integration — Snowcap Nook with travel luggage in a controlled reverse-drive QA scene. This view makes roof clearance and the combined silhouette reviewable in context.

Runtime integration extends beyond the driving scene. Starter selection, Garage, and Shop use thumbnails rendered from the actual models. Vehicle definitions provide the same identity across those views, while geometry and reusable resources remain shared. Actor-owned paint and lamp materials can vary independently, and asynchronous load guards prevent an obsolete vehicle request from replacing a newer selection.

Preserving quality under delivery constraints

The fleet upgrade retained the accepted geometry rather than claiming an unfinished reduction or LOD pass. When the release archive exceeded the hosting budget, compressing the server-rendering bundle made room without deleting historical assets or degrading the approved vehicle shapes.

The result is an integrated eight-car runtime, not a claim that every art-production problem is finished. Further topology review, accessory refinement, and broader visual coverage remain part of the WIP. The useful pipeline outcome is a clearer boundary between generated shape, artistic acceptance, semantic assembly, and game behavior.

The eight accepted semantic vehicle assemblies, rendered offline for delivery review. Final totals range from 42,676 to 67,880 triangles; the earlier 30k remesh target is not the final assembled budget or a completed LOD system.

Materials, Lighting, and Visual Continuity

Much of the visual improvement came from relationships between assets: the palette of a mountain region, how a surface responds to weather, and whether a vehicle has convincing contact with the ground.

Regional ground uses PBR material sets and route-aware transitions. Planting-bed edges blend into surrounding surfaces, while concrete and gravel retain intentionally harder boundaries. Weather drives a damped wetness response across lit surfaces, changing color and specular response without replacing the configured dry-weather look.

Mountain rock material preparation — source artwork, processed base color, normal and roughness maps, and a 3×3 tiling check. The warm-rock material uses 1024-pixel maps and a 7×7-meter repeat in the mountain-region material setup.

The source image is only the beginning of that material. The pipeline repairs the repeating boundary, derives periodic normal and roughness maps, and checks the rock pattern across multiple tiles before it is judged with the region's lighting and surrounding assets.

Lighting has similar constraints. The scene needs readable daylight, dusk, and night, but moving scenery and a long-running camera make unstable shadows especially noticeable. Cached sun and moon shadow snapshots, road-scroll compensation, and separate vehicle contact shadows address different parts of that problem. Practical lights stay bounded, and semantic lamp materials keep illumination attached to the intended parts of an asset.

Profiling and Runtime Optimization

A calm game makes interruptions conspicuous. Even when average frame rate looks acceptable, a short stall during a vehicle entrance or lighting change can break the sense of continuous travel.

I added an Admin-only diagnostic workflow to separate CPU work, GPU cost, long tasks, draw calls, pixel load, and shader-program activity. Timed logs and cold-context comparisons made it possible to investigate first-use behavior separately from an already warmed scene.

Diagnosing before choosing a fix

One recurring question was whether a hitch came from steady rendering cost, resource loading, or compiling a new lighting configuration. Normal and deferred warmup experiments used fresh WebGL contexts so a previous run's compiled shaders would not make the comparison misleading.

The resulting work included prewarming bounded headlight configurations and scheduling eligible later warmup during idle time. This complements resource pooling; it does not replace it. Road chunks, traffic actors, and lights still need controlled lifecycles, and delayed asset loads must not attach themselves to recycled objects.

Budgeting around the experience

Night traffic illustrates the tradeoff. The renderer supports a bounded number of vehicle-headlight pairs. When two long-term Roadmates occupy the scene, the traffic policy removes the oncoming slot rather than removing a friend's vehicle or leaving a visible car without headlights.

Night lighting with Roadmates — the leading companion travels in the adjacent lane, with another behind the player. A fresh production-renderer review capture.

Other controls address different costs: manual render scaling reduces pixel work, frustum-driven visibility limits unnecessary scenery, and shared GLB resources avoid repeated allocation. Resize behavior preserves the chosen render scale instead of silently reverting it. These are explicit controls, not a claim of automatic adaptive quality or a completed fleet-wide LOD system.

Keeping the results honest

Cold-start coverage, longer day/night runs, and representative target-device checks remain unfinished. The most reusable result so far is the diagnostic process: identify which cost changed, reproduce it under controlled conditions, and keep visual improvements tied to measurable runtime behavior.

Persistent Journeys and Quiet Social Play

The relaxed surface depends on reliable state underneath. D1 owns journey progress, mileage, purchases, vehicles, and equipment. Offline settlement advances the trip across road legs and city stops, while request receipts and atomic spending protect purchases from retries and concurrent actions.

The map and active-journey panel alongside the running world — a fresh local main-application capture with the leading Roadmate in the adjacent lane.

Saves are distinct from devices and accounts, allowing guest play and recovery without casually merging independent progress. Vehicle ownership is instance-based: two copies of a model can carry different equipment, and switching the active car does not move decorations between them.

The newer Roadmates system provides two independent reciprocal connections. Brief automatic encounters create passing company; accepted friend invitations support longer shared trips. Friends-only and Go solo make companionship a choice. Logical connections are separated from physical scene placement, so a friend can remain connected during a non-driving stopover without requiring a driving actor in the scene.

Recent journey controls add another form of player agency. Interrupting a trip first settles earned progress, then returns the player to the current leg's departure city without awarding completion. Remote departures provide a limited free allowance before a clearly quoted points cost. Both are implemented features awaiting publication in the September development record.

These systems serve the same product goal as the interface: players should be able to leave, return, change plans, or enjoy company without turning the game into a demanding social or competitive obligation.

Directing an AI-Assisted Development Workflow

AI assisted with implementation, visual exploration, geometry generation, debugging hypotheses, documentation, and test development. My role was to define the goals and constraints, evaluate the results, and connect the individual outputs into a coherent game.

I organized the work around bounded production problems, each with a reviewable result and explicit acceptance criteria.

For each problem, I established what could change and what had to remain stable. Fixed-view art review, runtime inspection, regression tests, and build checks then provided different kinds of evidence. None could substitute for all the others.

Failures became part of the process documentation. An unsuccessful remesh helped clarify the visual acceptance gate. A migration that worked in local SQLite but failed in the hosted executor became a deployment constraint. A late asset load attaching to the wrong scene generation became a lifecycle regression test.

The same delivery discipline applies to smaller 2D assets. A collectible illustration still needs background removal, alpha review and a bounded WebP export before it can work as a menu icon. The Seattle gift below preserves those stages instead of presenting generation as the whole workflow.

Seattle Space Needle gift icon — generated source artwork → prepared alpha cutout → optimized UI WebP. The cutout is displayed against the review board so its transparent boundary can be inspected.

This is the aspect of AI-assisted development I want the project to demonstrate: faster exploration is useful when it is paired with explicit ownership, reviewable decisions, and a maintainable interface between content and code.

Current Results and Next Steps

Ahead One is publicly playable, with an integrated procedural world, eight-car runtime, persistent progression, and a growing set of authoring and diagnostic tools. The newer implementation work described here is broader than the latest release state verified in the development records.

I have also established an art-QA entry point that uses the production renderer with repeatable recipes for vehicles, attachments, direction, weather, and lighting. Fixed captures and main-application checks provide a baseline for comparison without treating a concept image or isolated model preview as proof of the complete experience.

Integrated review coverage — daytime road contact, reverse travel at dusk, staggered Roadmates at night, and rain with a surfboard on a narrow viewport. These are controlled production-renderer fixtures.

The next priorities are:

• Refine vehicle topology and accessory fit, and expand visual coverage across car-and-accessory combinations.
• Refine environment composition and material consistency across more regions.
• Complete cold-start, sustained day/night, and target-device performance checks.
• Verify pending work through the full migration and public-release process.

The project remains WIP. Its value as a technical-art case study is the connected workflow: turning visual intent into reusable assets and procedural rules, giving those systems practical tools, and improving the result while respecting a running game's constraints.