A client asked me a simple question about 3D building renderings. Four days later I was riding a bicycle through a virtual Piedmont Park, shooting drones and yelling at an AI model about steering sensitivity. This is the story of The Battle of ATL.
It Started With a Rendering Question
A client wanted to know whether modern 3D tools could produce more convincing renderings of buildings than the static images they were used to. That sent us into real-time rendering and, eventually, Unreal Engine. Unreal is famous for games, but it is also a serious visualization platform for architecture, terrain, lighting, vehicles, and interactive environments. We briefly looked at an intermediary tool called Aura, but the project quickly outgrew the extra layer. Working directly in Unreal gave us the control we needed.
So there we were with 3D geometry, Atlanta map data, real terrain, and a frontier AI model all sitting in the same conversation. Somebody asked the question that hijacked the project: how far could we push this before GTA VI comes out?
The answer took a little over four days of nearly continuous development, 97 builds, five AI usage resets, and 1.5 billion processed tokens. At the end of it, we had The Battle of ATL, an experimental indie game set in a version of Atlanta that people from here can actually recognize.
Those numbers make it sound like the AI did the work. It did a lot of it. But the more important half of the story is the hundred-plus messages of direction, the repeated hands-on playtests, and my flat refusal to accept a build just because it launched.
Paperboy Meets GTA in Midtown
The game opens on a residential street near Piedmont Park. Ellison, the main character, is learning the basics: ride, walk, run, jump, crouch, get on and off his bike. It is a quiet stretch by design. The player gets to figure out the controls before reaching the stone arch at the 14th Street entrance to the park.
The setup is simple. Ellison dropped his phone while playing frisbee. The Find My app on his watch points in the general direction but will not give him an exact spot. When he rides into the park, the clock starts. He has to find the phone and get to Morgan's party at 98 Estoria near Krog Street Tunnel before time runs out.
The route runs through Midtown, Piedmont Park, the city's most popular bike path, a couple of genuinely dangerous road crossings, and on toward the tunnel. The beta ends there, but the larger route is already mapped for later.
Someone described it as the 1980s Paperboy meeting GTA in Atlanta. That sounds ridiculous, and it is, which is most of the appeal. It is also accurate: bicycle handling, exploration, a timer, obstacle avoidance, third-person shooting, strange street encounters, and a distinctly Atlanta sense of humor.
This Was Not a One-Prompt Game
It would be a better headline if I told you I typed one giant prompt and came back to a finished game. That is not what happened.
The initial prompt set a direction. Everything that made the game specific came from the conversation afterward. I fed the model a constant stream of gameplay rules, location corrections, story beats, jokes, priorities, and test reports. Some messages were a single fix. Others laid out a whole interconnected system.
I defined Ellison and Morgan, the lost-phone premise, the watch-based search, the timed ride, and the idea that the player should learn in the neighborhood before the real clock begins. I specified that Ellison is a Black man and corrected the ending when the wrong characters showed up. I named businesses, changed names that felt legally risky, moved the park entrance to the correct street, and stopped development more than once to make sure the route actually matched the map.
The gameplay direction was just as detailed: WASD and arrow keys, mouse aiming, on-foot running, jumping and crouching, a weapon that has to be drawn instead of always being out, 17-round magazines, stored ammo, spare bicycles, natural steering, low-speed balance, faster downhill riding, ramps, speed boosts, limited horn charges, automatic lights, swimming, drones, police responses, scooters, roller skaters, dogs, ducks, traffic, potholes, crowds, and time bonuses.
Those were not a wish list. I kept defining how they related to each other. Shooting a zombie earns time; shooting a pedestrian costs time and brings the police. The timer runs faster on foot. A drone has to be visible far enough out that you can decide to shoot it. Arcade bike mode should forgive bumping into scenery, but hostile characters can still knock you off. The watch flashes as you get closer to the phone. The horn scatters crowds, so it needs limited charges.
That is what turns a pile of mechanics into a world with rules.
Local Knowledge Became Map Data
Some of the most useful information in the project never existed in any geographic file. I have ridden these streets for years. I know which hill should feel fast, where a path bends, which entrance has the stone arch, how 13th and 14th connect, and where a route that looks reasonable on a screen feels wrong when you are actually on a bike.
I flagged the Monroe crossing as dangerous because it is. I pointed out another rough crossing near Lake Avenue and Irwin Street, and the intersection by Krog Street Tunnel where scooter riders regularly go down. That turned into an occasional crashed rider surrounded by people trying to help. Some of the less charming things you see around Midtown at night became environmental storytelling too, including the occasional bench fire. I had a prominent apartment building on the route represented and renamed it The Fancy Roach Motel, for reasons anyone who has lived in Midtown will understand.
The farmers market near the 12th Street entrance explained why vendors might later show up inside the park. The bowl, the road-race character of 10th Street, the bike lane, the lake, the neighborhoods, the kinds of people and obstacles you actually encounter: all of that came from having been there, not from a "generic Atlanta" theme.
One hidden encounter on the route has a more serious origin, and we built it to feel rare, strange, and respectful rather than becoming another pickup. I am leaving the details for players to find. The point is the process: a real memory became a rule, a location, a mood, and a limit on what the player is allowed to do.
That is the kind of context an AI model simply does not have. It can read a map. It cannot remember what it feels like to ride down that hill.
We Did Not Build a Generic Park
The goal was a place an Atlantan could recognize. We studied maps, aerial views, streets, entrances, paths, buildings, intersections, and photographs, and cross-checked all of it against my own memory of riding through.
The world includes the 12th, 13th, and 14th Street approaches, the 14th Street stone entrance, the lake loop, the steep bowl inside the park, the 10th Street hills, the Monroe crossing, the route toward Krog Street, and the tunnel itself. We placed recognizable apartment buildings, neighborhood businesses, the farmers market area, traffic, bike lanes, benches, trees, fences, ramps, and the skate park in relationships that make sense.
Some names changed for the game. Familiar places became Billy's, Murder K, The Fancy Roach Motel, and 98 Estoria. Midtown roads outside the playable beta are blocked with construction signs and "coming soon" messages, because an invisible wall is less funny and less useful than a believable boundary.
Getting this right meant more than tracing lines. A line on a map has no width, collision, slope, shoulder, material, or connection to the ground under it. We projected the route into one Unreal coordinate system, shaped terrain beneath it, built rideable surfaces, and then rode it over and over. Paths floated. Intersections pinched shut. Buildings landed on the wrong side of the street. A harmless curb could trap the bike. Every failure sent us back into the world model.
Atlanta Hills Had to Feel Like Atlanta Hills
Elevation turned out to be one of the most important details. The bowl in Piedmont Park has a real drop, and the 10th Street hills will push a bicycle to its actual top speed. Flatten those and the route loses its identity. Overdo the grade and you cannot climb back out.
We reshaped terrain, tuned downhill acceleration, adjusted climbing, and tested transitions between pavement, grass, ramps, bridges, and road. Potholes went in as occasional hazards, because a perfectly smooth Atlanta road would have been the least realistic thing in the game.
The skate park became our physics lab. It gave us a contained space to test speed, gravity, ramps, jumps, landings, collision, and how much time a player should earn for catching air.
Making the Bicycle Fun Took Dozens of Revisions
The bicycle was the hardest system because everyone knows instantly when steering feels wrong. Early turning was jerky and oversensitive. The bike was too slow, leaned unnaturally, stuck to walls, and sometimes could not reverse or turn around. Bridges exposed problems normal paths did not. The seat passed through the rider. When the bike stopped, his feet never came down.
We reworked steering, acceleration, braking, reversing, low-speed balance, lean, collision recovery, jumping, and mounting and dismounting. The game now has both an arcade mode and a more physical riding mode. In arcade mode, trees and scenery stop throwing you off the bike, but hostile characters and serious hits still can. Speed boosters, ramps, jumps, recoverable and spare bicycles, lights, gears, and limited horn charges keep the ride varied.
The horn scatters pedestrians, but you start with two charges and have to find more. The bike light comes on automatically where it matters, including the darker tunnel sections.
Two Games in One Character
Ellison had to work both as a cyclist and as an on-foot third-person character. Early versions failed hard here. The player could move forward but could not turn with the mouse. Arms and hands looked wrong. The gun was out when it should have been holstered. There were no instructions for the new controls.
We added mouse look and aim, keyboard turning, walking, running, jumping, crouching, drawing and holstering, and context-sensitive instructions that change when you get on or off the bike. You can pin the instructions permanently, but the default interface stays quiet enough to see the world.
Time also behaves differently on foot. The clock runs noticeably faster once Ellison is off the bike, so you dismount only when it is worth the risk.
Animations Were Their Own Project
We evaluated free and licensed character packs, Fab assets, Epic animation packs, and Mixamo motion libraries for walking, running, falling, fighting, dancing, crouching, swimming, getting hit, and getting up.
Retargeting those onto different characters produced some memorable disasters. Characters dissolved. Feet pointed backward. Hands twisted. One punk rocker somehow looked fine standing on reversed feet. A guitar player looked so wrong he got his own line item in the next build.
It is funny in hindsight, but animation quality holds the whole game together. Falling off a bike, getting tased, swimming back to shore, mounting up, drawing a weapon, or just walking all have to connect naturally or the player stops believing the world.
Rules, Consequences, and Surprises
The route is populated with pedestrians, cyclists, scooter riders, roller skaters, dogs on leashes, ducks, traffic, park visitors, street characters, zombies, police, drones, and faster "hyper bikes." Some are obstacles. Others react to you.
You start with 17 rounds and can find more ammo in believable places like trash cans. Other weapons can be discovered. Shooting a zombie earns time. Shooting an innocent person costs time and brings trouble. After enough violence, police arrive, warn you, draw tasers, and try to stop you. Their response had to be tuned so they did not show up instantly or shoot with impossible accuracy.
Drones were rebuilt so you can see them coming, judge the distance, and choose to evade or shoot. A drone hit can knock you off the bike and burn valuable time. Tasers produced one of my favorite bugs: Ellison got hit mid-jump and froze in midair, which led to another round of physics and state-recovery fixes.
The park also holds timed bonuses, speed boosts, jumps, water, swimming, spare bikes, occasional fires, potholes, crowds, and hidden encounters. Some happen every run. Others are probabilistic so repeat playthroughs do not unfold the same way. A few of the stranger Atlanta moments are deliberately staying out of the marketing.
Sound, Interface, and Story Had to Work Together
Two original tracks went into the project. The M key cycles between songs and silence, and the interface tells you that control exists. Bike lights, the horn, gunfire, warnings, the tracking watch, countdown messages, and police encounters all needed clear audio or visual feedback.
The interface went through several redesigns. Early text was faded, crowded, and sometimes escaped its container. Control lists ate the screen. The current version shows only essentials and lets you open a full help display when you want it. The build number is always visible, because every playtest report has to name the exact version.
The watch flashes as Ellison closes in on the phone. The timer starts when he enters the park, with a clear notice that the game has begun. The ending had to recognize arrival, play the celebration, and show Ellison with Morgan instead of swapping in the wrong characters.
The Most Important Tool Was Playtesting
The first playable builds were bad. Controls were stiff. Characters moved badly. The bike got stuck against walls. Swimming looked wrong. Drone attacks meant nothing because you never saw them coming. The landscape felt generic. The interface was unreadable. Reaching the end sometimes did nothing.
We did not hide those failures. They were the work list.
Every test produced specific notes: steering too sensitive; mouse aim broken; police arrive too fast; timer too long; fence too tall; bowl too shallow; bike cannot jump on a hill; character freezes when tased in the air; seat cuts through the rider; instructions disappear at the wrong time; finish trigger fails.
I did not soften any of it for the machine. When a build played badly, I said so. When characters looked cheap, the interface was unreadable, or an animation looked like a kid made it, I said that too. That bluntness kept "it compiles" from being mistaken for "it's good."
I also said when things worked. When the ride got fun, the drones became readable, and the humor started landing, I called it out so those parts survived the next revision.
That specificity is what makes an AI useful. "Make the game better" produces guesses. "The bike cannot reverse after hitting a wall" produces a problem that can be reproduced, fixed, and tested.
The Conversation Was the Design Document
Traditional game development starts with a locked design doc. This project ran on a living conversation. New ideas arrived while old systems were still being tested. A note about unreadable text became an interface redesign. A complaint about being unable to dismount exposed missing instructions. A request for more realistic bike crashes expanded into animation, collision, recovery, and difficulty rules.
The conversation also preserved decisions that would otherwise have evaporated: the title became The Battle of ATL; Ellison and Morgan became the leads; the beta started as a Mac-only build; the site carries Web Experts branding; the TestFlight link started out hidden behind email verification; Murder K stays out of the marketing; and the guitar player's broken animation goes on the next build list. Two of those decisions have since been reversed. The beta runs on Windows and Mac now, and the TestFlight invitation is public.
This was intense because the model was not just generating code. It was maintaining continuity across geography, story, controls, physics, animation, interface, release engineering, marketing, and distribution while I kept moving the target.
What GPT-6 Astra Actually Did
GPT-6 Astra worked across code, Unreal project structure, gameplay logic, interface revisions, map research, debugging, packaging, release notes, website development, and the TestFlight process. It could inspect a problem, make a change, build the project, launch it, take feedback, and revise again.
We ran it hard for more than four days. 1.5 billion tokens, five resets, 97 builds. That build count is not ceremonial. It is 97 points where the project had to become concrete enough to run, inspect, reject, or improve.
The model did an enormous amount of work. It did not replace judgment. It could write a steering system in minutes. It could not feel that the bike was unpleasant to control. It could place an apartment building. It could not know it looked wrong to someone who has ridden past it a thousand times. It could wire up animation states. It could not know the guitar player looked ridiculous until a human told it.
AI compressed the gap between an observation and a new build. I supplied the world, the rules, the taste, and the refusal to stop at "technically works."
From Development Build to Mac Beta
A game running inside Unreal Editor is not something people can test. It had to become a standalone Mac app with no engine required.
That meant packaging in Shipping configuration, setting the final bundle ID, keeping saves inside Apple's allowed container, stripping dev-only controls, checking asset and music licenses, creating the icon, adding pause and quit behavior, testing display options, signing the app, building the installer, validating in Xcode, and uploading to App Store Connect.
Build 096 became the first signed TestFlight candidate. Apple processed it, and the external public beta went into review. The public site needed its own system: landing page, mobile layout, screenshots, video, a four-question signup, six-digit email verification, protected TestFlight access, and a feedback form. A separate worldwide version was built at WebExperts.ai because the primary company site limits international traffic.
That gate is gone. The beta page was rebuilt around an open beta: Windows and Mac, no signup, no email, no code, and both downloads public.
None of that makes the bike turn better. All of it is required before another human can install the game and tell us the bike still needs work.
What I Learned
The Battle of ATL shows how much a small team can attempt when a frontier model is allowed to work across an entire project instead of answering isolated questions. It also shows exactly where the hype ends.
Fast output is not finished work. A real product still needs direction, memory, taste, testing, licensing, packaging, distribution, error recovery, and somebody willing to say "this is not good enough yet." The model accelerated every one of those steps. It did not make a single one disappear.
Most of our clients are not asking for a video game. They are asking whether an unusual idea can become real software without spending a year finding out. This project gave us a demanding answer: build the smallest real version, put it in front of a person, listen carefully, and make the next one better.
Try The Battle of ATL
The beta is free and open on Windows and Mac. No signup, no email, no code: the Windows build downloads from a public GitHub page, and the Mac build installs through Apple TestFlight.
Visit The Battle of ATL beta page to pick your platform, see the project, and tell us what should change next.
If your company has an idea that sounds slightly unreasonable, that may be the right place to start. Learn more about our Atlanta AI development services or contact Web Experts.