Car Driving Game AI - Status Update

This video is a status update on the cars and their driving AI, in the video game Traction Point. Read more in the development blog at www.madrigalgames.com/
Intro: 0:00
Issuing AI commands: 2:17
Dynamic obstacle avoidance: 5:31
Soft vs. hard navmesh obstacles: 7:30
Getting around the world: 10:45
Loading a larger vehicle: 12:45
Fitting into smaller places: 13:41
Missing an obstacle component: 15:11
Vehicle-specific navmeshes: 18:54
Lifting a vehicle: 21:36
A tricky situation: 23:50
Anyone wanna see the code?: 25:37
Outro: 26:31

[@FINXainarskrastins]

Idea for final goal concept. Explore -> fuel management->find more cars ->puzzles made by the terrain->Easter egg collectibles as cosmetics->co-op fun like races or challenges->vs mode where the world is mirrored and its like a capture the flag/king of the hill thing->back to strategy concepts like commanding ai cars to go on missions->rescue a car by figuring out how to get to it and how to get it back->standing on buttons to keep gates open->frustration noises when the ai can't reach a place. Idk a lot of ideas.

[@WisKy64VT]

This game is looking super cool! Enjoy your vacation!

[@MadrigalGames]

Thanks!

[@Jdgo95]

Hello Sebastian,
Nice video! I was wondering, does the NavMesh drive the vehicle or is it the physics simulation? How much resolution does the tessellation have on the NavMesh? Did you bake the NavMesh? Do you have a granny crane for those situations 24:00 ? (Your project is superb, I'm interested in knowing more about the topic of networks in general. If you use any Zig socket libraries?)

[@MadrigalGames]

Hi Juan, thanks! Let's see if I can answer all of your questions in order.
The NavMesh doesn't take any initiative over any gameplay event or system. It just sits there and answer questions like "Can a car drive here?" or "What is the path from here to there?". The physics system also doesn't technically drive the vehicle. It just simulates how the vehicle moves when certain inputs are applied, such as accelerating, braking and steering.
The vehicle is driven by giving these inputs to the physics system, and it works the same whether the driver is a human player or an AI agent. The physics system doesn't know or care which one it is. That's what makes this so tricky to implement an AI for, because I do not (yet at least) "cheat" by teleporting the car around. Instead, I calculate what the inputs need to be to get the car from point A to B.
Regarding the tesselation resolution, it depends on what you means by "resolution". I use Recast and Detour for building and querying the NavMesh respectively, and Recast has a bunch of settings you need to give it when building the NavMesh (so yes I build, or "bake", the NavMesh in the level editor). I can list the settings here but I don't think that's what you were asking for. If you'd like me to go into more detail, I can do that.
Not sure what you mean by "granny crane". I do have a bunch of ideas on how to tackle the issue you refer to. One such idea is limiting the AIs ability to make reverse-turns in tight spaces. Instead, they would switch into a sort of "reverse mode" where they follow the driveline normally, but with all the inputs flipped, to make the vehicle back out of the tight space until it reaches a larger area where there is more space to make reverse-turns. I might have to make a follow-up video when the Mother vehicle knows how to get out of that area :)
For the network transport I use ENet: github.com/lsalzman/enet. It's buried pretty deep in the game engine and I have my own RPC and propagation layers built on top of it so I rarely have to interact with it directly. However, as it is a C-library, you should be able to use it directly from Zig.

[@HobokerDev]

Is this navmesh recast or something else?

[@MadrigalGames]

Yep, it's Recast and Detour.