February 2025

General

The devblogs for February and March were made at the same time

Situation System Enter / Exit

With the new Vore animations, I must procedurally edit the enter and the exit animations of a situation.

To explain, the animations that are managed by the situation system are fully modular: When Talas sits on a chair the code will load an animation layer with all specific animations and the code that manages it.

Before, the animations for entering and exit were loaded and called outside the layer directly in the character animation script. This is fine but the animation layer can't directly edit these animations.
Now the enter and the exit animations are loaded and called directly in the animation layer. So, I can blend it with other animations from the animation layer.

This is what I do here: The entering animation to make Talas open his beak is now blended with the animation that set Talas height.

Situation System Net code update

Following the situation update with the Enter and Exit actions that are now in the animation layer, I had to make some changes to the net code of my situation system because it no longer worked in multiplayer.

This also allowed me to simplify the different procedures and optimize the net code.

Previously, on the server side, when Talas used a situation, the server replicated the different actions made by Talas to the client via requests, in addition to the state

Talas uses this situation.
Talas uses this position.
Talas uses the action to sit on the chair.
Talas uses this position.
Talas uses the action to change position on the chair.
Talas uses this position
Talas uses the action to get up from the chair
Talas does not use this situation anymore

This would cause some issues because some requests may get out of sync or get lost between the server and the client.

Now the server will simply send a defined state and let the client handle all the actions on its side to arrive at a state identical to that of the server

Talas uses this situation with this position.
Talas uses this position
Talas does not use this situation anymore

In a way, the server just sends the state of a door (open or closed) and lets the client handle the animation of the door each time this state is updated.

Slime System Optimization Fix

I have updated the tongue slime configuration with the new tongue skeleton, and this made me notice an issue with the optimization code.

The code should stop updating and destroy the strands of saliva when it's not visible after a delay, but once it is destroyed the visibility zone (object bound) turns to a simple point that's never visible because it is hidden inside Talas’ head. So, the strands of saliva rarely respawn.

Now the visibility zone is set to Talas' head.

This of course also fixes the issue on the other use of it, like the sweat between the toes.

Communication on Contextual Interactions

I'm not sure if I have already spoken about the interaction system, like the other systems it fully made by me. My interaction system works like a tree with dynamic branches, that created or destroyed depending on the context.

Example in non-VR a new branch is created to an interaction module making possible for the player to interact which what the player character sees and reach.
If I switch to VR the branch is destroyed, and two new branches are created linked to other modules used for both hands. So, the VR player can now interact with the objects that enter the hand zones.
If the player enters in a vehicle a third branch is created making them possible to interact with the vehicle interactions: “Exit from left” or “Exit from right”.

Many information passes through these branches letting the game know what is possible, who handles it, and what to show to the player.

During this month I worked on the new interactions when Cobble is on the tongue making him possible to struggle or exit when that possible. So, I did a pass on the interaction system to make it simpler to use, optimize the process and kept in cached some information.

More Root Offset Issues

Last month I explained how I was able to animate Cobble character offset depending on Talas body using the item bones. The issue with that is that I need to animate Talas with the item bone for every animation of Cobble.

Cobble can have several positions inside Talas' beak.

He can be layered with the head toward the front of the beak.
Or layered with the head toward the throat.

If Talas licks his beak, the animation of Cobble needs to be different depending on his position so, the animated item bone can't fit with both animations.

Finally, the best solution I found is to use the item bone for very specific animations and use the root motion for others.

The root motion is a technique that offsets the character from his attach point using the movement of the root bone of his own animation.

Example when Talas switch the position of Cobble in his beak or spit him, I use it the item bone to animate the offset of Cobble.
And for common animations like when Talas licks his beak or swallow, I use the root motion offset.

Also, Cobble will no longer be using the item bone of Talas for his positions in his beak. He will be directly attached to the tongue bone and will switch the attachment depending on the animations of Talas.

In game the switch is done in 1 frame, and it is completely invisible to the player.

Then I had to update all the Vore animations with Cobble. But thankfully, I had good tools to help me.

This is a common trick to move the character root without breaking the animation by saving the absolute positions. I used often this with the offset changes so, I added a tool to do that in my addon and save time.

Now when Cobble is idle in the code will automatically set the target offset depending on his position. (It’s the short rotation you can see when I teleport inside the maw.)

And when not idle or the animation will choose how move Cobble offset using the root motion or Talas’s item bone.

Stuck Zones Manager moved to C++

