PC A suggestion to solve the BIG problem

[Psychodabble]

Disclaimer: I am not a programmer. I don not know whether this idea is feasible or how difficult it would be to implement.

I read this post by Morloc:

It would be nice to simply choose the AI that feels most fun, but these elements will conspire to define it:

1) Horde size is limited due to performance.

2) If you have a small horde size, then you needs zombies that are either smarter, stronger or specialized to provide a challenge.

2a) Most people* in the forums have rejected stronger (bullet sponges) zombies as well as the proposed specialized (behemoth) zombies. Feral and irradiated zombies still cause some to grumble.

3) Smarter zombies alienate the Romero crowd and others, but what they want cannot happen due to #1 above, so TFP aims toward smarter zombies.

4) Smarter Zs have more complex AIs to the point of being "too smart" to feel like zombies anymore. This of course doesn't take into account the current pathing exploits that are possible, and likely to be eliminated or greatly mitigated as TFP hones their algorithms.

I think we're in trouble long-term due to the limitations on zombie quantity.

*That's my subjective observation. I'm OK with or without either personally.

-Morloc

And I'm quite inclined to agree. We argue about AI and bullet sponge zombies, but these are all workarounds to compensate for the technical limitations on what we all really want: huge zombie hordes. Morloc is right. The big problem isn't going away no matter how we try to compensate for it, so why don't we solve it?

If I understand correctly, the problem with a really daunting horde is that it's just too many entities. Managing so many entities at once slows the engine to a crawl, making the game unplayable.

So here's my suggestion: dramatically reduce the number of entities involved in a horde. I don't mean small hordes, I mean HUGE, simulated hordes using new models that LOOK like mass numbers of zombies.

This is somewhat similar to the behemoth concept, but instead of an oversized, mutant freak, we'd have a single entity that LOOKS like a massive crowd of shamblers. Think WIDE instead of tall. The new model should be designed with many "head" hitboxes, but nothing else, making headshots the only way to damage it.

