Antigravity × Unreal Engine 5 — A Complete Integration Guide for Builders

Chapter 3: C++ generation — Epic conventions are surprisingly well respected

C++ output adheres to Epic's coding conventions to a degree that genuinely surprised me. UCLASS, UPROPERTY, UFUNCTION macros, header/implementation splits, forward declarations — all rendered at a quality that holds up next to Epic's own sample projects.

A simple AI controller, generated end-to-end:

// EnemyAIController.h
#pragma once
 
#include "CoreMinimal.h"
#include "AIController.h"
#include "EnemyAIController.generated.h"
 
class UBehaviorTree;
class UBlackboardComponent;
 
UCLASS()
class MYGAME_API AEnemyAIController : public AAIController
{
    GENERATED_BODY()
 
public:
    AEnemyAIController();
 
protected:
    virtual void OnPossess(APawn* InPawn) override;
    virtual void Tick(float DeltaSeconds) override;
 
    UPROPERTY(EditDefaultsOnly, Category = "AI")
    UBehaviorTree* BehaviorTreeAsset;
 
private:
    UPROPERTY()
    UBlackboardComponent* BlackboardComp;
 
    void UpdatePerception();
};

// EnemyAIController.cpp
#include "EnemyAIController.h"
#include "BehaviorTree/BehaviorTree.h"
#include "BehaviorTree/BlackboardComponent.h"
 
AEnemyAIController::AEnemyAIController()
{
    PrimaryActorTick.bCanEverTick = true;
}
 
void AEnemyAIController::OnPossess(APawn* InPawn)
{
    Super::OnPossess(InPawn);
 
    if (BehaviorTreeAsset && BehaviorTreeAsset->BlackboardAsset)
    {
        UseBlackboard(BehaviorTreeAsset->BlackboardAsset, BlackboardComp);
        RunBehaviorTree(BehaviorTreeAsset);
    }
}
 
void AEnemyAIController::Tick(float DeltaSeconds)
{
    Super::Tick(DeltaSeconds);
    UpdatePerception();
}
 
void AEnemyAIController::UpdatePerception()
{
    // Player line-of-sight check + Blackboard updates
}

Header order, the MYGAME_API macro, forward declarations — the small things UE5 C++ developers know about but often skip are all done right.

That said, compile errors are not zero. In my experience, 10–20% of generated code needs some manual tweaking — usually around include paths or API signature differences across UE5 minor versions.

Chapter 4: Runtime AI — wiring Antigravity into in-game NPCs

This is where the integration starts to feel transformative. Calling Antigravity's API at runtime lets you delegate NPC dialogue and decision-making to the model.

The base structure

// AntigravityNPCComponent.h
#pragma once
 
#include "CoreMinimal.h"
#include "Components/ActorComponent.h"
#include "AntigravityNPCComponent.generated.h"
 
UCLASS(ClassGroup=(AI), meta=(BlueprintSpawnableComponent))
class MYGAME_API UAntigravityNPCComponent : public UActorComponent
{
    GENERATED_BODY()
 
public:
    UAntigravityNPCComponent();
 
    UFUNCTION(BlueprintCallable, Category = "AI")
    void RequestDialogue(const FString& PlayerInput);
 
    UPROPERTY(BlueprintAssignable, Category = "AI")
    FOnDialogueResponseDelegate OnDialogueResponse;
 
protected:
    virtual void BeginPlay() override;
 
    UPROPERTY(EditDefaultsOnly, Category = "AI")
    FString CharacterPersona;
 
    UPROPERTY(EditDefaultsOnly, Category = "AI")
    FString ModelName = TEXT("gemma-4");
 
private:
    void HandleAPIResponse(const FString& Response);
};

The implementation uses HttpModule to POST to the Antigravity HTTP endpoint. Asynchronous handling is mandatory — anything blocking on the game thread will tank your frame rate.

The three rules I learned the hard way

Rule 1: Never call the API from Tick. This is obvious in C++ but disarmingly easy to do in Blueprint. AI calls inside Tick will crater your frame rate immediately.

Rule 2: Always prefer streaming responses. Waiting for an entire long NPC line is a much worse experience than rendering tokens as they arrive. Streaming reduces perceived latency dramatically.

Rule 3: Always have an offline fallback. The internet is unreliable; the game shouldn't break when it is. I keep a pool of pre-written canned lines and select from them when API calls fail.

Model selection in practice

For runtime AI, I use a per-context model strategy:

Pinning the entire game to a single model forces you to compromise on either cost or quality. Picking the model per-character or per-scene is the configuration that's left me happiest with the result.

The five mistakes I made first

Sharing in the order I hit them, so you don't repeat them:

1. "Antigravity Plugin not found in Project Settings." You need to manually add "Antigravity" to the plugin dependencies in your .uproject file. The installer doesn't always do this.

2. Compile errors persist despite require_review: true. Review doesn't catch compile-level issues. Always recompile immediately after generation; if errors appear, discard the change in the Diff Viewer, refine the prompt, and regenerate. That's faster than fixing the generated code by hand.

3. Hot Reload not picking up changes. This is a UE5 issue, not an Antigravity one — the only fix today is restarting the editor.

4. Content Browser metadata corruption. Rare but real. Generated Blueprints occasionally break thumbnail rendering. Asset Manager → Refresh Asset Registry clears it.

5. Runtime AI latency higher than expected on mobile builds. Mobile UE5 builds can show 2–3x the latency of desktop builds for the same Antigravity call. SSL handshake overhead is the culprit; HTTP connection pooling/reuse fixes most of it.

If you're starting fresh, complete Chapter 1 setup, then run the inventory Blueprint example from Chapter 2. Thirty minutes will give you a clear sense of what Antigravity can — and can't — do for your UE5 project.