DEV Community: Ivory Jones

Building Cipher: Where We Are, What Broke, and What’s Coming Next

Ivory Jones — Sat, 11 Apr 2026 19:19:03 +0000

Most AI tools stop at generating code.

Cipher doesn’t.

It walks straight into Unreal Engine and builds.

That sounds cool on paper. In practice, it’s been messy, frustrating, and honestly… kind of insane to get working.

This is where we actually are right now.

What Cipher Actually Does (Right Now)

At its core, Cipher is a loop:

Goal → Plan → Validate → Execute → Verify → Repeat

You give it something simple like:

“Create a player character with a mesh and animation”

And instead of spitting out instructions, it:

Talks to a FastAPI server
Writes structured commands
Sends them into Unreal
Modifies Blueprints directly
Verifies if it worked

If it fails, it tries again.

No hand-holding. No guessing.

That loop is alive now.

The First Real Breakthrough

The moment things started feeling real was when we solved mesh + animation assignment.

Sounds basic. It wasn’t.

Unreal doesn’t behave the way you expect when you modify native components like CharacterMesh0.

We tried:

Writing to the CDO → didn’t persist
Recompiling after changes → wiped values
Using handlers → failed on native components

What finally worked:

Use SubobjectDataSubsystem
Modify components through handles
Control the compile order (this mattered more than anything)

Once that clicked, Cipher could:

Assign skeletal meshes
Apply animation blueprints
Verify the result

That was the first time the system felt stable.

Where It Gets Ugly

A lot of things looked like they worked… until they didn’t.

Unreal Lifecycle Problems

Order matters more than logic.

If you:

assign mesh too early → it gets wiped
compile too often → you lose state
reload incorrectly → you verify the wrong object

We spent time chasing “bugs” that were just timing issues.

False Positives in Verification

Cipher has a verify step, which sounds great… until it lies to you.

We had cases where:

Mesh looked assigned → but wasn’t saved
Animation existed → but wasn’t actually applied
Blueprint compiled → but still broken at runtime

So we had to build real verification, not surface checks.

Things like:

checking actual asset names
stripping _C from generated classes
validating component existence directly

Python Listener Hell

Reloading agent_listener.py inside Unreal caused stale callbacks.

Meaning:

new code wouldn’t run
old functions stayed active
behavior became inconsistent

Fix was moving to a persistent dispatcher pattern instead of re-binding functions every reload.

Blueprint Graph Logic (Still Painful)

We recently started working on node wiring and fan-out logic.

This introduced a whole new class of problems:

duplicate execution pins
broken connections
missing idempotency

Even small mistakes here create invisible bugs.

This is where we are currently fighting.

What Actually Works Today

Right now, Cipher can reliably:

Create / load Blueprints
Add components (camera, spring arm, etc.)
Assign meshes
Assign animation blueprints
Compile + save
Verify correctness
Run in a loop from a goals file

Command loop:

py dev_agent.py --loop goals/aegion_setup.txt

That loop is the foundation of everything.

What’s Coming Next (This Is the Real Shift)

Up to now, we’ve been proving control.

Next, we move into gameplay.

Not just assets. Behavior.

Animation System Validation

We finish making sure animation blueprints:

attach correctly
play correctly
pass verification every time

No partial success.

Weapon System (Big One)

This is the next major milestone.

Cipher should be able to:

Attach a weapon to a socket
Validate the socket exists
Add firing logic
Connect input → action
Verify the system actually works

This is where Cipher stops being “asset automation”
and starts becoming gameplay automation.

Blueprint Modification (Not Creation)

We’re shifting focus:

Cipher should work with existing Blueprints, not just create new ones.

That means:

reading current state
modifying graphs safely
avoiding breaking existing logic

This is much harder than generating from scratch.

Toward a Gameplay Layer

Long term, the goal is simple:

Cipher should understand:

systems (movement, combat, UI)
interactions (input → response)
rules (win/lose states)

Right now, we’re still at the foundation.

But the direction is clear.

The Reality

This hasn’t been smooth.

It’s been:

debugging Unreal internals
fighting engine behavior
rewriting systems that almost worked
learning that “it compiled” means nothing

But now there’s something real:

A loop that can take intent
and turn it into something inside Unreal
without manual work.

Final Thought

Most AI tools generate ideas.

Cipher executes them.

And we’re just getting past the part where it stops breaking everything.

Next phase is where it starts actually building games.

I Built an AI That Actually Creates Unreal Engine Blueprints

Ivory Jones — Sun, 05 Apr 2026 18:43:32 +0000

There’s a point in every Unreal project where you stop being creative and start doing chores.

Create Blueprint.
Add camera.
Attach spring arm.
Set mesh.
Assign anim BP.
Fix offsets.
Compile.
Repeat.

