Godot Port Update #7

Porting stats
Porting progress: ~75%
Hours with Godot: ~434h
Scripts transferred: 67
3D-assets transferred: 55
Audio files transferred: 211
Godot project size: 12.7GB

What are these Godot Port Updates?

Porting a game to another engine is a big and rather unique thing, so these post are my way of documenting this porting experience and giving some honest updates on how the porting process is going.

These posts are a weekly thing until all the core features have been ported and along with these posts there are also Patreon test builds each week. These test builds are directed to small audience and the main purpose is to get performance data and early feedback on the ported features.

What has been ported this week?

- AI spawner
- AI sensor
- AI hearing
- AI visibility states
- AI navigation
- AI animation blending
- AI hitbox system
- AI interaction (doors)
- AI wander (behavior)
- AI combat (behavior)
- AI directional audio
- AI surface detection
- AI bullet SFX
- AI footsteps
- Player damage impact
- Player damage HUD effect
- Player damage SFX
- KP-31 + animations
- Obstruction visibility layers
- Terrain / map framing
- Additional weapon stats (tooltip)
- Jump & land footsteps
- New building

Initial AI worries

This last week was all about porting the AI system to Godot. AI was the last "scary" porting topic for this project meaning there could have been a lot of unwanted surprises when it comes to Godot's features for handling the AI.

My biggest concerns were related to navigation mesh baking, pathfinding performance, animation retargeting and movement related blending systems. If any of these would have been unusable, it would have created fairly big dent to this entire porting timeline.

Navigation meshes and pathfinding

I started the AI week by testing the Godot's native method for generating navigation meshes. These initial tests were promising but there were some learning curve for understanding how you can manipulate the generated result to your preference.

Once I found fairly good initial parameters, then it was time to start figuring out ways to exclude certain areas and elements from the generated meshes.

In this image, you can see for example how the generated mesh is attached to the roof and areas which are unreachable for the AI.



This unreachable area / region excluding process is really important, since I know from prior experience that if your generated navigation mesh is filled with unreachable areas, the pathfinding process will introduce nasty stutters in some point with most pathfinding algorithms.

I confirmed this unreachable area stutters thing by testing all kinds unreachable events with the AI and like expected the stutters became pretty severe even when trying to limit them through Godot's "isReachable" path conditionals.

Removing the pathfinding stutters

The pathfinding (AI navigation) in Godot is based on this A* pathfinding algorithm. I have been working with A* previously multiple times and I know pretty well how it performs in certain situations and what situations are considered as "expensive calculations".

The core idea of A* is that it calculates the shortest possible path to given target by estimating so called "travel cost" based on certain points. This method is really common in video games but it has certain performance problems when it comes to those unreachable areas.

So, I started removing those bad areas in order to negate the possibility for expensive calculations and easiest method was simply through layer masks but those weren't enough for certain situations, so I also brought multiple of my trusted "carver objects" to Godot.

These carver objects are custom invisible meshes that are designed to fool the navigation mesh generation. Carver objects are basically your manual way of modifying the navigation mesh (make a hole or add an custom area) and they are linked to objects that are too complex or otherwise problematic for the native mesh generation.

With these simple layer masks and carver objects, I removed all the unreachable areas and after that the pathfinding stutters were gone since those expensive calculations are not given to the AI agent.

Extra mention: For those who are interested, these expensive calculations might occur in scenarios where AI behavior uses random navigation through custom functions like random point within a sphere (Wander behaviors) or random point within an annulus (Evade behaviors) and those might provide unreachable target points to the AI.

Animation tools were great

The rest of the initial worries were related to animations and how to blend them nicely with the AI's movement and velocity.

Luckily Godot supported animation retargeting through so called animation libraries and there was also support for blend trees which are my favorite way of doing stuff like direction based combat strafing etc.

In general, I think Godot has a really nice toolset when it comes to animation blending and those are also easily controllable through code which is really important.

I think the only painpoints that I had with animation related tests were the ragdolls since getting good initial results with those seemed unreasonable hard but it might be too early to judge since it can also might be my fault for not understanding all the physics parameters, bone joint types etc.

AI week was a success

To summarize, this last week were mostly spent on these AI topics and I'm really happy with the end results.

Initial worries were unnecessary and through some custom tools, I managed to get really solid foundation for the AI which is now playable, animations blend nicely, directional audio works like expected and pathfinding + all the AI sensors (LOS and hearing) performs well for this game idea.

This week it's time to port the attachment system and I have already multiple improvements designed for that compared to the previous Unity version.

- Antti (Developer)