Increase the Limit of Simultaneous Enemies

[Nanostrike]

I am aware that my computer is not the greatest powerhouse there, but even one RO custom map with tons of trees and large enough that it takes 15min+ to do one lap around with a vehicle works beter on 50 player server than KF with 80+ active specimen

Not to mention that it slows down even further when you add the 6 Players in. I've been able to get 70 running silky smooth on single-player...but me and a few buddies tried 70 on a Listen server and it started to lag like mad...I can only imagine it'll get significantly worse with each specimen added after that point, even on a dedicated server...

 

[Rak]

Your suggestion would make the server lag ridiculously strenuous on all but the beefiest of systems. I agree that there should be more, but 50 per person is a bit much. Maybe in suicidal mode have higher spawn ratios?

Red Orchestra Servers can handle 50(can even go to 64) HUMAN players and it doesn't lag both clients and servers. So numbers are not a problem.

 

[Griever]

There really should be more specimens coming... In big maps you search for specimens rather than running away from them blasting them with all u got. It shouldn't be like that, There must be 'too' many specimens for each player, that's what I call horror SURVIVAL. It's like horror specimen hunting game now.

 

[Templarion]

set KFMod.KFGameType MaxZombiesOnce 100 works perfectly! It is awesome. Makes the outdoor maps much more harder as they should be. This is what I always wanted. Now they are pouring in from every direction with massive numbers.

mastertheknife, thank you for that command line. I actually tried it before but for some reason it didn't work then (I probably misspelled it). Anyway, thank you for putting me to test it again.

Btw, in 4 player game, we had all 100 zombies in our screen (we actually counted them ) and we noticed no lag at all. The player with the poorest computer (about 4 years old PC) said that his FPS dropped somewhere between 23-26 but it was still very playable.

So, don't use performance issues as an argument anymore!

 

[GeneticArmor]

Gonna try this with my stationary computer, hopefully it'll make things more interesting ^^

 

[mastertheknife]

set KFMod.KFGameType MaxZombiesOnce 100 works perfectly! It is awesome. Makes the outdoor maps much more harder as they should be. This is what I always wanted. Now they are pouring in from every direction with massive numbers.

mastertheknife, thank you for that command line. I actually tried it before but for some reason it didn't work then (I probably misspelled it). Anyway, thank you for putting me to test it again.

Btw, in 4 player game, we had all 100 zombies in our screen (we actually counted them ) and we noticed no lag at all. The player with the poorest computer (about 4 years old PC) said that his FPS dropped somewhere between 23-26 but it was still very playable.

So, don't use performance issues as an argument anymore!

Keep in mind though, that on every map change, that variable is set back to 32.
Setting it in the ini to something other than 32 doesn't work either, cause as soon as the map loads, the variable is set back to 32.
The only way to make it stick is to use custom game length, but then you have perks disabled.

 

[Templarion]

Keep in mind though, that on every map change, that variable is set back to 32.
Setting it in the ini to something other than 32 doesn't work either, cause as soon as the map loads, the variable is set back to 32.
The only way to make it stick is to use custom game length, but then you have perks disabled.

I know. That's why I bind it in my keyboard and press the button before everyone has clicked ready.

If you are too lazy to bind the command line or write it every time again, you can always use the arrow keys in the console to find the command.

 

[Utarefson]

I am aware that my computer is not the greatest powerhouse there, but even one RO custom map with tons of trees and large enough that it takes 15min+ to do one lap around with a vehicle works beter on 50 player server than KF with 80+ active specimen

Please note that trees and human players don't use a.i. routines and that 50 is a smaller number than 80.
Thank you.

 

[Oldih]

Please note that trees and human players don't use a.i. routines and that 50 is a smaller number than 80.
Thank you.

True.

Could be as simple as UT2.5 engine does not like my computer specs at all which makes it easily to go lagomania with active specimen. I can't even turn everything as high as possible without game crashing without any errors while loading a map (both in RO and KF).

 

[kulik]

I would also raise the numbers of speciments in a wave. I have 75% of ammo after the wave ends, i can hold up two or three waves without visiting trader (tried this when one griefer blocked traders door).

 

[krid]

I tried solo mode with 1024 stalkers on screen at once. It was a slideshow.
I then tried solo mode with 512 stalkers on screen at once. It was almost playable.
At 256 it was perfectly fine with stalkers on or off screen.

Once I re-added the parts of their AI I excised, it stopped being fine.

The AI in this game is highly suboptimal; it's far more complicated than it needs to be to achieve the same effect, and it seems to be wasting time by duplicating its efforts.
To compare, the AI in KF isn't any more complex or advanced than the unit AI in Warcraft 3. However, where the AI in KF clogs itself up and brings the game to a halt with only one or two hundred AIs active, Warcraft 3 handles that as a trivial case. I've played on custom WC3 maps with one or two thousand active AIs, and the only slowdown the game suffered was from the resultant network lag.

Naturally, my suggestion for this is twofold:
First: Streamline the AI code. Look for cases where you can have the AI system use one result (In whole or in part) for multiple entities.
Second: Thread the AI and Physics systems for use on multi-core systems.