Do it ten times, and it’s fine.
Do it a hundred times, and you start wondering why you’re still doing this manually.

That’s where Cipher came from.

Not as “another AI assistant.”
But as something that actually does the work inside Unreal.

The shift: from AI assistants → AI builders

Most AI tools right now help you write code.

They suggest things.
They autocomplete.
They explain.

But they stop right before the part that actually matters:

👉 changing your project

Cipher is different.

Instead of saying “here’s how to do it,” it goes:

“I’ll do it.”

What Cipher actually does

At a high level, it works like this:

You give a goal →
Cipher plans the steps →
Checks what exists in your project →
Executes inside Unreal →
Verifies the result →
Fixes anything that failed →
Returns a working Blueprint

That loop is the whole system:

Plan → Validate → Execute → Verify → Retry

No guessing. No blind generation. No “hope this works.”

A real example

Here’s a real command:

build BP_Test_Player with mesh SK_Mannequin anim_bp ThirdPerson_AnimBP and rifle and shooting system

What happens next:

Cipher creates the Blueprint
Confirms the parent class is correct
Finds SK_Mannequin in the Asset Registry
Assigns it to the character mesh
Finds the animation blueprint
Hooks it up correctly
Adds components (camera, weapon, etc.)
Verifies everything actually exists and works

And you end up with a playable character Blueprint.

No dragging. No clicking. No hunting through folders.

Why this doesn’t hallucinate like other AI

If you’ve used ChatGPT or Copilot for game dev, you’ve seen this:

“Use SK_PlayerMesh_Advanced_v2”

Cool. That asset doesn’t exist.

Cipher avoids that completely.

Before it does anything, it validates against Unreal itself:

Uses the Asset Registry to confirm assets exist
Enforces strict schemas for every action
Only executes valid tool calls

So instead of:

“Here’s what should work”

It’s:

“This will work because it exists”

That one difference changes everything.

The part that made it feel real

The first time Cipher successfully built a character wasn’t exciting because of the AI.

It was exciting because I didn’t touch the editor.

I gave a sentence.
Watched logs.
Opened Unreal…

…and the Blueprint was just there. Working.

Camera set.
Mesh visible.
Anim hooked up.

That’s the moment it stopped being an experiment.

It doesn’t break when things go wrong

This was a big one.

Most AI systems fail once and stop.

Cipher doesn’t.

If something fails:

It detects the failure
Re-checks the state
Adjusts the plan
Tries again

Automatically.

That retry loop is built into everything.

So instead of babysitting the process, you just… let it run.

It actually remembers what it did

Cipher also keeps memory.

That means:

It knows what it already created
It avoids duplicating work
It can continue builds instead of restarting

You’re not re-explaining your project every time.

It builds on itself.

Recipes: building more than one step

For bigger systems, Cipher uses recipes (YAML-based).

Think of it like this:

Instead of one command, you define a full build:

Create player →
Add camera system →
Assign mesh →
Assign animation →
Attach weapon →
Setup firing logic

And Cipher runs the entire sequence, validating at each step.

This is where it starts to feel less like a tool and more like a system.

What it can already do

Right now, Cipher can:

Create character Blueprints
Assign meshes and animation blueprints
Attach weapons
Build camera setups
Configure components

And it does all of this directly inside Unreal Editor.

No export. No copy/paste. No manual follow-up.

Why this is different from ChatGPT or Copilot

Those tools operate outside your engine.

Cipher operates inside your project.

That means:

It sees your actual assets
It works with real Blueprint structures
It validates against your current state

It’s not generating ideas.
It’s modifying reality.

The bigger idea

This isn’t about skipping effort.

It’s about shifting where effort goes.

Instead of:

“Let me build this step-by-step”

You move to:

“Let me describe what I want”

And let the system handle execution.

That’s a very different way of building games.

Where this goes next

Right now, Cipher is handling structured systems like characters and components.

But the direction is clear:

More complex gameplay systems
Full Blueprint graphs
Multi-actor setups
Eventually… entire game scaffolding

All from intent.

Final thought

There’s a lot of AI hype right now.

Most of it feels like tools getting slightly better at helping.

This felt different.

Because for the first time, I wasn’t being assisted.

I was being replaced… in the parts I didn’t want to do anyway.

And honestly?

That’s exactly what I wanted.

I Thought the Mesh Was Broken. It Was Actually My Blueprint Lifecycle.

Ivory Jones — Fri, 03 Apr 2026 22:46:31 +0000

I’ve been deep in a frustrating Unreal Engine 5.5 bug inside my AI → Unreal pipeline for Cipher.

The symptom looked simple:

[CIPHER] assign_mesh: no SkeletalMeshComponent found — parent must be ACharacter

