One particle per enemy for MANY enemies

[Jambo]

Hello,

I'm thinking of using Obi for the physics of enemies in my game.  The enemies will be extremely simple: 

• Modelled as a single sphere
  
• Need to collide with terrain (move over the surface of the terrain)
  
• Need to collide (repel) each other to avoid getting clumped
  

I was thinking of using one particle per enemy.

I thought I would use Obi because I suspect it's more efficient than Unity's physics engine, and I would like to have a lot of enemies.  

I'm thinking I'll need to:

1. Implement my own ObiActor which is basically a container for all enemies
   
2. Implement my own blueprint, which specifies the pool of enemies
   
3. ....set them all to inactive, and active them as enemies spawn?
   
   

Does this sound like a reasonable use of Obi, or am I barking up the wrong tree?

[josemendez]

I was thinking of using one particle per enemy.

I thought I would use Obi because I suspect it's more efficient than Unity's physics engine, and I would like to have a lot of enemies.  

Hi,

Using Obi for this is probably going to make things overly complicated, as it is specifically optimized to be a particle system and it does not contemplate custom character rendering or logic.

My advice would be to use Unity's DOTS, its built on the same technology Obi is (Jobs + Burst) plus an ECS paradigm and it is designed specifically for use cases similar to yours:
https://unity.com/dots

kind regards,

[Jambo]

Oh wow, I wasn't aware of Unity DOTs. It looks like a great framework, though perhaps overkill for what I want to achieve. 

I'm not too worried about rendering: I can do my own thing for that (e.g. use the Unity Animation-Instancing package) to efficiently render many animated models. 

So far, I've had excellent results using Obi: I've basically made my own custom actor and blueprint that really don't do anything at all other than provision 5k particles.  I've then added some addition movement logic using custom jobs / IJobParallelFor.  For additional enemy state, I'm using my own data structure that maps 1:1 to the actor indices. 

So far, I'm using the Obi Particle Renderer to see what's going on, but will soon switch to Animation Instancing and have something animated. 

I'm not planning for the game to be online multiplayer, which would probably be the biggest benefit of going with DOTs. 

I'll post a video when I have something presentable

[josemendez]

Oh wow, I wasn't aware of Unity DOTs. It looks like a great framework, though perhaps overkill for what I want to achieve. 
[...]
I'm not planning for the game to be online multiplayer, which would probably be the biggest benefit of going with DOTs. 

DOTS = Burst + Jobs + ECS. It's not necessarily related to online multiplayer (eg. you can also have thousands of enemies in local single player), the idea behind it is to lay out data in a way that's efficient for the computer to process, so that it can deal with much larger amounts of data. So instead of having the "GameObject" concept that both stores data (scattered around in memory) and implements logic, component data is stored in flat arrays that can be efficiently processed in parallel using "systems", and "entities" are just indices into those arrays. Hence the name Entity Component System. If it sounds similar to what Obi does it's because it is!

Obi uses Burst and Jobs, but instead of using Unity's ECS system it rolls out a custom ECS implementation specifically tailored to particles/constraints and builds a physics engine on top of it. So in a way, it's 66% DOTS.

So far, I've had excellent results using Obi: I've basically made my own custom actor and blueprint that really don't do anything at all other than provision 5k particles.  I've then added some addition movement logic using custom jobs / IJobParallelFor.  For additional enemy state, I'm using my own data structure that maps 1:1 to the actor indices. 

If it works for you, then it's fine. Depending on how complex your enemy logic gets you might benefit from a more generic ECS system, but I guess it depends on the specifics of your game more than anything.

best of luck with your somewhat unorthodox use case , and let me know if you need any help!

kind regards,

[Jambo]

DOTS = Burst + Jobs + ECS. It's not necessarily related to online multiplayer (eg. you can also have thousands of enemies in local single player), the idea behind it is to lay out data in a way that's efficient for the computer to process, so that it can deal with much larger amounts of data. So instead of having the "GameObject" concept that both stores data (scattered around in memory) and implements logic, component data is stored in flat arrays that can be efficiently processed in parallel using "systems", and "entities" are just indices into those arrays. Hence the name Entity Component System. If it sounds similar to what Obi does it's because it is!

Yes, I understand. The reason I mentioned multiplayer is this:

My understanding is that the DOTS Physics engine is designed to be deterministic and to work with Netcode. My thinking is that there must be some compromises in order to achieve this.

Optional aside: In the past, I've implemented my own physics engine and low-latency networking library (this was in Java, built on of Libgdx and KryoNet). I even made a few games with it that I still play with old schoolfriends occasionally. In order to do this, I created my own Fixed Point library to guarantee determinism (yep, I implemented most maths functions, including trig, in Fixed Point  - lots of bit shifting and lookup tables ) ...anyway, my experience was that it was challenging, and came with performance compromises compared to just using floats. I don't think Unity DOTS Physics does exactly this, but I'm guessing there must be some compromises. 

The game I'm currently making will be more like, let's say, Vampire Survivors - nothing online, but epic quantities of enemies. Therefore, I want a very simple physics engine with great performance. Obi seems a pretty good fit for this.

Here's the promised video.




I pre-bake the animation meshes in a manner similar to this, and then I've implemented my own renderer that uses GPU instancing to render masses of enemies efficiently (i.e. all enemies of the same type on the same frame of animation are drawn with a single call). 

I can go up to 5k enemies without my GPU sweating, but my CPU starts to struggle at 1k or so - probably because it's 7 years old now. I'll need to do a bit of profiling to see.

I've not yet looked at how Obi interacts with Terrain - do you think this could potentially be a bottleneck?