ECS/com.unity.physics + MLAPI = Crazy?

Hey all,

I've got a particular use case that I've been banging my head against for a couple days and I think I'm just going to have to give up on using ECS for now, but I wanted to ask the community first... Here's my situation:

I'm working on a project with a couple specific requirements:
1) 10 player networked/local multiplayer co-op in an "open world" isometric game.
2) "Hundreds" of AI agents active in the map at any one time (~1000 AI agents an upper bound)

Decent challenge, eh?

BUT, so far at least, all is good! I've got 1000 AI agents running around, parallelized GOAP planning, navigating, networked what I want down to client, etc.

I've been using RaycastCommand for AI sight sensing, and it's meeting my perf requirements beautifully, but I have LOTS of AI sensors to build so naturally I started diving into the new Unity Physics package and ECS a bit. Did a couple of small tests, seems like some slick tech (I've built something very similar in the past) and I would LOVE to use both Unity Physics and ECS specifically for the AI sensors.

However, I can't seem to get a working example of Unity Physics working with an MLAPI game object. I've tried making an ECS container sub-object, physics sub-objects, etc, but I haven't been able to get something that works. I started with the Boss Room sample and tried to "com.unity.physics-ify" it, but so far no dice.

So the question is this:

Is Unity Physics/ECS and MLAPI a dead-end or is there a path I can take to get a Unity Physics/ECS + MLAPI powered workflow for my AI sensors?

I took a look at NetCode but my understanding is that MLAPI and NetCode aren't compatible with one another. And I definitely don't want to build an ECS only solution for this project (I worked on an ECS engine for a couple years and have some feels about ECS only workflows...)

I'm currently doing some threading myself (w/13+ years in AAA, very comfortable with threading) so my current plan is "roll my own parallel solution" but I wanted to ask here first.

Thoughts?

Thanks!

 

I'm not too familiar with MLAPI, but my guess is you will need to employ this pattern:
1) Copy state from MLAPI-managed data to ECS world.
2) Run ECS simulation.
3) Copy ECS data back to MLAPI-managed state.

I would prioritize Burst over threading. Single-threaded naive Burst usually beats managed threaded code even on 16 core systems. If you are going to "roll your own parallel solution", at least use the C# job system. You don't need Entities for that. Depending on the details of your use case (I suspect you just need spatial queries since this is AI), I may have some code you can borrow that may be easier to adapt to your needs.

 

Thanks for the response! The 3 step approach you suggested was what I tried, though I'm sure I did something goofy somewhere. I *might* have a thought here, let's see if this works...

Burst looks killer, glad I looked into it! However, I've got several reference types in systems that would benefit from threading, and I really don't want to take the time to go do some clever ECS conversion for all of them... Maybe one day, but this project needs "faster turnaround" than I think I can reasonably achieve with ECS' blittable value type requirements.

Back to the problem at hand...

I think, for now anyway, I'll stick to the few Jobs I have and do some custom spatial queries when needed (jobified, of course) and not worry about com.unity.physics package support. Seems like the best approach for my needs. Basically the one system that I don't want to jobify is my GOAP AI implementation. I'm sure it's possible, I just don't want to spend the time doing it lol. Much more impactful fish to fry

That said, I would love to see any code you have to offer

Thanks again!

 

You can find the documentation entry-point to some of my physics code here: https://github.com/Dreaming381/Lati...ter/Documentation~/Psyshock Physics/README.md

Basically I have spheres, capsules, boxes, and compounds which all have AABBs, raycasts, collider casts, distance, and point queries. With the exception of compounds, they are all values types which you can create dynamically at runtime. And they all can be converted to a Collider base type for easier abstractions.

There's also a multithreaded broadphase algorithm. That part does depend on the existance of an Entity type, but it mostly checks to make sure the values are unique for safety reasons. Otherwise you can use it without ECS by creating the collision layers using the NativeArray<ColliderBody> API.

So yeah. Feel free to borrow whatever pieces you need if it saves you time!

 

Out of curiosity, how do you plan on syncing all across 10 players? I'd imagine that the bandwidth needed would be huge unless you opted for some fancy steplock shenanigans.

 

I'm planning on having pretty high network requirements for this project potentially, though my initial tests with MLAPI leave me pretty optimistic. Last project had ~100 agents running around using ~7Kbps bandwidth. But we'll see