On a somewhat related note, you might want to consider having the engine clamp the particle population based on calculation time; cycle through the different particle emitters when performing the frame update, and when time is up expire all the particles you didn't have time to process. Since you're cycling through the emitters, the particle density drops with the framerate but no emitters starve completely.
That would take a huge bite out of firebug-related FPS hits.

 

[Templarion]

I would also raise the numbers of speciments in a wave. I have 75% of ammo after the wave ends, i can hold up two or three waves without visiting trader (tried this when one griefer blocked traders door).

I don't know what difficulty you prefer but that's something which makes me shiver. Yeah... The limit should absolutely be bigger.

 

[BanzaiKen]

As Utarefson said, keep in mind humans dont have AI routines.

Multiplayer games are essentially singleplayer games with Bots that receive input commands from humans. All they wait for is a human interface command.

With actual AI bots, they have check routines, everything from Find Cover, Break Door, Charge Enemy, IsDeadYes/No, etc. happening simultaneously. And you need to pull those routines out of memory and make sure their functions/loops do not leak back in. Now times that by 60, 70, 80. Not only do you have latency to worry about, but you would be requiring ALL dedicated servers to have higher minimum specs to run the default settings for the default 6 players. Anyway, the switch is available apprantly for server admins to change it.

 

[rallfo]

In this age of titanic computer specs WHY can't my zombie game support hundreds nay thousands of zombies on screen?

Tripwire need to seriously optimize their code and the performance footprint of a single zombie instance to fit memory/processing budgets for these sorts of numbers of simultaneous zombies to be possible basically, rather than relying on 5 year old ut2k4 Invasion script that was never designed for this sort of application and was probably written by an Epic Games intern as an amusing value-addon.

Compare this to Valve's approach in Left4Dead where they even removed the textures and rendering passes on the zombies EYES (leaving them entirely white) in order to further reduce the performance cost of an individual zombie and thus support more on-screen at once. And the Left4Dead zombie AI and animation manage to do far more than a KF specimen, in a fraction of the per-zombie performance cost.

Better hardware and tweaking will only get you so far, and asymptotically as the code's effective efficiency limit is approached. Algorithm and resource optimization is what is necessary to do this.

 

[kingkong]

In this age of titanic computer specs WHY can't my zombie game support hundreds nay thousands of zombies on screen?

Tripwire need to seriously optimize their code and the performance footprint of a single zombie instance to fit memory/processing budgets for these sorts of numbers of simultaneous zombies to be possible basically, rather than relying on 5 year old ut2k4 Invasion script that was never designed for this sort of application and was probably written by an Epic Games intern as an amusing value-addon.

Compare this to Valve's approach in Left4Dead where they even removed the textures and rendering passes on the zombies EYES (leaving them entirely white) in order to further reduce the performance cost of an individual zombie and thus support more on-screen at once. And the Left4Dead zombie AI and animation manage to do far more than a KF specimen, in a fraction of the per-zombie performance cost.

Better hardware and tweaking will only get you so far, and asymptotically as the code's effective efficiency limit is approached. Algorithm and resource optimization is what is necessary to do this.

I don't know why you would claim that something like l4d is somehow more 'optimized' than kf, whether it's true or not the comparison is pointless. if you had any idea how they were using the source engine, you would also know that they use 'just in time' positional spawning gimmicks to simulate the presence of a horde. the number of zombies on the map at any given time can actually be fewer than kf, it's an illusion that is crafted to simulate numbers while they run at you full bore, spawning relative to your location. the 5 specials they have spawn at far fewer intervals and amounts than the variety of 7 specimens that kf has all together at any given time on the map. l4d is basically one single type of zombie that only does 2 things, stand still and wait for you or sprint towards you in a straight line, with only a single instance of the other 5, if that. the pathing and logic for kf is actually more complicated, it can only be optimised so much before you run into unscalable hardware constraints.

do not confuse the difference between graphics rendering and logic computations, they use totally different resources that cannot be scaled down or 'optimised' as you say.

ie. you can remove the eye sockets of a zombie to improve rendering speed and not change the overall gameplay experience, but in order to do the same for the ai's logic 'algorithm and resource optimization' you would have to make them dumber, and with fewer instances, which does change the gameplay experience significantly. no matter how efficient their pathing and logic algorithms are, each instance will still add to the overall cost in cpu cycles.

and when you have multiple instances of all 7 types of zombies on the map at the same time trying to decide whether they want to shamble, grab, charge, chop, pounce, puke, flank, scream, or gore, each one of them has to get in line and wait for the cpu to tell them what to do. not the same as spawning a bunch of identical zombies here and there to stand still or run towards the nearest player.

 

[rallfo]

Evidently given your stance and unphased ignorance you have not worked on production software or studied it formally...

Far more past and future performance improvements in computation have come from algorithm optimization than Moore's law (improved hardware). In the real world any computation process can always be optimized further, and significantly so. Otherwise computer science would stagnate!

I don't see why you are so staunchly defending someone else's code when the KF developers themselves have said they are influenced, look to and play Left4Dead which has had far more man hours and resources go into developing it than Killing Floor. That is an objective fact reflected in the price difference.