As it becomes more damaged it spawns individual zombies in similar numbers to what we see now in wandering hordes and dwindling in model size (is this possible? I would think it would function similarly to the system for zombies losing limbs). There could even be 2 or 3 of these new entity models representing hordes of roughly 100, 50, and 25 zombies each (or whatever numbers, I don't know, but I think it would be great to have a 1000 zed horde that only takes the performance of 10).

Eventually, the horde would be "killed" running out of HP and just leaving individual zombies behind.

Maybe this is all an impossible shower thought, but at the very least, I think it's the direction we should be thinking in because ultimately, Morloc is right. Unless we can figure out a way to address this limitation on zombie numbers, 7DTD will never live up to the promise of being the survival HORDE crafting game.

 

[Psychodabble]

A further suggestion:

As the "horde entity" would be unable to enter any space narrower than, say, 10 blocks wide, anytime it is unable to reach the player or is stopped by obstacles, it begins to spawn a slow, but steady stream of normal zombies. This way, if you opt for classical wall-based defense, you will have to make some tough decisions between whittling down the "horde" (which would also spawn more normal zeds) or taking out the zombies it spawns that will smash down your defenses.

To this end, I think it would make the most sense that the "horde" has no block damaging ability of it's own. I would also suggest that any attempt to engage the "horde" in melee result in near-certain death (enough player damage to kill all but the most hardened and armored survivor in one hit).

 

[Aerial]

Personally, I'd like an AI option that gives me low-rez non-HD zombies with basic meshes so that I CAN have hundreds alive at once. Especially now that they don't drop specialized loot, who cares if they all look the same (or like one of a handful of varieties)?

 

[Psychodabble]

Personally, I'd like an AI option that gives me low-rez non-HD zombies with basic meshes so that I CAN have hundreds alive at once. Especially now that they don't drop specialized loot, who cares if they all look the same (or like one of a handful of varieties)?

This is nice, but I'm not sure if it solves the problem. Perhaps someone with some technical insight could answer...is the issue about the number of entities or the resources to render them?

 

[Benjiro]

The issue is more complex then just having too many Zombies. Its a combination of items. More zombies means more hitboxes that need to be calculated. It also means more AI calculations.

If you see for instance some of those massive game like Total War, they fix this issue by having unit blocks, that share one AI, hitbox and simply drop "enemies" from this hitbox.

I think this is the concept that you are looking at. Groups of combined zombies that form one hitbox/ai/... and when you kill one, one drops from the group. The problem is, this type of design only really works with specific games. Flat, hitbox vs hitbox type of games.

For instance, what do you do when a group of 10 zombies ( 5 x 2 deep ), that try to get up a 1x1 block or a latter, to get to you? You need to float 4 * 2 of the zombies or break the group ( what will create a lag spike and the same issue as before ).

What happens when you shoot between that several zombies, where does the hitbox start and end. In the end, you almost end up with the same amount of hitboxes as before with individual zombies.

What happens when you melee a group and one need to fall down ( but not dead )...

I think you see the issue very fast. It works for games like Total War, because how the game is designed. But for 7D2D it can not work properly.

What you can do is create the illusion of a big zombie invasion by introducing low quality zombie assets, that roam the distance ( and are replaced by high quality / full AI when a player is close ). But its hard to get that right and it does not increase the amount of attacking zombies.

One issue that plagues 7D2D is how assets are calculated with their environment interaction, the multithreading issues etc. Being honest, if the Pimp wanted to solve or mitigate these issue, they are almost required to rewrite 7D2D from the ground up with all the experience they have build up. And/Or write it in a different game engine. Unity is a nice engine but its not a engine where you can really draw out the best performance, especially for a game with this design.

The whole 1x1 block system allows for a lot of creativity but also sucks up a lot of performance. This is why a lot of games use pieces ( Rust, Subnautica, etc ), so where 7D2D may need 3 times more blocks, its also 3 times more SI calculations, more calculations for hit boxes, more zombie pathing calculations etc. A lot is issued into the design of the game, where a lot of different elements all exacerbate the issues.

And it goes beyond the technical, its the game balance and concept. If we look at Subnautica, how do we even start the game? You start in a easy area, with basic resources and not too many enemies. It gives you time to slowly explore out. 7D2D the moment the timer runs out, trows you into a grinder, a grinder that is hard for a lot of new players.

Even if they explorer other areas, those areas are still the same. A bit harder enemies in wasteland, a bit warm or cold in winter/desert biome but it all feels the same.

Now trow in the whole loot issues, where a lot of loot does not feel like a great thing after a few days ingame. The loot balance - progression.

With for example Subnautica you need specific things to explorer more distance away ( oxygen, dive suit, radiation suit, sub, bigger sub, power, more power ) but at the same time you also get more better rewards ( other technologies, rare or important resources, etc away from the starting position ). 7D2D simply does not have any of this ( this is how we ended up with the whole XP gateing to create artificial barriers and not natural barriers, and how loot can unbalance the game experience ).

So even if they add more Zombies on screen, it does not solve the progression issues. The more i analyse the progression of 7D2D as a game, the more clear it becomes that the game has several major design issues. A17 simply made them more obvious.

This is why the Pimp can not balance the game correctly to have good or expandable mid to late game content ( and why they do not bother adding new content for anything beyond mid to late, i think they know this also ). We think of steel as late content but its not. Stone, ( Iron / Steel ), ( Mechanical / Steel / Mechanical ), Powered ( battery / electronic components /... ) Tools, ... The game is stuck in the whole Stone/Iron/Steel loop with a few pieces of mechanical, instead of complete tiers.

The issue go beyond this. So sorry if this sounds a bit like a topic hijack Psychodabble but more onscreen zombie is not going the solve the other issues. And that technically will already be hard. The reality in my opinion is, that 7D2D is flawed and this is why the Pimps are constantly struggling to find a balance or fix or balance or fix or progression or fix or ... I think they even realize this themselves.

 

[OzHawkeye]

What does surprise me a little about how zombie numbers have gone is that in Alpha 10 (which I still play from time to time), it was possible to jack up the zombie numbers massively in cities (500%-1000% increase in the base zombie spawn rate). We used this as a sort of difficulty slider - making cities something you could approach only when pretty well kitted out.

The result is mass zombies, and done on a 3 player server without any significant lag (indeed, it took all three of us to get in there and clear a city block).

Now, to be sure, this is pre UMA zombies, and pre smart zombies, so I've no doubt there was much less stress in generating these hordes than would be involved in doing so now, and the number of zombie textures were much smaller too, but I'd happily go back to that in order to boost the numbers, and reserve high texture, smart entities for bandits, which I wouldn't expect to turn a corner and see several dozen of.

 

[Psychodabble]

What does surprise me a little about how zombie numbers have gone is that in Alpha 10 (which I still play from time to time), it was possible to jack up the zombie numbers massively in cities (500%-1000% increase in the base zombie spawn rate). We used this as a sort of difficulty slider - making cities something you could approach only when pretty well kitted out.
The result is mass zombies, and done on a 3 player server without any significant lag (indeed, it took all three of us to get in there and clear a city block).

Now, to be sure, this is pre UMA zombies, and pre smart zombies, so I've no doubt there was much less stress in generating these hordes than would be involved in doing so now, and the number of zombie textures were much smaller too, but I'd happily go back to that in order to boost the numbers, and reserve high texture, smart entities for bandits, which I wouldn't expect to turn a corner and see several dozen of.

If the solution were this simple, I'd be all for it, but the Pimps seem unwilling to do it. Maybe a poll to see how the community at large feels about it?

 

[Psychodabble]

The issue is more complex then just having too many Zombies. Its a combination of items. More zombies means more hitboxes that need to be calculated. It also means more AI calculations.
If you see for instance some of those massive game like Total War, they fix this issue by having unit blocks, that share one AI, hitbox and simply drop "enemies" from this hitbox.

I think this is the concept that you are looking at. Groups of combined zombies that form one hitbox/ai/... and when you kill one, one drops from the group. The problem is, this type of design only really works with specific games. Flat, hitbox vs hitbox type of games.

For instance, what do you do when a group of 10 zombies ( 5 x 2 deep ), that try to get up a 1x1 block or a latter, to get to you? You need to float 4 * 2 of the zombies or break the group ( what will create a lag spike and the same issue as before ).

What happens when you shoot between that several zombies, where does the hitbox start and end. In the end, you almost end up with the same amount of hitboxes as before with individual zombies.

What happens when you melee a group and one need to fall down ( but not dead )...

I think you see the issue very fast. It works for games like Total War, because how the game is designed. But for 7D2D it can not work properly.

What you can do is create the illusion of a big zombie invasion by introducing low quality zombie assets, that roam the distance ( and are replaced by high quality / full AI when a player is close ). But its hard to get that right and it does not increase the amount of attacking zombies.

One issue that plagues 7D2D is how assets are calculated with their environment interaction, the multithreading issues etc. Being honest, if the Pimp wanted to solve or mitigate these issue, they are almost required to rewrite 7D2D from the ground up with all the experience they have build up. And/Or write it in a different game engine. Unity is a nice engine but its not a engine where you can really draw out the best performance, especially for a game with this design.

The whole 1x1 block system allows for a lot of creativity but also sucks up a lot of performance. This is why a lot of games use pieces ( Rust, Subnautica, etc ), so where 7D2D may need 3 times more blocks, its also 3 times more SI calculations, more calculations for hit boxes, more zombie pathing calculations etc. A lot is issued into the design of the game, where a lot of different elements all exacerbate the issues.

And it goes beyond the technical, its the game balance and concept. If we look at Subnautica, how do we even start the game? You start in a easy area, with basic resources and not too many enemies. It gives you time to slowly explore out. 7D2D the moment the timer runs out, trows you into a grinder, a grinder that is hard for a lot of new players.

Even if they explorer other areas, those areas are still the same. A bit harder enemies in wasteland, a bit warm or cold in winter/desert biome but it all feels the same.

Now trow in the whole loot issues, where a lot of loot does not feel like a great thing after a few days ingame. The loot balance - progression.

With for example Subnautica you need specific things to explorer more distance away ( oxygen, dive suit, radiation suit, sub, bigger sub, power, more power ) but at the same time you also get more better rewards ( other technologies, rare or important resources, etc away from the starting position ). 7D2D simply does not have any of this ( this is how we ended up with the whole XP gateing to create artificial barriers and not natural barriers, and how loot can unbalance the game experience ).

So even if they add more Zombies on screen, it does not solve the progression issues. The more i analyse the progression of 7D2D as a game, the more clear it becomes that the game has several major design issues. A17 simply made them more obvious.

This is why the Pimp can not balance the game correctly to have good or expandable mid to late game content ( and why they do not bother adding new content for anything beyond mid to late, i think they know this also ). We think of steel as late content but its not. Stone, ( Iron / Steel ), ( Mechanical / Steel / Mechanical ), Powered ( battery / electronic components /... ) Tools, ... The game is stuck in the whole Stone/Iron/Steel loop with a few pieces of mechanical, instead of complete tiers.

The issue go beyond this. So sorry if this sounds a bit like a topic hijack Psychodabble but more onscreen zombie is not going the solve the other issues. And that technically will already be hard. The reality in my opinion is, that 7D2D is flawed and this is why the Pimps are constantly struggling to find a balance or fix or balance or fix or progression or fix or ... I think they even realize this themselves.

I agree with you about the progresion and balance issues, but I think you realize that those are a topic for another thread. We can't solve everything at once.

As far as the issues you brought up regarding the horde entity, those are precisely what I was trying to address in my second post.

1) Instead of trying to split the group when it encounters a ladder, the horde entity just stops and begins spawning individual zombies that can climb the ladder.

