It is now 2026.
This time is a special combined issue, December 2025 plus January 2026.
To be honest, it is because I was too busy with work to find time to write.
All right, starting with December.
In December, the results of the Epic MegaGrants were announced.
For Hotch Potch House, this was my third attempt, and the result was…
I wrote it further down below.
Here is what this issue covers.
Also, starting this month, there will be a table of contents.
Of course, you can click an item to jump to that section.
●Switching to State Tree
●Major Collision Overhaul
●Shared Rig
●MegaPlants
●Others
●Future Plans
●Switching to StateTree
It feels like I have been talking about this forever, but I finally finished migrating my AI logic to StateTree(ST)
It went about three times more smoothly than I expected.
For the regular enemies, I ported over the logic I had built for another project.
For the bosses, I rebuilt everything from scratch.
What I love about ST is the clean, well-organized UI. It looks great.
Keeping things tidy is extremely important in game development, so this change is a big deal for me.
Debugging also became much easier thanks to the dedicated debugger that was added.
Before I started, I was already feeling discouraged because I expected a lot of trouble, but the migration ended up being smooth with almost no issues.
That said, the current setup is still not very flexible, and there is plenty of room for improvement.
To fix that, I first need to lock down what kinds of enemies I will have and how they move, so I have been doing a lot of sketches and brainstorming.
I cannot really show much yet, so I will save it as something to look forward to after release.
On a slightly more technical note, one thing that makes me personally happy about switching to ST is that I can trigger events using Gameplay Tags.
With Behavior Tree, as far as I know, there was no better option, so I reluctantly used Event Dispatchers.
The problem is that this requires hard references, which hurts modularity.
By the way, this is the boss I made quite a while ago. It is finally getting its moment, and he is happy about it.
●A Major Collision Overhaul
Settings like collision profiles were part of it, but the main focus of this overhaul was camera collision.
It had been on my to-do list for a long time, but I kept ignoring it because it sounded like a hassle.
Eventually, the pressure became too persistent to ignore, like a little bear relentlessly poking me in the side, so I finally committed to it.
As many of you probably know, UE5’s default camera collision can feel very jittery, and it is not comfortable to play with.
In a game like Hotch Potch House, where tight spaces are packed with objects, it becomes especially stressful.
Up until now, I used a setup like the one in this video, two Spring Arms plus camera lag to keep the movement smooth, and I was fairly happy with it. But at a certain point, a number of issues started to show up.
The new logic was introduced to get rid of those problems.
What I referenced was the camera system in Hogwarts Legacy.
Moving closer works normally, but when the camera pulls back, it only moves slowly while the character or the camera is actually moving.
It is hard to explain in words, so here is what I built.
…It might still be hard to tell from the video.
But once you play it, it becomes obvious.
I also redesigned the behavior for when the camera overlaps with objects.
For example, if a thin object like a pencil blocks the camera, the camera can end up snapping back and forth rapidly, which ruins the experience.
One option is to make the camera ignore thin or small objects, but then the camera can sink into geometry, which also looks bad.
To solve this, I brought back this video.
By coincidence, it is a developer talk from the Hogwarts Legacy team. It is an excellent talk that I have been referring to since early development, but the part about camera collision had always remained a mystery to me.
It says, “Solution: use overlap response,” but simply switching to overlap still lets the camera go inside thin objects.
The video does not explain the exact logic, so I had to build it myself.
Here is what I ended up with.
So yes, this is how I rewrote the camera behavior, and it was a pretty intense task.
The logic itself is fairly simple, but debugging was difficult because it runs every frame.
At one point, even though the math should have been correct, the camera was somehow drifting slightly away from where it should be. That was the biggest time sink.
The culprit turned out to be the Spring Arm’s Socket Offset, and I promptly removed it.
After that, everything moved forward smoothly.
●Shared Rig
I made a robot NPC.
It already existed in the project, but it was originally a placeholder NPC and did not look great, so I rebuilt it.
…That said, it still does not look quite right, so I will probably end up revising it again.
While rebuilding the robot, I also revisited the rig setup.
Actually, that was the main point.
I grouped my characters into four categories, 1) humanoid, 2) quadruped, 3) bird, and 4) unique, and made each category share a common rig.
I think this is the standard approach in many game projects, but early in HPH’s development I was estimating roughly ten characters, so I planned to just make a unique rig for each one.
As development went on, my ambitions kept growing, and before I knew it, I was building twenty characters.
And it looks like the number may still go up.
At that point, giving every character a unique rig would make Animation Blueprint setup far too tedious.
Also, with twenty characters, I can probably reuse animations here and there.
That is why I decided to restructure the rigs.
First up is the humanoid rig, which I will use for the robot.
Building from scratch is a pain, so I use Rigify.
Rigify is an official Blender add-on, and it is my favorite rig preset.
The downside was that, because of its structure, exporting to UE5 would bring along a ton of extra bones I did not need.
I looked into ways around that and found an excellent add-on called GameRig.
With it, you can generate a game-ready rig that includes only the necessary bones, in a single click. Great.
By the way, the author of the add-on, Armin Halac, sounded familiar. It turns out he is the author of a well-known book on Blender rigging.
I almost never buy 3D books, YouTube is usually enough, but this is the one exception I bought, and it was genuinely helpful. Recommended.
From here, I will be building the other rig types one by one.
●MegaPlants
MegaPlants was added in 5.7.
Despite being an experimental feature, and on Mac, which is about the worst possible combination in UE5, it is surprisingly well-behaved, with almost no critical bugs.
How this relates to Hotch Potch House is that I mainly want to use it for the tree in the garden.
A while ago, I had already finished the base tree model.
All that was left was to place branches using PCG, but I was stuck on what to do about wind.
WPO is an option, but it is heavy on performance, and more importantly, the lighting does not look great, which was a problem.
Then this new feature showed up at the perfect time.
Exactly what I needed.
If I remake the branch and leaf parts so the style matches, I think I can build some really nice trees.
The one risky part is that I would need to update UE.
At the very least, it will not move into beta until 5.8, and going through two major version updates at this stage feels pretty scary.
Of course, I will test everything and move forward carefully, but I really want to make it work and bring it into the project.
●そのほか
So, about the Epic MegaGrants results that were announced last December…
I did not get selected🥲
I even dreamed about being accepted like four times. Something is not adding up.
This time I was fairly confident, so I took a proper look at what went wrong.
Here is my reflection report. Reflect, reflect.
【Reflection 1: I am not sharing information about myself】
This was a blind spot, but it is probably a very important point.
From the perspective of the person giving out money, there is always the risk that someone could take the money and disappear.
If they do not know who you are, they cannot really trust you.
I do share my real name and a photo of my face, but these days you can even generate profile images with AI *sigh.
For the next submission, I plan to include more information about myself.
【Reflection 2: I am not communicating the fun well enough】
Of course, I also thought about flaws in the game itself.
The biggest issue is… well… it is not fun.
From my perspective, it felt like a very exciting game, but when I tried to play it more objectively, it was basically just a model house tour where there is almost nothing to do.
In my head, I can clearly imagine a lot of fun elements, and I think that imagination was doing most of the work.
From now on, packing in genuinely fun gameplay will be one of my top priorities.
【Reflection 3: Amateur-level materials】
Belatedly, I researched how to make materials for publishers.
What I learned is that the materials I have submitted so far were not professional at all.
I also got a much clearer sense of what publishers actually want to see, so I am currently working on a new set of materials.
I plan to share them publicly at some point.
That is it for the reflections.
With that in mind, let us look at what is coming next.
●Future Plans
Based on my reflections on the MegaGrants result, my short-term plan has changed significantly.
My top priority is now to build a playable demo that includes genuinely fun, game-like elements.
I will improve things like boss battles and quests, and shape the demo into something that has a clear beginning and end, even if it is short.
At the same time, I will also keep working on the pitch materials in parallel.
So that was my first combined issue. It took me quite a while to write, but I am glad I managed to publish it.
Thank you for reading, and see you in the next issue.