Best engine for lot's of entities?

[JasonX]

Darkplaces seemed like a good choice, but it's framerate drops with about 100 monsters at the screen. Is there a good engine for handling lot's of enemies? FitzQuake in software mode, maybe?

[Spirit]

From what I know: It depends (tm) on the logic rather than the polycount.

You will want an advanced protocol and one of FTE/DP/Quakespasm/DirectQ I think.

[mh]

[Spike]

regarding network protocols:
vanilla: 600
dp: 32k
fitzquake/quakespasm: 65k
fte: 262k
these are protocol limits rather than default limits. you may need to set pr_maxedicts, max_edicts, pr_ssqc_memsize, or other cvars in order to actually utilise this many ents.

regarding rendering:
be sure to disable any realtime lighting... you don't want everything being drawn 500 times. 100 monsters all using their own muzzleflashes and dlights will destroy your framerate, while the all shadows from static lighting will do the same.
reflective water and other such effects can also result in increased rendering costs per monster.

regarding gamecode:
be aware that idle monsters are not free. they will all be doing various pvs etc checks, and firing off tracelines to see if the player is visible yet. they'll be checking their contents values constantly too. much of this cost will come in bursts, so while you might be able to atain 60fps, you'll get 10 spikes every second that make the game feel like its running at 12 fps or so.
it can thus pay off to activate areas of monsters based upon triggers rather than leaving them all active from the start. this can reduce cpu load quite a lot.

tldr:
100 monsters onscreen at 60fps should be perfectly achievable on any of the engines spirit mentioned, so long as there are no extra poorly-scaling things like rtlights, and so long as the monster thinks are staggered slightly.

[Tr3B]

There was a discussion about RBDOOM-3-BFG running 300 zombies. http://idtechforums.fuzzylogicinc.com/i ... opic=198.0

I had really big problems in XreaL with the Q3A netcode when dealing with many entities. The constant updates from the client game to the renderer completely suck with the Q3A architecture.
Doom 3 allows more entities if you run it in single player because the single player execution skips all netcode and entity delta calculations. It also holds all entities in its own renderer world so you only need to update them if needed.
The BFG engine even runs the entire game code and all physics/ai scripting inside in a separate thread which gives another big performance boost.

[JasonX]

Would it be possible to write some entity pooling on QuakeC code? Or this has to be something on the engine side? Would it help to just remanage entities, instead of destroying/instancing them?

Also, i plan to use very low-poly game models (< 500 polys), both for enemies and other data... would this help the framerate, or it's irrelevant comparing to 2k/3k models? Pardon my ignorance guys, and thanks for all the help!

[Spike]

http://triptohell.info/moodles/junk/fte ... shader.png
(that's about 4.8 million indicies, 250 times a second)
or in other words, if the engine avoids deprecated methods then vertex counts are pretty much irrelevent nowadays.
(I should probably take the time to point out that these are NOT entities, but rather geometry generated by the usage of a shader on the surface which they are upon, meaning its purely static just geometry with very little overhead).

using a base like my purecsqc mod (which completely disregards ssqc and is thus single-player-only) allows you to skip all of the network protocol overhead, but you still have overheads feeding the entities to the renderer and then on to opengl, and you'll need the qc to do your interpolation - this can actually be slower (because qc is executed via an interpreter rather than a jit).

builtins that itterate through lists (like the find builtin) will always have poor scaling with respect to high entity counts, so try to avoid those.
This includes traceline of course. the more entities you have in your room, the more tracelines you're generating and the more entities your tracelines are potentially able to hit.

there's a few ways to check where your overheads are:
r_norefresh 1:
this setting will skip 3d rendering entirely (you'll probably want gl_clear), leaving any 2d stuff including framerate displays on screen. if there's not much difference, then you know the renderer isn't your slowdown.
r_drawentities 0:
unlike r_norefresh, this setting will still draw the world, and probably some other things like particles. you can compare the two to determine if your slowdown is caused by an excessively complex world bsp entity.
pause:
by pausing the game, you inhibit all serverside physics and qc logic. if the framerate goes up then the server is spending far too long servicing movetypes or think functions.
profiling:
most engines support profiling in some way. both dp and fte can give wall-clock times for individual qc functions ('apropos profile' to see the commands). even vanilla quake can show you how many qc opcodes have been executed (but sadly this does not include the duration of time spent within builtins).