2) Melee attacks and animations would be very problematic in the context of such an entity, so we disincentivize them as much as possible. There would be no possibility to knock down individual zombies in the horde entity, because they don't exist...each headshot only lowers the entity's total HP and triggers it to spawn more individual zombies. In this way, people inclined to take the increased risk of attacking the horde entity with melee weapons can still do so and make progress toward defeating the horde, but will face the constant threat of instant death and be motivated to engage the horde at range.

I'm not naive enough to think that this suggestion is a complete solution for the horde size issue, but I do believe it would provide some of what players want in that regard at a lower performance cost than the current solution of increasing zombie numbers by mod.

 

[stasis78]

I don’t think number of zombies and progression issues have anything to do with each other. At all.

If there are impossible to balance issues with the game, that has zero to do with the number of zombies, their AI, their quantity etc. Hijacking a thread about more zombies to talk about acedemic game theory on a completely different topic is pretty ♥♥♥♥ty behavior. The OP asked about zeds. Not YOUR opinion on how game mechanics should work with progression.

They are not related issues. Again, at all.

Furthermore making a statement that 7dtd is fundamentally flawed and therefore can never be balanced is beyond ignorant.

 

[ghettochild2600]

Zombies shouldn't be smart period. I'd rather have a larger horde of zombies than one's that know how to jump and climb ladders. I remove that functionality from the xml file. Of course this can't happen without much needed performance optimizations.