But the part that made it maddening was this: the Blueprint was a Character. The parent class was correct. The Blueprint created successfully. The mesh component existed in the Blueprint editor. And if I tested the mesh assignment logic by itself, it worked.

So why did it keep failing in the real pipeline?

Because the problem was never the mesh.

It was the order I was touching the Blueprint.

The setup

My pipeline is trying to do something pretty straightforward:

Create Blueprint → Add Components → Assign Mesh → Assign Anim → Keep building

In practice, the execution looked like this:

setup_player_actor → Blueprint created
ensure_camera → Camera component added
assign_mesh → FAILS

And the logs made it obvious where things went sideways:

[CIPHER] ensure_camera: Camera created
[CIPHER] assign_mesh: no SkeletalMeshComponent found — parent must be ACharacter

At first glance, that error makes you think one of two things happened:

The Blueprint was created with the wrong parent.
The mesh component doesn’t exist.

Neither was true.

The parent class was ACharacter.
CharacterMesh0 was there in the Blueprint editor.
And GetDefaultObject()->GetMesh() was valid when tested in isolation.

That was the trap. Everything looked correct in pieces. It only broke when the full sequence ran.

What I already tried

Before landing on the actual cause, I burned time going down all the usual paths:

SCS traversal
CDO access
compile before access
PostEditChange
Modify
structural modification flags
rebuilding the plugin

None of it fixed the real issue.

That usually means the bug isn’t in one function. It’s in the lifecycle.

The real problem

The moment I added the camera, I changed the Blueprint’s structure.

That matters.

ensure_camera wasn’t just setting a property. It was modifying the Blueprint’s component tree. In Unreal terms, that means I was performing a structural Blueprint modification.

And once that happens, the current GeneratedClass is no longer something you should trust.

That was the break.

The pipeline looked like this:

Blueprint created
→ class compiled
→ camera added
→ Blueprint structure changes
→ GeneratedClass becomes stale
→ assign_mesh runs anyway
→ inherited mesh lookup fails

So the error message was misleading. The skeletal mesh component wasn’t “missing.” I was asking for it through a class state that had already been invalidated by the previous structural edit.

That is a very different problem.

Why this happens in Unreal

Unreal does not treat all Blueprint edits equally.

If you change data, you can often keep moving.

If you change structure — adding components, changing SCS layout, altering inheritance-sensitive setup — Unreal dirties the Blueprint in a more serious way. The compiled class is now out of date relative to the Blueprint asset.

So yes: modifying SCS or adding components can invalidate the current GeneratedClass.

That means if your next step depends on inherited components like CharacterMesh0, you need to recompile after the structural change, not just before it.

That was the key detail I kept stepping over.

I had been thinking:

“The Blueprint compiled earlier, so the class should still be usable.”

Not after ensure_camera.
Not after structural edits.

The correct lifecycle pattern

Once I stopped treating Blueprint creation as the only important compile point, the fix became clear.

The safe lifecycle is:

Create the Blueprint

Create the Character Blueprint asset.

Perform structural edits

Add camera, spring arm, or any component that changes the Blueprint’s component hierarchy.

Recompile the Blueprint

This refreshes the GeneratedClass so it matches the current Blueprint structure.

Access inherited components

Only after that should you access ACharacter defaults like GetMesh().

Assign mesh / anim / continue building

Now the mesh and animation assignment steps have a valid class backing them.

In other words:

Create Blueprint
→ Structural modifications
→ Compile Blueprint
→ Access CharacterMesh0
→ Assign mesh
→ Assign anim
→ Continue

That compile in the middle is the difference between a stable pipeline and a fake-success setup that blows up one step later.

The practical fix

The rule I’m following now is simple:

Every structural Blueprint modification must be followed by a compile before any code touches inherited components or class defaults.

That means CompileBlueprint does not belong only at creation time.

It also belongs immediately after functions like:

ensure_camera
component additions
SCS edits
anything that changes Blueprint structure

Then, and only then, should code like this run:

ACharacter* CharacterCDO = Cast(Blueprint->GeneratedClass->GetDefaultObject());
USkeletalMeshComponent* MeshComp = CharacterCDO ? CharacterCDO->GetMesh() : nullptr;

Because now GeneratedClass actually represents the current Blueprint, not the version from one structural change ago.

What made this bug so annoying

This kind of bug is ugly because Unreal gives you just enough truth to waste your time.

The Blueprint exists.
The parent class is correct.
The component shows up in the editor.
The mesh assignment logic works alone.

So you assume the access code is wrong.

But the failure was happening between steps, not inside one.

That’s what made it feel random. It wasn’t random at all. The class was simply stale by the time assign_mesh ran.

What I’m changing in Cipher