There are a lot of lessons that could be learnt from Left4dead; for example in fact there is no difference between "really" having lots of zombies on screen and giving the players the effect of that by more cunning use of spawning which you called "'just in time' positional spawning gimmicks" and I call very clever optimization.

To clarify my point: if people want KF to support large numbers of zombies simultaneously it needs a lot of optimization and the Tripwire developers would agree if you asked them.

 

[Skunkee]

Start looking through some code and post your optimization suggestions on the Bug Report forum then, rallfo. That way you can use your extensive programming knowledge to help the TWI team find and fix bugs/make the game more interesting.

For instance, check this topic where Benjamin found the reason why the Medic Syringe has such a crappy hitbox: http://forums.tripwireinteractive.com/showthread.php?t=33626[url]http://forums.tripwireinteractive.com/showthread.php?t=33626[/URL]

I think that would do more for the game than having an internet argument on the Idea boards

 

[kingkong]

Evidently given your stance and unphased ignorance you have not worked on production software or studied it formally...

and since you happen to mention this for no apparent reason, evidently you have. which baffles me even more why you would make such nonsensical comparisons when you claim to have such a clear understanding of the logic behind what we are discussing.

Far more past and future performance improvements in computation have come from algorithm optimization than Moore's law (improved hardware). In the real world any computation process can always be optimized further, and significantly so. Otherwise computer science would stagnate!

thanks for the inspiring words buddy, and I totally agree but I don't recall any requirement for a minimum word count on this assignment.

I don't see why you are so staunchly defending someone else's code when the KF developers themselves have said they are influenced, look to and play Left4Dead which has had far more man hours and resources go into developing it than Killing Floor. That is an objective fact reflected in the price difference.

defensive stance is your own fabrication, if you were really making an objective contribution this would not be an issue at all.

There are a lot of lessons that could be learnt from Left4dead; for example in fact there is no difference between "really" having lots of zombies on screen and giving the players the effect of that by more cunning use of spawning which you called "'just in time' positional spawning gimmicks" and I call very clever optimization.

wrong, it's a completely different gameplay mechanic that changes the possibilities for runtime optimization. the persistent presence for a set number of entities on the map chasing players around is not the same as arbitrary locational spawning of similar objects that are typically culled immediately. again, if you had any intention of making an objective contribution to actual optimization you would have taken this into account.

To clarify my point: if people want KF to support large numbers of zombies simultaneously it needs a lot of optimization and the Tripwire developers would agree if you asked them.

if you actually had a point, you would not be making obvious claims to support some biased experience you had with some other game. developers always have lots to learn from each other, the important thing is that you apply the proper reasoning behind it with constructive criticism.

 

[Murphy]

In my personal opinion, which I don't plan to defend or force on anyone else, difficulty should be raised by making individual enemies more dangerous instead of just cluttering the screen with specimen.

Why do you want five scrakes if they combined aren't as dangerous as a single one from the mod days? And what's scarier? A dude with a chainsaw that can kill you if you aren't extremely careful, or five dudes with chainsaws who can't ever hit you as long as you keep backpadeling?
Why do you want two Bloats instead of making one spit twice as far? Why have ten clots to circle you if three faster, stronger, more grab happy ones with more brains would take you down a lot faster?

Killing Floor isn't a zombie game. There is no zombie infestation and not the whole population of a city block has been turned into zombies. There is no zombie apocalypse! There are a bunch of genetic prototypes running wild and an elite force has to take them out.

Killing Floor should also be a survival game, where genetic experiments are out to kill you (means they have to be dangerous. They are on the hunt!). It should not be a grindfest with a million zombies to slaughter to level your perks. Sadly that's exactly what it looks like it's becoming.

Now, proceed.

 

[rallfo]

I totally agree with you there Murphy. I really made a passing comment on a technical level that a prerequisite for the OP's request of hundreds of zombies on screen was improved individual zombie performance. Didn't say anything about it being a good idea!

However optimization would still benefit you too, increasing your tickrate/framerate ceiling playing with normal numbers of zombies.

Also I would like to point out that pure optimization does not change anything, say the functionality ("intelligence") of the zombie. By definition optimization it is doing precisely the same thing but more efficiently.

Skunkee I'm two steps ahead of you (search my posts) but it is somewhat disheartening that the Tripwire representatives seem to actually weigh in on very few of these discussions. Also something like generally optimizing the game performance is something that should be done by the original developers given:

(a) It is their game and their code in the first place, they are in the best position to do this.
(b) The overhead of vetting and incorporating each of the million and one cvs checkins from the community necessary to effect this by Tripwire would be greater than the human resources required to actually do the whole thing themselves!
(c) Killing Floor is not open source so licensing restrictions as well as the fact not all the source is publicly available would get in the way on a purely practical level.
(d) Killing Floor is not open source and Tripwire would be bundling up and selling a significant body of third parties' altruistic unpaid work which I'd morally object to...

Incidentally it is less "internet argument" more making the mistake of giving a genuine answer to a needlessly hostile troll sowing ambiguity and incorrect information. To answer my own earlier remark no wonder the Tripwire developers stay away from here!