Chasing the Missing Reply
The end of Milestone 3 left me with a feeling of unfinished business.
My attempt to add player input (prompting the LLM directly from within the game) somehow broke what had been “working” before.
What was meant to be a simple addition of UI dialogue boxes, a player input field, and the apple-seller persona seed instead resulted in silence on the other end.
Where Was Milestone 3 Left?
By the close of Milestone 3, the project was just shy of full interaction.
The player could type messages and see the interface respond with a “…thinking…” status, but the NPC’s actual reply wasn’t making it onto the screen yet.
That moment marked the turning point between connection and communication. Something had severed the connection and therefore the communication.
With Milestone 4, I set out to trace exactly where the response path was breaking, rebuild a clean execution chain, and finally see my first in-game conversation come to life.
Rubber Duckie…You’re the One
As I opened the Blueprint to begin debugging, I realized that I actually had not a clue where to start.
I had some suspicions about what might be wrong, but my lack of formal programming experience made it hard to know exactly where to look, or how to fix it once I did.
Enter the Duck
I recently learned about “rubber ducking”, a debugging or problem-solving technique used by programmers.
The idea is simple: you explain each line of your code to a rubber duck (or any inanimate object, or even another person).
By doing this, you’re forced to slow down, walk through your logic, and often spot what’s going wrong. If you can’t clearly explain what your code is doing to the duck, then maybe it doesn’t make sense logically either!
Waddling Through the Response Trail
Rubber ducking has turned out to be surprisingly helpful so far. I’m only about a third of the way through the Blueprint, but I’ve already spotted a few things that didn’t make sense.
First, I realized that the output box wasn’t actually displaying the “thinking” status text from my code, it was just showing the placeholder “…thinking…” text that I had set inside the Dialogue Widget earlier!
In other words, that feedback was coming from the designer, not the Blueprint logic. I confirmed this by changing the placeholder text to “waiting”.
Second, it looked like the execution path wasn’t running through the full chain of nodes. To trace what was really happening, I started adding Print String nodes labeled “happy path” along the ideal execution route I want the code to follow, just to see how far the flow was getting and where it stopped.
Finally, I noticed that I might have gone a bit overboard with UI safeguards before the core system was ready. The TrySend function and several nodes in the WBP Event Graph seem to be blocking or short-circuiting the message path.
It’s like I built guardrails before I finished paving the road!
Tomorrow, I plan to continue rubber ducking my way through the rest of the Blueprint; clearing away the extra bramble until I can see the main, clean pipeline that connects Unreal’s prompt to Ollama’s response. Just like it did back when the first SMOKETEST worked!
Spreading My Wings
Even without a full fix yet, this round of debugging has been one of the most valuable learning moments in the project so far.
Rubber ducking forced me to slow down and really see the Blueprint I built: every function, every branch, every piece of logic.
It reminded me that building an “intelligent NPC” isn’t just about wiring an AI model into Unreal, it’s also about building my own understanding of how each piece connects.
Most unexpectedly, I’ve discovered that I genuinely love this process. Programming has turned out to be incredibly fun, even when things don’t work right away. Every time I trace a wire, spot a pattern, or watch a Print String confirm a theory, I feel immense joy. There is something eloquent and creative about this form of problem solving.
My goals for the rest of Milestone 4 are to:
Once that happens, the NPC will finally have a voice again. Then I can start focusing on the part I’ve been dreaming about: shaping its personality and traits and bringing it to life inside a prototype.
This milestone also made me realize how genuinely exciting programming can be. There’s something thrilling about working hands-on with technology that feels like it’s sitting right on the edge of what might change the world.
Even when things don’t work, the process of experimenting, debugging, and slowly making sense of the logic is deeply rewarding. It’s made me want to keep exploring this side of development long after the project is over.
Until next time,
~Lauren
