Devblog March 2026

General

This month I focused on several optimizations and refactorings with the Game Master and the tracking point system.
I also redid the floating player name and created a new cinematic mode for Talas’s model.

Progress with Game Master and Maw Exhib

Following the Game Master Update I did a big cleanup and fully removed old code and dependencies.
Now the system has the core Game Master code in C++ in a plugin and MMVS use the plugin with C++ override and visual scripting to setup its logic specific to the game.

As a reminder, Maw Exhib is the Situation System that allow Talas to show his maw to a micro in the environment.

For the Maw Exhib when you click on the environment as game master, the tool automatically detects the closest valid spot to the mouse position where Talas can show his maw.
But the tracked point was on the floor, at the origin of the situation object, so it was not very intuitive to find the right spot when you have several heights at the same floor position.

So I created a new game master selection point class used to find the correct points with context.
The code is similar to my game master tool observer added in February, it will cache all selection points in several categories depending on the context and automatically update when the context changes.

For the Game Master Player, this allows them to click at the correct height, automatically selecting the closest valid point from the mouse position.

When a game master tool is used, the system can instantly access the correct selection points with minimal CPU usage since everything is cached. And from here the code can get the closest one.

Before the system used a cached situation list and filtered only the situations from a specific class.
Even earlier in the first versions of the game, the code iterated over all actors in the level then, filtered the ones with the correct situation class, but that was very inefficient.

As always all this is modular, it makes the system both faster and far more intuitive to use.
This is currently only used for Maw Exhib, but it future-proofs the system. I put foundations that will be reused for other Game Master stuff.

Game Master Tool Selection

I updated the Game Master scripts to pass custom actions and manage selection state, so now the code can notify when a selection is selected by a tool or when it’s hovered.
A player game master can manage one selection at a time, and a game master tool can have several selections at a time.

Every tool type has its own way to manage the selection.
For the MawExhib and the StandAgainstWall, the tool code just sets as hovered the closest selection object from the mouse position.
And the object detects and updates the FX, so that gives a better feedback to the game master user.

In the video you can see what is considered as hovered or selected, and how the FX react to it.

Standardized Game Master FX

Now that I have a clean setup I can make some standardization to save time and have a better workflow.
In Unreal Engine the VFX use Niagara, it is a particle system that can manage scripted logic per systems, emitter, and particle.

Before, when the player game master hovers over a selectable object, the code transfers the info to the FX Asset and in the Niagara logic the color is set to orange when hovered.
It works but requires copying and pasting the same logic in every FX assets and losing a lot of time if I need to change something.

So now the FX assets use scripted modules that manage everything: the state, the transitions, the color, etc.
If I update the module it updates all FX using it, so it can save a lot of time and have a better consistency between the different FX.

To update I fully redid all the game master FX.
The FX are now more intuitive with color and animations transition and smoother movement animations.
Also the scripted FX are now directly spawned and managed by the game master tools.

For example, the MoveTo action is a game master tool with two scripted FX: the 3D mouse cursor and 3D path, both managing their own logic to update the FX.

In the video you can see the color that changes to indicate if it works, the cursor rotation is less aggressive, etc.

Talas Cinematic Mode and Macro March 2026

In March I rendered many scenes and poses for the Macro March 2026 and I used Nanite technology for Talas’s model.

Nanite is an Unreal Engine technology that strongly optimizes the geometry sent to the GPU, allowing very high poly counts with good performance.
It’s very useful to work with Nanite tessellation and displacement directly from the model shader.
But it also has limitations that must be understood to avoid pushing all the settings to the limit.

So I created a new cinematic mode for Talas’s model.

First, I separated the transparency parts of the model because transparency shaders are not supported by Nanite tessellation.
The model has a higher poly count so the tessellation can use more data at very close view.
If you are too close to a big face the geometry can start to glitch, increasing the poly count makes the face smaller so you can get closer before it starts to glitch.
I also split the model into several parts: paws, legs, head, etc., so Nanite could manage chunking per part. This avoids cutting the model itself into big chunks and gives better results, preventing glitches with geometry and shadows when the camera is focused on a specific part of the model.

In the cinematic mode I also replaced the shader parallax with real displacement, which gives very good results and you see true geometry on the model.

This opens up many possibilities for the future, I will be able to reuse this once I migrate to Nanite.

Btw, to pose the characters, I used a Control Rig (in Unreal Engine).
The rig was created by Corvidius, thanks to him for his awesome work!

If you want to see more:

You can check my 3D FurAffinity gallery: FurAffinity
And check the 8k renders and Behind the scene on my Dropbox: Dropbox Link

Just to tease, the Nano Sole Environment level will get a way better quality than here. ;)

Floating Player Name

I totally redid the floating player name above the head to support more character types and fix the facing camera rotation issues.

Now the rotation is done by the FX Asset on the render thread rather than the gameplay thread.
It really follows the head and fixes some rendering issues.
Also, the text is now a texture generated by a widget like the game UI, so it can support all languages font, custom colors, and emojis.

Also I added more options in the user settings to keep your own name visible.

Tracking Point System Refactorization

Related to a bug I refactorised my tracking point system. It’s a system that manages a virtual point for Talas when he wants to stomp, grab a micro with his hand or with his beak, etc.

The bug was easy to fix but the main issue is that the system was trying to handle too many things at the same time.

Gameplay, with several animations when Talas predicts a stomp at a specific location, or simply follows a target, etc.
AI, which can set its own target.
The animation system, which uses the tracking data to animate Talas.
Player feedback, such as the shadow showing where Talas will stomp.
Collision, to manage the tracking range.
Etc.

For each use case, I need to add a lot of additional code in subclasses of the tracking point system, which makes things difficult to debug.

I first did a big cleanup and moved all the logic into a master class in C++. Then I refactored some elements like the zone detection that are faster and easier to configure.
And the system now supports rotation control for future uses, though it’s not used here yet but it will be possible to stomp with custom paw rotation.

Once the system is done I can recreate the uses with the stomp, grab, etc
I will speak about it in the April devblog.