They are supposed to overwhelm you with their massive numbers. If they're going to be smart we might as well not even call them zombies anymore.

However, I do believe that choice should be up to the player to decide and having a way in-game via a configuration menu is a good way to go.

 

[Laz Man]

Alpha 6 or 7:

594 zombies. Brings back some good memories.

 

[OzHawkeye]

Alpha 6 or 7:
594 zombies. Brings back some good memories.

Reminds me of my Alpha 10 cities - though probably not quite that many, but not far off it either.

- - - Updated - - -

I don’t think number of zombies and progression issues have anything to do with each other. At all.
If there are impossible to balance issues with the game, that has zero to do with the number of zombies, their AI, their quantity etc. Hijacking a thread about more zombies to talk about acedemic game theory on a completely different topic is pretty ♥♥♥♥ty behavior. The OP asked about zeds. Not YOUR opinion on how game mechanics should work with progression.

They are not related issues. Again, at all.

Furthermore making a statement that 7dtd is fundamentally flawed and therefore can never be balanced is beyond ignorant.

The OP specifically mentions horde size in his opening statement, so thoughts on that aspect of gameplay are quite valid.

 

[Laz Man]

Reminds me of my Alpha 10 cities - though probably not quite that many, but not far off it either.
- - - Updated - - -

The OP specifically mentions horde size in his opening statement, so thoughts on that aspect of gameplay are quite valid.

