Indie-Resource.com

Good day,

I was playing around with the example 13.6-texturemaps-load-tiled and was stress-testing the engine performance, while increasing the "CharacterAI" count from 20 to 200.
I ran into performance issues, before I reached 100 entities.
My question is as follows:
What is the theoretical capability of the engine in regards to entity count, disregarding box2d integration (just the average overhead of tick and render calls, and movement)?
Is there anything in the example, that could cause the performance to be sub-optimal, so I could achieve higher entity counts by cutting some corners i.e disabling physics?

In general, how would I go about implementing swarm-style play(think hordes in l4d) with ~200 entities (As far as I tested, pathfinding was not the bottleneck), without degrading the performance too heavily? To clarfily, I just want to understand where the performance bottlenecks are in the engine and how to avoid them.

-Uni

Uni wrote:Good day,

I was playing around with the example 13.6-texturemaps-load-tiled and was stress-testing the engine performance, while increasing the "CharacterAI" count from 20 to 200.
I ran into performance issues, before I reached 100 entities.
My question is as follows:
What is the theoretical capability of the engine in regards to entity count, disregarding box2d integration (just the average overhead of tick and render calls, and movement)?
Is there anything in the example, that could cause the performance to be sub-optimal, so I could achieve higher entity counts by cutting some corners i.e disabling physics?

In general, how would I go about implementing swarm-style play(think hordes in l4d) with ~200 entities (As far as I tested, pathfinding was not the bottleneck), without degrading the performance too heavily? To clarfily, I just want to understand where the performance bottlenecks are in the engine and how to avoid them.

-Uni

Hey there! The example is not optimised for performance.

With tweaks to the example I was able to have 200 AI entities + the player at 60 fps. The big performance hit will come from drawing the path the entity is traversing as this is meant for debugging and not for live use.

The second change is to add the entity manager component to the objectScene which makes sure that draw calls are not made for entities unless they are in a visible area of a viewport.

I have updated the engine's ige repo dev branch with my changes.

Here's a screeny of the example running with 200 AI entities at 60fps (click it to view full image). The system shows 118 DPT because a number of the entities are "off screen" but even when almost all of them are on screen it still performs at 60 fps.

To answer your main question about performance bottlenecks, this is a really wide question without knowing the game you are creating and what will be on screen and what your deployment platforms will be.

Isometric uses more cpu than 2d, box2d physics will account for some cpu cycles, moving entities use more cpu than static ones etc etc.

Examples in the repo tend not to be performance optimised because they exist to demonstrate (and test) particular features of the engine. That said if you have a specific performance issue (like the one above) I will always try to help solve it for you.

That is exactly what I was looking for, thank you.

Uni wrote:That is exactly what I was looking for, thank you.

No worries mate