Cipher’s job is to automate Blueprint building reliably, not just occasionally.

So the pipeline has to respect Unreal’s lifecycle, especially when chaining actions like:

Create Blueprint → Add Components → Assign Mesh → Assign Anim → Continue building

If the system modifies structure and keeps going without recompiling, it’s building on a broken foundation.

The fix is to treat compilation as a synchronization point, not a one-time startup step.

That means:

create Blueprint
apply structural edits
compile
then do inherited-component work
repeat that pattern whenever the structure changes again

That should make mesh assignment succeed consistently, even after previous modifications.

Final thought

I went into this thinking I had a mesh visibility issue.

What I actually had was a Blueprint lifecycle issue.

The mesh wasn’t gone.
The parent wasn’t wrong.
The lookup wasn’t crazy.

I was just asking Unreal for CharacterMesh0 from a class that no longer matched the Blueprint I had just edited.

Once I started treating structural edits as invalidation points, the bug stopped looking mysterious.

It started looking like Unreal.

The AI That Actually Builds Unreal Engine Blueprints

Ivory Jones — Thu, 02 Apr 2026 20:06:02 +0000

A few weeks ago I sat down with a simple but slightly insane thought:
What if I could type “Build me a third-person character blueprint with a follow camera and a basic mesh”… and an AI just did it? No ChatGPT spitting out code I have to paste. No manual drag-and-drop in the editor. Just set a goal and walk away while it works inside Unreal.That’s Cipher. It’s not another “AI for game dev” wrapper. It’s an autonomous agent that lives in your Unreal project, reads your high-level goal, plans its own steps, executes them through the Python API, checks its work, and keeps going until the job is done.Why this actually feels differentMost AI tools I’ve tried are fancy autocomplete or chatbots. They hand you a blueprint graph screenshot or a wall of nodes and say “good luck implementing this.” Cipher doesn’t hand you anything—it does the thing.It connects three pieces that talk to each other in a tight loop:AI planner (the brain)

Command system (the translator)

Unreal Engine (the hands)

Right now the brain is Qwen running locally via Ollama—fast, private, zero cost. Later I’ll swap it for Claude when I want deeper reasoning. The whole thing is deliberately modular so the “brain” can be upgraded without touching the rest of the system.How the loop actually works (it’s simpler than it sounds)You give Cipher a goal in plain English:“Create a new Actor blueprint called RotatingCube that has a static mesh component using the default cube and rotates slowly on the Z axis with a point light attached.”
Here’s the pipeline:Goal → Qwen (via Ollama)

Qwen outputs command.json — structured, no hallucinations allowed

Unreal Python script reads the JSON and executes it (create BP, add components, set properties, save asset)

Script writes response.json with what actually happened + current editor state

Back to Qwen: it reads the response, evaluates progress (“70% done, missing rotation logic”), and decides the next command

Loop until the goal is marked complete

The whole thing runs hands-free. I’ve literally started it, gone to grab coffee, and come back to a finished blueprint.Here’s a tiny peek at what a command looks like (real example from a recent run):json

{
"action": "create_blueprint",
"params": {
"name": "RotatingCube",
"parent_class": "Actor",
"components": [
{
"type": "StaticMeshComponent",
"mesh": "/Engine/BasicShapes/Cube.Cube",
"relative_location": [0, 0, 0]
},
{
"type": "PointLightComponent",
"intensity": 5000
}
],
"next_steps": "add rotation logic and test"
}
}

The debugging journey (aka the part where I wanted to throw my keyboard)This was not a smooth “I wrote it in one evening” story. It was messy and I loved it.First big headache: Unreal’s Python API is powerful but extremely picky about editor context and transactions. I spent an embarrassing number of hours chasing “stale callback” errors because I wasn’t properly committing changes or refreshing the asset registry. The AI would happily command something that worked in my head but failed silently in the editor.Then the command pipeline kept breaking in fun ways:AI would invent node names that don’t exist
JSON would get malformed when Qwen got excited
Execution would succeed but the response.json would be empty because I forgot to flush the output

Each time I’d fix one thing, the loop would run a little longer. The first time it successfully created a blueprint and added a camera component without me touching the mouse, I actually said “no way” out loud. The next breakthrough was when it read its own response, realized the rotation wasn’t there yet, and added the timeline + rotation nodes on the next iteration. That moment felt like magic.I kept a little “victory log” in my notes. The best entry:
“2026-03-28 2:14am — it fixed its own mistake. I didn’t even tell it what was wrong.”What Cipher can do right nowCreate brand-new blueprints from scratch (any parent class)
Add and configure components (Camera, StaticMesh, SkeletalMesh, PointLight, etc.)
Modify existing assets (change materials, variables, default values)
Evaluate its own progress and self-correct
Run completely autonomously until the goal is marked “complete”