594 was about as much as I could push my potatoe. The FPS was horrendous lol...

 

[JDStrawesome]

Personally, I'd like an AI option that gives me low-rez non-HD zombies with basic meshes so that I CAN have hundreds alive at once. Especially now that they don't drop specialized loot, who cares if they all look the same (or like one of a handful of varieties)?

(Disclaimer: am a game developer)

Unfortunately, the bottleneck for having massive hordes is not really rendering, but processing AI and physics in a server/client setting. So, strategies along the lines of psychodabble's is what would give us our giant hordes.

Combined meta-rigs, clever strategies to attach and detach zombies into dumb swarms, efficient and good-enough swarming, clever replication relevancy (determining how the server knows what is worth syncing to each client)... stuff like that will get you giant hordes.

Unity has a lot of visual optimizations already in play so long as you know how to appropriately use them that will mitigate rendering overhead.

 

[Psychodabble]

(Disclaimer: am a game developer)
Unfortunately, the bottleneck for having massive hordes is not really rendering, but processing AI and physics in a server/client setting. So, strategies along the lines of psychodabble's is what would give us our giant hordes.

Combined meta-rigs, clever strategies to attach and detach zombies into dumb swarms, efficient and good-enough swarming, clever replication relevancy (determining how the server knows what is worth syncing to each client)... stuff like that will get you giant hordes.

Unity has a lot of visual optimizations already in play so long as you know how to appropriately use them that will mitigate rendering overhead.

Excellent, thanks for contributing. This is the kind of technical input I needed.

So you think this idea would work? I think it solves a lot of AI and physics issues by just cheating them. The horde entity would not need any complex pathfinding AI...it just moves toward the player as best it can and stops when it can't proceed. The horde entity would also not go over cliffs or drop from awkward heights, instead displaying the same "stop and spawn" behavior.

Perhaps if stopped long enough, a "horde entity 100" would spawn a smaller "horde entity 50 or 25" on the other side of the obstacle. Maybe it would be possible that if a certain threshold of individual zombies in a given area is surpassed, they despawn and are replaced with a horde entity of appropriate size?

To clarify for everyone, I'm not just looking for support for my idea here, I'm trying to get some brainstorming/crowdsourcing going in terms of what can be done to overcome these technical limitations and deliver the game that we all really want to play.

TFP feedback regarding the official stance toward this kind of workaround would be greatly appreciated.

 

[Psychodabble]

Alpha 6 or 7:
594 zombies. Brings back some good memories.

I think this provides a really good visual to go along with the idea. When zombies are densely packed it's hard to make them out as individuals anyway, so this would just be the next step to improve performance and enable even greater horde sizes.

So when we look at this image, imagine that the pillars are the demarcation line and each group between them is actually only one "horde entity". Thusly we could achieve a crowd of this size using maybe only 20 entities total: 9 "horde entities" and another 10-15 individual zombie entities milling among the hordes.

The horde entities basically become mobile, visible spawners that can kill you and be killed, while the individual zombies present the more aggressive, agile, destructive threat.

 

[meganoth]

