General
June 2026 focus a lot on Talas’ digestive system, with new audio, gameplay, and animation features. I also did pass on my Rig Generator used to animate objects and characters.
The May and June 2026 devblogs were written at the same time.
Digestive System: Audio Ambiances
TL;DR: New ambiances in Talas digestive system with reverb and variations.
As I did for Talas House, I added audio ambiance in Talas’ digestive system to improve immersion and reinforce the feeling of being inside a living creature. Every zone will have its own reverb and ambiance, with some variations.
(Activate the sound on the video below)
I added more details on how I do it in the Devblog of May 2026.
Scenario System: Level Metadata
TL;DR: New method to share metadata between levels and sublevels simplifying the dev process.
During this month, I worked on a better system to share metadata between levels and sublevels.
This is mainly internal work, but it saves development time and improves game stability.
────────────
When the game loads a new level, the game code searches in the world for a hidden script called “World Settings” that contains metadata about the world and the current game, like micro scale, macro scale, description, available game settings, etc.
This script exists only in main levels, not in sublevels.
Talas’ digestive system is a sublevel that is loaded and connected to Talas’ character when it spawns.
So in-game, when you fall into that sublevel because Talas swallowed you, the code continues to use the script created by the main level to get all the data.
It’s a system that I made in 2022. Devblog of December 2022.
Most of its usage was later moved to the World Subsystem introduced in Unreal Engine 4.24 and to level settings, but it was still used for level metadata and scenario metadata.
Testing Issue
The issue is that when I work on the digestive system and want to playtest in the editor, I need to load a test level that creates the World Settings metadata, then loads the digestive system as a sublevel.
If I try to play directly in the sublevel, the game breaks because the data does not exist and default values are wrong.
Switching levels for every test wastes a lot of time. So I fully removed the World Settings script and rebuilt a cleaner C++ system using the World Subsystem and level settings to store data. I also updated all remaining usages, and I had to update 249 debug levels that were using the old World Settings.
Now I directly store metadata such as available game settings, description, micro scale, macro scale, etc., in level settings with a priority system.
And dynamic or cached data in the World Sub System.
Now during testing, the game uses main-level metadata if it exists, otherwise, it uses the sublevel, which now contains its own metadata.
Finally I can do testing directly in the sublevel with the correct data without having to load another level.
Dynamic Mesh Morph: Non-deterministic animations.
TL;DR: Support for non-deterministic animations to add more gameplay possibilities in Talas’ digestive system.
I updated Talas’ digestive system to add some gameplay animations.
To recap, initially the TagDynamicMeshMorph used for digestive system animation is deterministic.
This means that at a specific time, the geometry animation will be exactly the same for everyone on every machine. It is useful for multiplayer and replication, but it can’t be modified by gameplay events.
So I did new modifier types that support non-deterministic animations that can be triggered by gameplay events and not only by time.
Digestive System: Talas heart
TL;DR: New character heart system with heart-driven animation and audio in Talas Digestive System.
Talas is not gentle, but Talas has a heart.
With the new non-deterministic animation system, it is now possible to animate the heart animation with gameplay events. So I did a full heart system for the characters.
In the Heart System, heartbeat BPM adjusts to the character’s activity, actions, and gameplay events. Then the heart pulse script in the Digestive System detects the beat trigger, animates the surface, and manages audio.
Here in the video, I tested it with Cobble, so heart BPM adapts to the player’s gait and stance.
For Talas, it will adapt to his actions and situation, whether he lies in bed, walks, or tries to stomp a micro, etc.
Multiplayer Synchronization
About multiplayer, the simplest way would be to send a request at every beat. But that would produce a lot of useless network traffic.
Instead, I use some math to calculate a deterministic heartbeat using the BPM and server time.
Then I progressively resync the local heartbeat by adding or removing time between beats.
If Talas is sitting, the BPM target will be the same for server and clients, then the beat will offset to match the server timing.
You can see the resync in the video debug menu.
That way, I send zero network requests and the heartbeats remain perfectly synchronized.
Dynamic Mesh Morph: Anim Instance Driven Animations
TL;DR: Support for skeletal mesh animation instances to drive morph animations.
Now that the system supports non-deterministic animations, I added support to drive the morph animations with a skeletal mesh animation instance.
The anim instance in Unreal Engine is a system that allows animating a skeletal mesh with complex animation blend and logic. So using that to drive the morph animations allows me to do more complex and dynamic animations.
In the video I show a simple example with a gate animating a Morph Cone that comes out of the floor.
The game sets the gate state and the Anim Instance handles animation. You can see the gate logic in the Anim Instance view.
Dynamic Mesh Morph: Rendering Update
TL;DR: Support rendering for non-collision players & New Render task distribution.
During June, I did a final pass on TagDynamicMeshMorph. You can now play as GameMaster inside Talas’ digestive system while rendering avoids micro-freezes. This pass improves render task handling and support for players without collisions, such as GameMaster or Spectator.
Game Master & Spectator Rendering
With new gameplay interactions in the future, it will be possible to interact with the digestive system when you play as GameMaster.
So I updated the TagDynamicMeshMorph to make the render detection usable when the player has no collisions.
So the render now updates when you play as GameMaster or Spectator inside Talas’ digestive system.
Before, it was updated only once every second because the player was not detected.
Render Task Distribution
Following non-collision rendering support, I also brought collision-update optimizations into render updates, with a task distribution system that handles render section splitting.
More details can be found in the Devblog of May 2026.
All that tech just for Talas Digestive System. :>
New Hold for Interactions
TL;DR: Updated the interaction system to support hold interactions.
I worked on my interaction system to support hold interactions. This will be used in the digestive system to interact with flesh walls. (More details lower in this devblog.)
I also updated the gameplay sounds to give better feedback for the actions.
(Activate the sound on the video below)
Before, the interaction system was focused on simple interaction triggers, but now I manage the action type and interaction states.
- This allows me to track who is holding an interaction,
- Whether the player needs to release a previous interaction before starting a new one,
- Whether a VR player can press the same button with both hands,
- Etc.
And that also works in multiplayer and VR of course.
Digestive System: Flesh Wall Interaction
TL;DR: New flesh wall interaction in Talas digestive system with organic animations and physics.
Now, with the new interaction changes, non-deterministic animations, and a bit of math and physics, I can do that:
Interacting with the flesh walls in the digestive system gives things a more real and immersive feel.
Additionally I can use that to add more gameplay interactions.
Here you need to pull the flesh wall to open the way.
Rig Generator
TL;DR: Details about my rig generator update with the new node and pin properties.
I worked on the rig generator to add more node-related features. This is mainly internal work that will save time in the future.
A rig is a tool used to animate a character or other objects, as I already mentioned in older devblogs.
In-game, it is used by many objects, including Cobble and Talas.
- I started with a simple Python script to generate Talas’ rig.
- With MMVS v0.3.0 I did a full tool to generate rigs.
- With MMVS v0.4.0 I added an option with several presets for multiple characters.
- Later I redid it to make it modular with layers of executions. (Every layer adding more logic to the rig.)
- Then I moved the layer execution to node execution. (Making it possible to create groups of nodes and manage branches of execution.)
And during this month I created a new base to manage nodes with properties. Before every node was simple execution that applies changes to the rig with static properties.
Now it will be possible to manage the properties with nodes as well and add more logic with data combinations and conditions.
When a node needs data:
- It runs a function to get the data directly from the input pin.
- The input pin returns the default value if it is not linked. Else, it runs a function to get the value from the linked node.
- The linked node manages the data internally, calculates it with its internal code, or gets it from a property or an input pin.
- And this continues recursively until data is returned.
This took me a lot of time because I am not very familiar with Blender nodes in Python, because I need to do everything from scratch, and because I cannot work with the source code as I’m used to do with C++ in Unreal Engine.
But in the end, that will save me a lot of time when I need to create new rigs.
The next step will be to redo all execution nodes to use the new data nodes and properties but I will do that step by step.
Fluid Volumes R&D
TL;DR: R&D on dynamic fluid volumes, with a reworked custom system.
I worked on water and fluid volumes to standardize usage and make volumes move up and down. The idea is to add in the future some gameplays with Talas stomach and the digestive system to fill it with gastric fluids periodically.
I started my tests using the native Unreal Water System, but sadly it doesn’t support moving water at all. The surface moves at runtime and interacts with physics objects, but I can’t move the water volume or dynamically set up a height.
So that’s useless for what I wanted to do.
So, I focused on my own water system. The render quality is not as good yet, but I have more control and can improve quality later.
During my tests, I reworked the script to standardize it. A fluid volume now manages interactions depending on the volume, such as shaders, underwater visual and audio effects, physics, etc.
- In the next video, first pool is Unreal Native Water Plugin, nice render but all is static.
- Second is my own water: I can move it and I have full control over it.
- Third is my own water used for Talas gastric acid.
In the future I will focus deeper on fluid volumes with the Bathroom update that will add new gameplay related to water and fluids.