I’ve used it to spin up quick prototypes: a simple third-person pawn, a rotating collectible with VFX, even a basic door that opens when you overlap a trigger. Nothing production-ready yet, but way beyond what I expected from a local model.What’s nextThe obvious upgrade is swapping the planner for Claude (or whatever frontier model is best when you read this). Claude’s reasoning is noticeably better at long-horizon planning and catching its own logical gaps. I’m also building better memory between runs so it can remember “last time I built a player character this way—let’s reuse that pattern.”Longer term? I want it building entire small scenes or simple gameplay loops without me babysitting every step. The dream is an AI that can take a one-paragraph game design doc and spit out a playable vertical slice while I sleep.The bigger pictureWe’re still early, but the direction is clear: AI isn’t just going to help us build games—it’s going to start building them with us, then eventually for us. Cipher is my small bet on that future.If you’re playing with Unreal Python, AI agents, or just love the idea of autonomous tooling in engines, I’d genuinely love to hear from you. Drop a comment, share your own war stories, or hit me up if you want to poke at the repo (it’s messy but public soon).Building this has been equal parts frustrating and ridiculously fun. Can’t wait to see where it goes next.— Rez
(just a guy who likes making computers do the boring parts)

Cipher: My AI That's Actually Building Unreal Blueprints For Me

Ivory Jones — Tue, 31 Mar 2026 21:08:54 +0000

I’m tired of staring at the same Blueprint nodes for the third hour straight. So I built Cipher — an AI agent that plans gameplay systems in Unreal Engine and spits out commands to make them real.

Cipher isn’t some fancy wrapper. It’s an agent that thinks through what needs to happen, then fires structured JSON commands over a Python bridge straight into Unreal. It duplicates Blueprints, adds cameras, spring arms, components, you name it. And it’s already doing more than I expected.

Why the hell am I doing this?

Unreal is powerful but the workflow can be soul-crushing. Want a new camera rig? Duplicate, tweak variables, hook up events, pray nothing breaks. Same crap every time you prototype. I got fed up repeating myself and decided to teach an AI to handle the boring bits so I could focus on the fun ones.

How Cipher actually works

I give it a high-level goal. Cipher’s planner figures out the steps, then outputs clean command JSON. A Python listener running inside Unreal picks it up and executes — creating actors, modifying Blueprints, adding components, setting properties. No vague “generate code” nonsense. It’s deliberate, structured, and reversible when it screws up.

Right now it’s solid at duplication and component surgery. Tell it “add a spring arm and camera to this pawn,” it does it without drama. Small wins, but they stack fast.

What’s already shipping

Blueprint duplication with targeted modifications
Adding and configuring components (cameras, springs, collision)
Basic property tweaks and hierarchy changes

It’s not perfect, but watching it build a functional camera system in seconds still makes me grin like an idiot.

The annoying bits I’m still fighting

Duplication bugs keep popping up when references get messy. Stability isn’t there yet — sometimes Unreal gets cranky with rapid commands. And making the whole thing deterministic so I don’t get different results on the same prompt is harder than it sounds. I’m deep in the trenches fixing this stuff daily.

Where this is headed

Full gameplay systems. Inventory, combat loops, procedural level hooks — all planned and assembled by Cipher. Long term? Maybe entire small games from rough specs. I’m not there yet, but the path is clear.

I built this because I want to make games faster and weirder without getting buried in editor busywork. Cipher’s my co-pilot in the trenches, not some magic bullet. It still needs me to steer hard, and that’s exactly how I like it.

If you’re an Unreal dev drowning in repetitive Blueprint work, this kind of setup might save your sanity too. I’ll keep posting updates as it levels up.

Hit me up if you’re doing similar crazy shit. Always down to compare scars.

NONRESOLVED Devlog

Ivory Jones — Sun, 29 Mar 2026 19:57:21 +0000

I want to tell you about the moment this project stopped being a concept and became something I couldn't stop thinking about.

I typed:

"build camera rig"

And Unreal Engine — the actual editor, the actual viewport — built it. A SpringArm, a Camera, wired together, attached to the correct root. Clean. No errors. No Blueprint editor opened. No node graph touched. I didn't drag a single component.

I just typed three words into a terminal.

The Problem I Was Actually Trying to Solve

I'm making a game called NONRESOLVED. The core of it — the thing that makes it different from anything else — is an AI that has memory, identity, and evolves over time. Not a chatbot you talk to. An entity that exists inside the world, that remembers what it said last week, that changes based on what happens to it.
I want to tell you about the moment this project stopped being a concept and became something I couldn't stop thinking about.

What I Built

The system has a simple shape, but it took a while to get the architecture right.