A further suggestion:
As the "horde entity" would be unable to enter any space narrower than, say, 10 blocks wide, anytime it is unable to reach the player or is stopped by obstacles, it begins to spawn a slow, but steady stream of normal zombies. This way, if you opt for classical wall-based defense, you will have to make some tough decisions between whittling down the "horde" (which would also spawn more normal zeds) or taking out the zombies it spawns that will smash down your defenses.

To this end, I think it would make the most sense that the "horde" has no block damaging ability of it's own. I would also suggest that any attempt to engage the "horde" in melee result in near-certain death (enough player damage to kill all but the most hardened and armored survivor in one hit).

Just a few possible problems:

1) AFAIK spawning an entity takes quite a toll on the engine. Imagine a wall with lots of 1 block wide openings/doors. The massive horde would have to constantly split off single zombies to go through the wall. Would tank FPS hard. Furthermore they would have to recombine inside again so that number of entities doesn't go through the roof. Sure, the individual player can decide to not use such a design, but TFP can't afford to publish a game that just breaks when you build something like this

2)The behemoth was scraped because there were lots of problem with movement of an entity with a footprint larger than one block. Those problems won't go away. You can't have half the horde clip into buildings because only one block of that entity exists and the rest is a fata morgana.

3) Consider the horde walking over very irregular terrain, i.e. over a pointy hill or inside a ruin with very uneven ground and obstacles. Eventually the horde has to make lots of path calculations again and partly needs calulations analoguous to individual zombies again.

I'm not saying that these problems can't be solved. But the current AI needed 1 year to implement. This seemingly huge change would probably need another year to get right. The time to do that has passed as TFP wants to go to smaller dev cycles and polishing and finish the game in about a year more or less.

Not all is lost though. Fataal said something about looking into the possibility of spawning light-weight zombies without a unity character controller. Or just reducing overhead of entities:

Many zombies is currently a performance issue. It is not the smarts that makes them slow. The character controller has a lot of overhead and then add the colliders, bones and animation and even a zombie with no AI walking in a straight line is expensive. We need to find ways to reduce that overhead to get more.

 

[JDStrawesome]

Excellent, thanks for contributing. This is the kind of technical input I needed.
So you think this idea would work? ...

I don't know how TFPs are currently doing it, and what challenges internally they face. It's easy to brainstorm solutions to these problems with the benefit of hindsight and a clean slate of don't-hafta-make-it.

I just wanted to give some experienced insight into precisely where bottlenecks and solutions might lay to the best of my knowledge.

I would bet TFPs are exploring similar system ideas and have even better ideas tailored to their current system, but are just hitting feature-creep limits and/or unity feature-walls.

Sometimes you think up a better way to do things, but because you've spent x years to get to this point, you would rather shelve it for the next game rather than tearing down what you currently have.

Edit:

Many zombies is currently a performance issue. It is not the smarts that makes them slow. The character controller has a lot of overhead and then add the colliders, bones and animation and even a zombie with no AI walking in a straight line is expensive. We need to find ways to reduce that overhead to get more.

^^So this is new info to me. There is both a performance hit on the server (I mean, we see it. Big POIs and lots of zombies chug the server) AND a unity rendering performance issue.

Though I stand by my claim. Unity has a lot of features to mitigate rendering and controller overhead. Admittedly, they are a bit obtuse in the documentation of best practices.

 

[hotpoon]

Perhaps at some point The Fun Pimps could purchase the crowd rendering system that is being used for the upcoming Black Mass game...

 

[Aerial]

Alpha 6 or 7:
594 zombies. Brings back some good memories.

This is exactly what I was getting at. We used to have huge hordes of lightweight (processing-wise) zombies. If the game supported them before, it's hard to argue that it couldn't now if they reverted back to these zombies (and maybe gave up some additional load from other things, I realize).

I would really like to understand what the game would have to give up (SI?, high-rez textures (all/some?), etc) in order to get these zombies back. I think I would probably be happy to make that trade.