This month I migrated the code to manage the spawned stuck zones in C++ It’s not the same code I spoke about in January, last time that was directly how the stuck zone works with the character code.

This makes the code more stable and changes the method to configure the stuck zone manager.

Toy car Mesh and Collision Update

During this month I made many small changes to the toy car.

First, I reworked the toy car's wheel collisions.

Before I was using a sphere cast. It's perfect to detect the full shape of the wheel but the collision does not match a true cylindrical shape, and it detected the collision on the sides of the wheels. With that I'm forced to make the car collision wider to avoid the issue you can see at the end of this video when the wheel collision touches the wall.

Now I'm using raycast, this time the collision will detect a single line from the center of the wheel to the floor.

This makes some issues when the wheel slowly rolls over an obstacle like in the next video, and the car can easily get stuck. But the side collisions are way better.

It's possible to simulate a cylinder collision using a mix of a box on a sphere collision (Collision considered as valid only if the cast success with a box and a sphere cast at the same time.) But for that I need to edit the engine source code as I did in the past with the VR eyes spacing but that's too complicated to manage.

Still about the Toy Car I updated the vehicle hierarchy to support the new stuck zone method and the use of static meshes for the vehicle’s parts.

In the past it was more common to use a fully deformable mesh (Skeletal Mesh) for animated assets like vehicles, doors, weapons, etc. Now it is more common to use static meshes for static parts and attach them to an animated skeleton. (More optimized with new techs and better to manage.)

That’s what I did for the orbs, the doors and the most animated assets in game. That's what I did for the Toy Car this month.

In the toy car I use static meshes for the chassis, the wheels, the chair. And deformable for the antenna.

Situation System Mesh Offset and Root Motion

By working on the Toy Car, I noticed two big issues with the Situation System:

That my situation system doesn’t support entrance on moving situations.
And that I made an error in the character mesh offset math.

About mesh offset math, before I used the character center with the floor distance to calculate the target character position when entering a situation, now I directly use the character mesh and use it local offset to move the character.

I think it’s more logical because the offset is related to the animation position.

And about the moving situations the code will calculate a relative position to update the character movement and not the absolute position.

Now that work good in dynamic situation like the Toy Car, and the preview will show the new math position.

Following this change, I had to update all situation configurations with the new offset.

I reviewed the Talas Bed Situation and fixed an old issue that I couldn’t solve in the past while working on the animation update (v0.4.4 to v0.4.4.3).

Previously, when Talas got into a situation like the bed, his actor moved to the center of the bed, and the animation adjusted his body to the correct position. This created many constraints that I had to fix individually.
Now, with the use of Root Motion and the new functionalities I added to control the character's offsets, I can move the actor to his real position.

In the video you can see the real character position with the red capsule. Before the capsule was stuck at the center of the bed.

I did the same change as the bed on the sofa table with the character offset

Modular system Example Use

Still related to my situation system, I updated the code that makes Cobble automatically switch between animation modes. Here, I show how all the systems blend and work together.

Talas and Cobble are free. (White)
Talas enters the situation system (Red) and plays the "Grab with Beak" animation (Purple).
Talas’ animation triggers the grab event, and Cobble gets grabbed using the Grab System (Blue).
- When Cobble is grabbed, he is attached using the Stuck Zone system (Yellow).
- Cobble uses Talas' situation as a master and enters the situation as a slave (Dark Red).
- He then plays the slave animation (Purple).
Talas exits the situation and is free (White).
- Cobble instantly enters the "In Beak" situation (Red), and the player is free to play animations (Purple).
Talas enters the situation system again (Red) and plays the "Spit on Floor" animation (Purple).
- Cobble exits the "In Beak" situation (Red) and enters Talas' situation as a slave (Dark Red).
- He then plays the slave animation (Purple).
Talas' animation triggers the release event, and Cobble gets released from the Grab System (Blue).
- Cobble detaches from the Stuck Zone system (Yellow).
- He exits Talas' situation (Dark Red) and stops playing the slave animation (Purple).
- Cobble is free (White).
Talas finishes the animation (Purple) and exits the situation (Red)
- Talas is free (White).

Here is the result in the game:

The only commands I send (Green) are:

"Grab here"
"Spit micro"
An input from the player to struggle.

Everything else is automatically managed by the code. By the way, you may notice that Cobble is instantly rotated when Talas spits. That’s because I haven't yet created an animation for cobble when spit with this orientation.

More Animations

I finished the base Maw Exhibition animations.