Prompt → Python Server → JSON → C++ Plugin → Unreal Engine

Here's how it works in practice:

I type a prompt — plain English, no special syntax
A FastAPI server (Python) interprets the intent and returns structured JSON
A custom C++ Unreal plugin (AIBridge) receives that JSON over HTTP
The plugin parses it and executes real Unreal API calls — FKismetEditorUtilities, USimpleConstructionScript, the actual Blueprint machinery
The editor updates. Live.

No Python running inside Unreal. No Blueprints being manually touched. C++ all the way down once the intent is resolved, which was a constraint I set early and refused to break. Python is the interpreter. C++ is the executor. The engine doesn't know or care that the instruction came from a human typing casually in a terminal.

The First Thing That Worked

The first milestone was just being able to create a Blueprint. Sounds trivial. It took a few days.

{
  "action": "create_blueprint",
  "name": "BP_AICharacter_1"
}

That's it. Type "create blueprint called BP_AICharacter_1" and the file appears at /Game/AI/BP_AICharacter_1. The asset is real, persistent, compilable.

Once that worked, I felt something shift. Not excitement exactly — more like recognition. This could actually be a thing.

The camera rig came next. And that's when I had the moment I described at the top. "build camera rig" expanding into a multi-step execution:

clean existing cameras
→ remove duplicate SpringArms
→ create SpringArm
→ create Camera
→ attach Camera to SpringArm
→ compile Blueprint

All from three words.

Milestone 2: Mesh and the Player Actor

This is where I am now, and it's the most satisfying thing I've shipped on this project.

I added five new actions:

add_mesh — adds a SkeletalMeshComponent or StaticMeshComponent to any Blueprint, cleaning first so you never end up with duplicates.

set_mesh — assigns a specific asset path to an existing mesh component. Point it at a skeletal mesh asset and it wires it up.

add_movement — adds and configures CharacterMovementComponent with values I actually want: 600 max walk speed, 1.75 gravity, bOrientRotationToMovement = true. Not Unreal defaults. My defaults.

set_transform — sets relative location and rotation on any scene component. The standard mannequin mesh offset (Z: -90, Yaw: -90) can now be applied with a single line.

But the one that made me stop and stare was this:

setup_player_actor

"setup player character BP_PlayerCharacter"

This single prompt now builds the entire thing:

BP_PlayerCharacter  [parent: ACharacter]
├── CapsuleComponent
├── Mesh              (offset Z:-90, Yaw:-90)
├── SpringArm         (boom 400, eye height 88, follows controller)
│   └── Camera
└── CharacterMovementComponent
        MaxWalkSpeed:  600
        JumpZVelocity: 600
        GravityScale:  1.75
        AirControl:    0.35

From one prompt. One compound action. The AI doesn't just respond to intent — it expands intent into a sequence of precise operations that produce a correct, compilable, playable result.

What This Actually Feels Like to Work In

Let me be honest about the texture of this workflow, because it's not all magic.

What's genuinely different:
The feedback loop is shorter than anything I've experienced in solo game dev. I'm not context-switching between "thinking about the game" and "doing Unreal things." The doing and the thinking are the same action. I describe what I want and I see it, and then I describe what I want next.

The system also forces you to think in operations, not in clicks. When you're dragging components around in a Blueprint editor, you're thinking visually and spatially. When you're prompting, you're thinking about what the system should do. It's a higher-order abstraction and — surprisingly — it makes bad decisions easier to catch before you make them.

What's still hard:
The intent parser has edges. "Set the mesh to the mannequin" works. "Use the default character mesh" is ambiguous and needs a real asset path. I'm still hand-tuning the keyword extraction for transforms and component targeting.

Also: you have to trust the system, which requires understanding the system. When setup_player_actor runs and the hierarchy looks wrong, you can't just undo a drag. You have to understand what the C++ executed, why, and how to correct the JSON response. The debugging layer is different, not easier.

The Design Principle That Keeps Everything Sane

Early on I wrote this down and I've referenced it constantly:

AI is the builder.
NOT the developer.

The AI agent doesn't make game design decisions. It doesn't choose where the camera should be or what the character should feel like to control. Those are my decisions. What the AI does is execute them — faster, without friction, and without requiring me to memorize the Unreal API at 1am.

This distinction matters because it's easy to let the tool start making decisions for you. When the AI builds a default camera rig, the temptation is to accept the defaults because changing them requires another prompt. I've resisted this by keeping my defaults in the system — the movement values, the spring arm length, the eye height. The AI executes my preferences, not its own.

Where This Is Going

The system is roughly 55% complete as a construction layer. Here's the full roadmap:

