Driving Unreal Engine Projects from Antigravity — Patterns from Building an Art Installation
Attaching Antigravity 2.0 agents to an Unreal Engine 5.5 project — across Blueprints and C++ — surfaced a real division of labor between editor work and agent-driven edits. Here are the patterns that actually held up through a live installation.
The Blueprint-and-C++ back-and-forth on my Unreal Engine 5.5 installation project got noticeably faster once I started routing it through Antigravity. The piece I'm building is a spatial exhibit whose rendering shifts in real time as visitors move through it, so the code centers on real-time rendering in a game engine and on designing how the scene responds to sensor input. I shape the artistic side by hand, but as an indie developer I've folded Antigravity into the code-level back-and-forth that sits underneath it. I've tuned that division of labor gradually, against the hardware these pieces actually run on at the venue.
Bringing Antigravity 2.0 in as an agent extended what I could reach inside an Unreal project — but game engines come with asset structure, Blueprint binaries, and long compile times that punish a "treat everything like web code" approach. Below are the failures I hit on the way and the patterns that hold up now, covering both prompt design on the agent side and project structure on the engine side.
Map what Antigravity can actually touch in an Unreal project
Antigravity edits text. Unreal projects mix text and binary, and that split decides what you can hand to the agent.
Text-side, fair game: .uproject (JSON), Config/.ini files, Source/ C++ (.h / .cpp / .Build.cs), Plugins/ metadata, shader code in Shaders/ (USF / HLSL), and project-management files like .gitignore. The agent can read, edit, and commit these directly.
Binary-side, hands off: .uasset and .umap, the binary part of Blueprints, textures, audio, motion capture, and other media. The agent cannot edit these directly. The workable pattern is for the agent to emit a written instruction sheet describing what needs to happen in the editor, which I then apply by hand.
Codifying this in an AGENT_SCOPE.md at the project root, plus an .antigravityignore that locks down binary assets, has saved me from at least two near-incidents where the agent was about to write into .uasset paths.
# .antigravityignore — recommended Unreal layout*.uasset*.umapContent/**Saved/Intermediate/DerivedDataCache/Binaries/*.pdb# Re-allow the text-side surfaces the agent should edit!Source/**!Config/**!Shaders/**!*.uproject!.gitignore!AGENT_SCOPE.md
Excluding Content/ wholesale and then re-allowing Source/, Config/, and Shaders/ keeps binary assets safe while leaving code and configuration fully under agent reach.
Tell the agent when to use C++ vs. Blueprints
The conventional Unreal split is: prototype gameplay in Blueprints, push stable core logic to C++. If you don't pin that down for the agent, it will reach for a Blueprint Function Library shortcut whenever it can.
In AGENT_SCOPE.md I spell out the division: new actors and components get their skeleton in C++ with UPROPERTY(EditAnywhere) for anything I'll want to tweak in editor; Blueprints call into those C++ functions; one-off numerical tuning and material parameters stay Blueprint-side; anything multiplayer-synced or saved goes through C++ from day one.
To keep that rule from drifting, I keep a prompt template at _agent_prompts/new_actor.md:
# New actor generation promptRole: You are the C++ implementation agent for an Unreal Engine 5.5 project.## Required rules1. Actors are C++ classes under `Source/<ProjectName>/Public/` and `Private/`.2. Anything tunable from the editor needs `UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Installation")`.3. Anything called from Blueprints needs `UFUNCTION(BlueprintCallable)`.4. Prefer forward declarations in headers; include in the `.cpp`.5. After adding a new `.h` / `.cpp`, verify whether `<ProjectName>.Build.cs` needs a new module dependency.## Output- Diff of generated files.- A written checklist of editor-side actions (deriving a Blueprint child class, placing components, etc.).
Routed through that template, the agent reliably stops at the C++ skeleton and emits an editor checklist under _agent_instructions/. Across the twelve new actor types in my current piece, none had to be rebuilt afterward for muddled C++/Blueprint responsibility.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦An honest map of what Antigravity can and cannot reach in an Unreal project
✦How to tell the agent when to write C++ vs. when to defer to Blueprints
✦Project conventions that make installation work reproducible on venue hardware
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
C++ builds on a substantial Unreal project run a minute or more. Telling Antigravity to "build and verify" drags the whole compile into its retry loop and burns through credits fast.
What I settled on: the agent never compiles. It emits a diff and stops. I run the build locally (Live Coding or Build.bat Development Win64) and feed the agent a short text result — "build succeeded" or "Foo.cpp:42 error C2065" — as the next prompt.
It looks inefficient on paper, but it cuts the agent's token usage materially. My measurements after switching showed AgentKit token consumption down 41% versus the "agent does the build too" workflow. On a $25/month credit plan that's a noticeable chunk.
# My local build script (macOS). Antigravity is NOT involved; I send only the error tail back to the agent."/Users/Shared/Epic Games/UE_5.5/Engine/Build/BatchFiles/Mac/Build.sh" \ MyInstallationGame Mac Development \ "${PWD}/MyInstallationGame.uproject" -waitmutex 2>&1 | \ tee /tmp/ue_build.log | tail -40
The trick is to feed back only the last 40 lines. Full logs eat context, and the agent gets distracted chasing warnings. A grep -E 'error C[0-9]+' pre-filter works well when builds are noisy.
Project conventions that make installation work reproducible
Installation pieces are usually first run on venue hardware that wasn't in the loop while developing — works on the studio Mac, doesn't launch on the gallery Windows box. Since I started letting Antigravity write code, a few conventions have proven necessary to keep reproducibility intact.
Branch hygiene is non-negotiable: a show/ branch for what will run at the venue, a dev/ branch for experiments. Any agent task starts by cutting a dev/ branch; merges into show/ are manual, by me. I learned this after the agent helpfully pushed into show/ once and the build failed the night before a rehearsal. Drawing the production-operation boundary explicitly is what makes on-venue improvisation tractable.
I split engine configs the same way. Config/DefaultEngine.ini stays untouched for the agent; venue-specific tuning lives in Config/_Production.ini, selected by launch argument:
When I ask the agent to "suggest settings for 4K / 60 fps at the venue," the diff lands cleanly in _Production.ini only. Dev configs stay intact, and the rehearsal-to-show delta is trivial to review.
Keep a manual layer between agents and sensor input
Installations react to depth cameras, motion sensors, or physical inputs over Arduino. The risk with letting the agent write that code is that it can't see the real sensor output, so it will guess at value ranges and get them wrong.
My pattern: write the C++ sensor-reading class as a skeleton only, and inject the actual range from a Blueprint at runtime. AGENT_SCOPE.md explicitly tells the agent: do not write normalization in C++; assume Blueprint will call SetSensorRange(min, max).
Pushing sensor-specific ranges into Blueprints means I can recalibrate at the venue from the editor, without going back to the agent. Fast iteration on site matters more than the elegance of an "all-in-C++" solution.
What to give up, what to delegate
After about five months of running this setup, the agent earns its keep in five lanes: C++ skeleton generation, Build.cs dependency wiring, shader experimentation, config-file organization, and Git branch hygiene. Blueprint detail work, texture tuning, actor placement, and camera moves are still faster and better in the editor by hand — handing them to the agent doesn't add value.
Once that line was clear, my prompts got shorter. Less surface for the agent to guess at, fewer off-target proposals. In the first few weeks, before I had that map, I kept asking for "everything," and most of the resulting work had to be redone in the editor.
For installation work, where the deadline and the artwork both have hard edges, the act of deciding what to delegate is itself part of the piece. Antigravity is a strong collaborator — but designing the split between agent and human is still a human job.
Where to go from here
If you're starting with Unreal Engine plus Antigravity, the highest-leverage 30 minutes you can spend is dropping in .antigravityignore and AGENT_SCOPE.md at the project root. Protect the binary assets, hand the agent C++ and configs, and you avoid runaway behavior from day one. Decoupling compile loops from the agent is the other big win — especially on a credit-based plan. Thanks for reading.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.