[x] Blueprint creation
[x] Camera rig system
[x] Mesh system
[x] Player actor system
[x] Transform configuration
[ ] Input bindings (Enhanced Input System)
[ ] Animation Blueprint hookup
[ ] Enemy AI (Behavior Trees via prompt)
[ ] Combat system
[ ] Narrative AI — memory, identity, evolution ← this is the whole game

The narrative AI layer is the reason any of this exists. Once the construction system is complete enough that I can build and iterate on gameplay systems through prompts, I can redirect my full attention to the thing that makes NONRESOLVED what it is: an entity that knows who it is, remembers what it's been through, and changes.

That's the thing I'm building toward. Everything else is scaffolding.

If You're Thinking About Building Something Like This

A few things I'd tell you:

Start with the C++ plugin, not the Python server. The hardest part wasn't the intent parsing — it was understanding which Unreal APIs to call and in what order to do things without breaking the asset system. Get one action working end-to-end in C++ before you build any abstraction on top of it.

Define your JSON schema before you write any code. Every action should have a clear shape. I wasted time refactoring early because "name" meant different things in different contexts.

Build clean-before-create into every action. The single best thing in this system is that every add operation removes duplicates first. Without this, you end up with five SpringArms and a nightmare.

The constraint is the point. No Unreal Python for core logic. All execution through C++. Structured JSON only. These rules feel restrictive but they're what makes the system reliable. Every time I've thought about bending them, the result has been worse.

I'll keep posting as this develops. Next up is input and animation — the last things standing between "a Blueprint that looks like a player" and "something you can actually control."

If you're building something with a similar approach — AI as construction layer, not design oracle — I'd genuinely love to hear about it. This space feels early and weird and I think that's exactly where the interesting work is.

NONRESOLVED is in active development. This is devlog #1.

Ok so I had to pivot creating my game from a novel. I’ve been working on a system that lets an AI agent directly create and modify Blueprints inside Unreal Engine. Not just generating code. Actually editing the game. Ill be sharing details and progress

Ivory Jones — Sat, 28 Mar 2026 23:20:53 +0000

Adapting a 100+ Page Novel Into 5 Game Missions: What to Keep, What to Cut

Ivory Jones — Thu, 05 Mar 2026 21:04:18 +0000

I still get goosebumps thinking about the day I decided to cram my 100+ page novel, NONRESOLVED, into a tight 5-mission stealth-action game. Picture me, solo dev in a dimly lit room, UE5 humming on dual monitors, staring at a manuscript full of shadowy bureaucracies and moral gray zones. The novel's this slow-burn institutional thriller: Aegion, a genetically tweaked enforcer (a "Prime"), starts glitching—hesitating on kills, letting survivors slip—while his Oracle handler, Veradys, spins his violence into sanitized reports. The Consortium freaks, unleashes unfeeling Omega-class hunters, and boom, themes of weapons learning to choose, language as a leash, surveillance everywhere. Epic on paper. Total mismatch for a game where players crave "infiltrate, assassinate, GTFO."Games aren't novels. Readers can marinate in subtext for chapters; players need dopamine hits every 30 seconds. So I slashed it down to 5 razor-sharp missions, each an assassination with escalating predator vibes. No filler, no meandering politics—just pure player agency wrapped in the story's soul. Here's how I did it, what survived the cut, and the gut punches along the way.
**
The Skeleton: 5 Missions, One Awakening Arc**
Forget sprawling campaigns. I mapped the novel's tension to clear verbs: Eliminate. Survive. Evolve.Mission 1: Take out a researcher digging into classified files. You're the perfect tool—cold, efficient. (Tier 0: Pro enforcer mode.)
Mission 2: Silence an archivist who cracked your memory wipes. First flicker of doubt hits.
Mission 3: Gut a rival commander. Brutality ramps; Veradys notices you're... off.
Mission 4: Hit the director of Project INTEGRATION (your brainwashing program). Omega hunter crashes the party.
Mission 5: End the auditor greenlighting the Omegas. Apex predator unlocked—choose your ending based on how savage you played.

Each clocks 20-30 minutes: multiple paths (ghost stealth, tactical takedowns, rage mode), environmental lore (blood-smeared files whispering your past), and mechanical progression tying straight to the theme—Aegion awakens from drone to beast, unlocking claw swipes, enhanced senses, wall-crawls.It's like Hitman meets Alien: Isolation, but your "alien" is you, clawing free from the system.
**
What I Fought to Keep: The Heart-Pounding Hooks**
Not everything made the chop block. I zeroed in on elements that doubled as gameplay gold.The Omega-Class Primes—My Thematic MVPs
In the book, these are the Consortium's fail-safe: paired killers stripped of choice, each watching the other for "deviation." Aegion could've been one. Pure function, no soul. I kept 'em as bosses because the mirror-match is chef's kiss. Mission 4: Solo Ω7, a relentless machine spamming patterns you know because they're yours. Mission 5: Upgraded Ω9 adapts mid-fight, then both tag-team with oversight AI—dodge one, the other predicts. Beating them? It's not just victory; it's proof choice > code. Players feel it in their bones, like Kratos smashing his past in God of War. Oracle Link Drama
Veradys isn't just exposition—she's your HUD: scans rooms, hacks doors, distracts guards. Mid-Mission 4, link snaps (Consortium catches her truth-telling). Mission 5? You're raw dogging it... until she shows up IRL, pistol in hand. Heartbreak + vulnerability spike = instant stakes. Reports as Quiet Rebellion
Her logs evolve post-mission: "Routine compliance" → "NON-RESOLVABLE." Mission 5 transmits the final one off-grid. It's resistance via paperwork—subtle nod to how truth slips chains.

The Brutal Cuts: Lessons in Mercy Kill

Sacrifices hurt, but they streamlined everything.Ditched the Luminari Watchers
Novel stars: Alien auditors judging the Consortium from afar. Cool voyeurism, zero gameplay. Replaced with Veradys as your witness—personal, punchy.Axed Bureaucratic Web
Jurisdictional catfights, real-time narrative rewrites? Page-turners, but in-game? Snoozefest. Swapped for threat ladder: grunts → elites → Omegas. Fightable escalation.One POV Only
Novel hops Aegion-Veradys-others. Game? You're Aegion. Veradys voices your feed; survivors taunt via radio. Agency intact.

Tough Calls That Paid Off
Omegas vs. New Foes? Almost made "loyalist Primes." Nah—Omegas' "no-choice" mirror is too poetic for boss design.
5 or 12 Missions? Early pitch: Bite-sized eps. Reality: 5 dense ones > padded sprawl. Replay ability via paths/endings.
Link: Nuanced or Simple? Book's psychic nuance → Game abilities (scan/decrypt). Loss hits harder mechanically.
**
What Stuck With Me**
Novels thrive on implication; games demand show, don't tell via play. I gutted 70% plot, but themes scream through mechanics: Hesitate? Survivors alert reinforcements. Awaken? Tear vents apart. Omegas force choice in chaos.Result: 6-8 hour tight loop where novel fans nod at Easter eggs, newbies get hooked on the predator high. UE5.5 with GASPALS locomotion, Combat Fury AI—it's alive.Dev peeps who've crossed mediums: What cut stung worst? (Luminari killed me.) What surprised you? (Bosses > lore dumps.) Faithful vs. fun—your ratio?Following along? I'll drop awakening breakdowns, Omega fights, PowerShell UE hacks soon. Solo grind's real—thanks for vibing. Back to the shadows.

# Building NONRESOLVED: What If You Forgot You Were a Predator?

Ivory Jones — Thu, 12 Feb 2026 22:22:52 +0000

Building NONRESOLVED: What If You Forgot You Were a Predator?

I'm building a stealth-action game where you play as an alien enforcer who slowly remembers he's from a conquered predator species.

The Premise

You're Aegion—an alien working for the Consortium, a bureaucratic empire. You enforce their rules, complete their missions, follow orders.

But something's wrong.

You're starting to remember what you were before they "integrated" your species into their society.

You were an apex predator. And they made you forget.

The Hook: Awakening

Instead of getting stronger through loot or upgrades, you awaken—unlocking memories and abilities from your predator nature.

Early game: Stealth is mandatory. You're vulnerable.

Late game: You're brutal. Enemies are tougher—other awakened Primes like you.

The game is about remembering who you are while the Consortium tries to keep you compliant.

Why I'm Building This Solo

I wanted to prove you can build an ambitious game alone if you:

Use marketplace assets for standard mechanics (75% covered: locomotion, combat, AI)
Automate ruthlessly with PowerShell + Python (batch creation, property changes, workflows)
Focus custom development on what makes your game unique (awakening system, narrative integration)

Scope: 5 dense, replayable missions. Quality over quantity.

The Approach

Foundation (now): Integrating GASPALS (movement), Combat Fury (combat/AI), Cover System (stealth)

Custom systems (next): Awakening progression, support character abilities, AI that responds to your transformation

Polish (later): Making 5 missions feel complete and satisfying

Why Document This?

I'm sharing the entire journey—design decisions, automation scripts, what works, what fails.

Questions I'm exploring:

Can you really build a "AAA-lite" game solo with smart asset choices?
How much game dev can you automate with scripts?
What's the minimum scope for a complete experience?

This is post #1. I'll be breaking down systems, sharing scripts, and documenting progress as I build.

What would you want to see covered first? Drop a comment.

gamedev #unrealengine #indiedev #automation