A solution to the "Run away from hordes" problem.

[OzHawkeye]

Was not in this thread but I have advocated for that. If you want to avoid the BM then turn it off. Avoided. It really is that simple. For those that want to play with BM on, it should mean something. It needs to be an obstacle to overcome rather than avoided.

 

It's not possible to make the BM Horde (absolutely) unavoidable, either in SP or MP, but where I think TFP could usefully invest their time, is making the BM Horde more interesting to combat (perhaps some BM Horde only zombies, eg a BM Horde boss zombie), more rewarding for the player to combat (some chance at better loot, especially in A18 since more loot will not be craftable), less predictable (which they're doing with more random behaviour), and harder to avoid (one way would be to not despawn those zombies until they're killed, leaving the GPS on, so, sooner or later, the player would have to deal with them).

[Wyrda78]

The solution is pretty simple... simply make vehicles break down randomly like they do in real life, and make it so vehicles aren't indestructible so they may take damage or breakdown if they hit something hard or fall from a long distance.

[AtomicUs5000]

The solution is pretty simple... simply make vehicles break down randomly like they do in real life, and make it so vehicles aren't indestructible so they may take damage or breakdown if they hit something hard or fall from a long distance.

 

Vehicle breakdown is ok.... I just have a problem with the "randomly' part. Machines do not break randomly... they break because of lack of maintenance, or simply put, because things wear out. I suppose they could be composed of faulty parts. If these parts break, it's not random... they were faulty. Perhaps breakdown can be worked into the quality of the vehicle parts. Like you said though, hard hits definitely should cause big damage.

 

I can see this having a little impact, but not as much as people might initially think.

How long is a horde? 25% of a single game day, right? What are the chances of you forgetting to maintain your vehicle so that it actually does break down within 6 in game hours? I think slim.

 

So, impacts I think would be the better way to go. Zombies need to smash vehicles up on BM the best they can.

[Wyrda78]

Vehicle breakdown is ok.... I just have a problem with the "randomly' part. Machines do not break randomly... they break because of lack of maintenance, or simply put, because things wear out. I suppose they could be composed of faulty parts. If these parts break, it's not random... they were faulty. Perhaps breakdown can be worked into the quality of the vehicle parts. Like you said though, hard hits definitely should cause big damage.

 

I can see this having a little impact, but not as much as people might initially think.

How long is a horde? 25% of a single game day, right? What are the chances of you forgetting to maintain your vehicle so that it actually does break down within 6 in game hours? I think slim.

 

So, impacts I think would be the better way to go. Zombies need to smash vehicles up on BM the best they can.

 

Vehicles do break down "randomly", whether it's due to wear and tear or spontaneous failure of parts. If you were in a perfectly controlled environment and was able to keep tabs of all running parts you could predict with 100% accuracy parts breaking down. But that's not real life, and especially not in a zombie apocalypse when you are building the vehicle yourself and have to use second-hand parts. Breaking down would be relatively common.

 

So breaking down should depend of the quality of your vehicle, the amount of hp is has, and random crashes and knocks should decrease the HP as well as create a chance of a spontaneous breakdown. If you have a good quality vehicle and you drive safely then there should be little chance of breaking down. But it still introduces an element of risk and skill that is needed, and maybe make you think twice about getting in your dinky minibike as the best way to escape hordes rather than as a last resort.

[AtomicUs5000]

Vehicles do break down "randomly", whether it's due to wear and tear or spontaneous failure of parts. If you were in a perfectly controlled environment and was able to keep tabs of all running parts you could predict with 100% accuracy parts breaking down. But that's not real life, and especially not in a zombie apocalypse when you are building the vehicle yourself and have to use second-hand parts. Breaking down would be relatively common.

 

So breaking down should depend of the quality of your vehicle, the amount of hp is has, and random crashes and knocks should decrease the HP as well as create a chance of a spontaneous breakdown. If you have a good quality vehicle and you drive safely then there should be little chance of breaking down. But it still introduces an element of risk and skill that is needed, and maybe make you think twice about getting in your dinky minibike as the best way to escape hordes rather than as a last resort.

 

I'm just saying if I have a vehicle made out of good parts, it better not just randomly break. That's just frustrating gameplay. There is no fun to be had with that. I mentioned the amount of time a BM is. If it lasts 6 in-game hours, then in order for randomness of break downs to be effective, it would have to weighted so that the chance of randomly breaking down within a 6 in-game hours span is almost guaranteed. This means even on non-BM days, your vehicle is going to randomly break down 4 or more times a day. No way. Random is good for a lot of things, but it just wouldn't work here.

 

Look at Days Gone. Vehicle maintenance is top priority. You are pretty safe on the vehicle but if you drive poorly or if things hit your bike, it will break. It doesn't just happen randomly and it doesn't need to because their system works. Leaving the randomness out of it, and making vehicles more vulnerable to being damaged is something that fits in a survival game. The zombies need to actively attempt to disable your vehicle on horde night such that a few good hits makes it break down. In Days Gone, it's not just the terrain and zombies, it's also other NPCs shooting. There may even be other ways for it to break down... just not randomly.

 

You would then have to further justify these random breakings. Your axe, your pistol, your club, your bow, your shoes, your nerdy glasses, your forge would also be subject to randomly breaking.

[meganoth]

Madmole just put a price tag on avoiding BM in https://7daystodie.com/forums/showthread.php?111778-Alpha-18-Dev-Diary!!&p=991877&viewfull=1#post991877 . It is 5000 dukes (probably just a number he thought of at the moment, but the feature itself is important). 5000 dukes or maintain a fortress, a decision the player has to make on a BM. But where is there a decision between paying 5000 dukes and driving on the bike for almost 0 dukes ? Who would ever pay 5000 dukes then?

 

Driving around needs a risk, a cost, something, otherwise the feature "sleep at the trader" would be a useless joke.

 

 

I mentioned the amount of time a BM is. If it lasts 6 in-game hours, then in order for randomness of break downs to be effective, it would have to weighted so that the chance of randomly breaking down within a 6 in-game hours span is almost guaranteed.

 

Already the knowledge that the bike COULD break down would be a non-trivial factor in anyone's decision. Think of one BM as a single pulling of the trigger in a game of Russian Roulette.

[KucheKlizma]

Does anyone actually ride his bike to avoid hordes though? It makes more sense to disable hordes than to do that, as it's a good way to waste a lot of real life time doing essentially nothing? It makes more sense to make a looping base with a ramp or a floating base attached to the invulnerable trader terrain.

 

Furthermore the old trick that has been around forever - circle around a lake and keep the zombies inside the water - still does the same thing without even needing a vehicle.

 

In my current game I just attached a floating mini-base to a tree that spawned on the exact border of the trader. The downside is I have to spend time farming zombies every horde night, but at least I'm getting XP and not doing absolutely nothing.

 

The more cheese they try to remove, the more new cheese people will continue finding out, it's a never-ending process.

What's the point? Why not focus their effort on things that matter - such as content?!

I mean I'm not saying it's completely pointless as well as it doesn't create more problems than it solves, so doing it effectively isn't easy and probably not worth the time investment.

 

Should just make an option that BM nights instantly destroy all player built structures and /kill the player and spawn some zombies on top of his corpse to crouch spam.

You are sure you posted this comment in the right thread or even the right forum?

 

I'm sorry I'm not a elite pro gamer at 7dtd, I guess I'm just a noob without the right to express my opinion.

[Feycat]

Was not in this thread but I have advocated for that. If you want to avoid the BM then turn it off. Avoided. It really is that simple. For those that want to play with BM on, it should mean something. It needs to be an obstacle to overcome rather than avoided.

 

What if their idea of overcoming it is "finding a way to escape it" every week? That's still overcoming it.

[OzHawkeye]

What if their idea of overcoming it is "finding a way to escape it" every week? That's still overcoming it.

 

To play devil's advocate here, I think the issue some people have isn't so much that there is a way to escape it, but that its so trivially easy, and risk free, to do. While it doesn't much bother me one way or the other, I can understand how people would like the Horde be either hard to avoid, or expensive to avoid, or, indeed, both.

[RipClaw]

To play devil's advocate here, I think the issue some people have isn't so much that there is a way to escape it, but that its so trivially easy, and risk free, to do. While it doesn't much bother me one way or the other, I can understand how people would like the Horde be either hard to avoid, or expensive to avoid, or, indeed, both.

 

What bothers me about the discussion is that developer resources should be wasted to fix something that only a few see as a problem.

 

When it comes to fixing problems you have to decide which problems to fix first. Documented technical issues that affect the game as a whole should be at the top of the priority list. Subjectively perceived problems can be dealt with later when it comes to polishing.

 

Also it was mentioned often enough that the game is easy to modify. Those who feel disturbed that you can avoid the horde with little effort could try developing a mod that will give them the horde night they want.

[OzHawkeye]

What bothers me about the discussion is that developer resources should be wasted to fix something that only a few see as a problem.

 

When it comes to fixing problems you have to decide which problems to fix first. Documented technical issues that affect the game as a whole should be at the top of the priority list. Subjectively perceived problems can be dealt with later when it comes to polishing.

 

Also it was mentioned often enough that the game is easy to modify. Those who feel disturbed that you can avoid the horde with little effort could try developing a mod that will give them the horde night they want.

 

Well, I agree with the bug fix prioritisation at least, and indeed I'd hope most people arguing in this thread for a "better" Horde would also agree, that if TFP had to choose between spending time fixing a bug that wiped bases, or making the Horde less avoidable, they'd choose the former not that latter.

 

As with all things, this will be up to TFP to decide if, how, and even whether, they address this "issue". Hopefully, making the game even more moddable than it is now (again, hopefully, already a TFP goal), makes this a moot issue by, as you say, allowing modders to mod in a more or less unavoidable Horde, preserving the maximum player freedom, between those that want a Horde they can skip when they feel like it and those that want one that just can't be avoided at all (if, indeed, such a mechanic is even possible).

 

The discussion itself shouldn't bother you though, since it is, after all, what these forums are for, players on one side of an issue thrash the issue out with those on the other side, and hopefully out of that debate - conducted politely of course - comes a better game. If the Pimps are watching this thread, hopefully, someone, somewhere has said something that's made them think of some new content or mechanic for the game. ;-)

[Wyrda78]

I'm just saying if I have a vehicle made out of good parts, it better not just randomly break. That's just frustrating gameplay. There is no fun to be had with that. I mentioned the amount of time a BM is. If it lasts 6 in-game hours, then in order for randomness of break downs to be effective, it would have to weighted so that the chance of randomly breaking down within a 6 in-game hours span is almost guaranteed. This means even on non-BM days, your vehicle is going to randomly break down 4 or more times a day. No way. Random is good for a lot of things, but it just wouldn't work here.

 

Look at Days Gone. Vehicle maintenance is top priority. You are pretty safe on the vehicle but if you drive poorly or if things hit your bike, it will break. It doesn't just happen randomly and it doesn't need to because their system works. Leaving the randomness out of it, and making vehicles more vulnerable to being damaged is something that fits in a survival game. The zombies need to actively attempt to disable your vehicle on horde night such that a few good hits makes it break down. In Days Gone, it's not just the terrain and zombies, it's also other NPCs shooting. There may even be other ways for it to break down... just not randomly.

 

You would then have to further justify these random breakings. Your axe, your pistol, your club, your bow, your shoes, your nerdy glasses, your forge would also be subject to randomly breaking.

 

For the randomness to be effective, it doesn't have to happen every night. It only has to present a risk of happening, not a guarantee. Even if there is a 10% chance of it happening in a horde night, that will make you question whether it's a good idea, because even a small chance of being stranded on foot might make you prefer to stay in your relatively safe base.

 

It is realistic because vehicles break down all the time, especially low-quality, self built ones. In a vehicle there are hundreds of moving parts that are all potential points of failure. Breaking down should be random and/or as a result of taking damage or crashing in to things, because if it was only the latter, you could simply drive a safe route indefinitely with no danger.

 

The chance of it breaking down doesn't have to be very high, say only 10% on a horde night for a low quality vehicle. Of course this would increase exponentially if you started taking damage. And if you wanted to reduce the risk/annoyance, of course you would need to invest some more perks.

 

And no, your vehicle breaking down doesn't mean other things have to break down too, because no one said a game has to be 100% realistic and have perfectly consistent internal logic.

[ColdGate]

Solution:

 

Problem: Run away from hordes

Solution: Do not run away from hordes.

✔SOLVED

[meganoth]

I'm sorry I'm not a elite pro gamer at 7dtd, I guess I'm just a noob without the right to express my opinion.

 

Sorry, my post probably was too provocative, but I don't understand the point you were trying to make with that hyperbole example. You have every right to post it, but maybe you also want others to understand your message.

 

What bothers me about the discussion is that developer resources should be wasted to fix something that only a few see as a problem.

 

When it comes to fixing problems you have to decide which problems to fix first. Documented technical issues that affect the game as a whole should be at the top of the priority list. Subjectively perceived problems can be dealt with later when it comes to polishing.

 

Also it was mentioned often enough that the game is easy to modify. Those who feel disturbed that you can avoid the horde with little effort could try developing a mod that will give them the horde night they want.

 

So we should not talk about balance issues, but only about technical issues? Or issues that at least 50% forum users see as a problem (how do you want to measure that)? Look at the A18 thread. Lots of balance issues being discussed. Shouldn't you tell them to drop those discussions too?

[seagas]

This would definitely lead to you having to adapt the base design.

 

For example, I never actually have the generators in same spot in my base where I am during the horde because that is not necessary. I'd have to change the wiring so that the generators are within range when something like this happens.

 

Also you have to install passive traps that slow down the zombies as long as the active traps are not active.

 

I like the idea of random events happening. All of my horde fighting bases rely on passive as well as adding active defenses. All defenses will fail, well except for maybe a pit, so having redundancy is a good thing! Having to repair or having an alternative power source available, will add some additional tension to the game. Lately I have been making my horde base also my forge and cement mixer base, so screamers are attracted there instead of my main/crafting/farm base.

[RestInPieces]

What bothers me about the discussion is that developer resources should be wasted to fix something that only a few see as a problem.

 

Well deal with it because this is a discussion forum and almost all you do in this thread is pop up and make the same comments about how "only a few" disagree with you, about "developer resources" (while not having a clue about development and while the simpler solutions only include a few number tweaks) and how they will be "wasted" just because, again, you don't agree with it.

 

When it comes to fixing problems you have to decide which problems to fix first. Documented technical issues that affect the game as a whole should be at the top of the priority list. Subjectively perceived problems can be dealt with later when it comes to polishing.

 

Yes, Sherlock. Some things will be fixed first, while others will get fixed later. Also pretty much every balance/gameplay issue while being discussed is "subjectively perceived". I don't know where your concerns about bugs getting fixed last come from, but none in this thread said anything about prioritizing. Gameplay changes happen all the time in an alpha - they don't just "fix bugs". Unless the real problem is that you just don't like this particular change and use bugs etc as an excuse to strengthen your argument.

 

Also it was mentioned often enough that the game is easy to modify. Those who feel disturbed that you can avoid the horde with little effort could try developing a mod that will give them the horde night they want.

 

Even easier to click your mouse and use the already existing disable hordes option, or tweak their frequency to your liking. And if you still want a risk/cost-free horde avoidance "whenever you feel like it", use god mode, it's one and the same.

[KucheKlizma]

Sorry, my post probably was too provocative, but I don't understand the point you were trying to make with that hyperbole example. You have every right to post it, but maybe you also want others to understand your message.

 

What's there to clarify - I just see this as a joke. It's minor, the proposed solutions would cause much more problems or would require massive time investment from the devs. It might disappear into complete obscurity with new features (such as when A18 rolls out) The game is still in alpha and stuff changes regularly. And for what? A lot of people clearly don't even see this as a problem, there's a variety of other cheeses to evade hordes and there's certainly people that dislike hordes in their current state enough to just directly disable them.

So that should sum up my perspective.

 

I also said earlier I think a possible valid solution would be to experiment with massive horde sizes. But that's just because I think it would be fun. If players have to deal with 10000 zombies in a horde it would likely completely change how running away works. Would probably require further optimization and maybe even usage of sprites for the zombies, but I think it could be quite fun and more fitting to a zombie apocalypse game even if it's a secondary mode type of thing :c

[meganoth]

I also said earlier I think a possible valid solution would be to experiment with massive horde sizes. But that's just because I think it would be fun. If players have to deal with 10000 zombies in a horde it would likely completely change how running away works. Would probably require further optimization and maybe even usage of sprites for the zombies, but I think it could be quite fun and more fitting to a zombie apocalypse game even if it's a secondary mode type of thing :c

 

As a relatively new forum user you wouldn't know about that, but TFP have explained lots of times (see https://7daystodie.com/forums/showthread.php?111778-Alpha-18-Dev-Diary!!&p=992195&viewfull=1#post992195 for the latest) that putting hundreds of zombies into the game is not doable (for them in a reasonable time, with Unity, for minimum spec PCs, in this voxel game...). If you have a powerful PC you certainly can crank it up. But for vanilla base game TFP is stuck with making any zombie count because there is a limit far below of what you propose

[KucheKlizma]

As a relatively new forum user you wouldn't know about that, but TFP have explained lots of times (see https://7daystodie.com/forums/showthread.php?111778-Alpha-18-Dev-Diary!!&p=992195&viewfull=1#post992195 for the latest) that putting hundreds of zombies into the game is not doable (for them in a reasonable time, with Unity, for minimum spec PCs, in this voxel game...). If you have a powerful PC you certainly can crank it up. But for vanilla base game TFP is stuck with making any zombie count because there is a limit far below of what you propose

 

As a relatively old player of the game (have been playing it since the single digit alphas - don't even remember which one anymore) - dude do you even read before you respond? I know it's not doable in highpoly. It has nothing to do with Unity. It's entirely doable with sprites batching within Unity, just like how it has been doable within 2D era engines with 3D terrain and sprites.

https://docs.unity3d.com/Manual/DrawCallBatching.html

 

And here's an example of pathfinding of 100000 objects in Unity without even writing your own pathfinding algorithm:

 

If the developers don't want to that's fine, but it's certainly entirely possible to do within Unity.

[KucheKlizma]

Just to clarify as I feel like you won't get it immediately - it's not the same suggestion. The quote you pasted clearly is talking about zombies AS THEY ARE NOW in the game. Obviously 10 000 of those isn't going to work. I'm talking about BATCH SPRITES. If you don't know what sprites are - sprite is basically a 2D object that can change it's image based on the angle it's viewed from. And batch sprites are sprites that have the same image in the current frame, so they require a single draw call, making them essentially require the same computing power to draw, despite their number. It's not rocket science.

[RestInPieces]

As a relatively old player of the game (have been playing it since the single digit alphas - don't even remember which one anymore) - dude do you even read before you respond? I know it's not doable in highpoly. It has nothing to do with Unity. It's entirely doable with sprites batching within Unity, just like how it has been doable within 2D era engines with 3D terrain and sprites.

https://docs.unity3d.com/Manual/DrawCallBatching.html

 

And here's an example of pathfinding of 100000 objects in Unity without even writing your own pathfinding algorithm:

 

If the developers don't want to that's fine, but it's certainly entirely possible to do within Unity.

Just to clarify as I feel like you won't get it immediately - it's not the same suggestion. The quote you pasted clearly is talking about zombies AS THEY ARE NOW in the game. Obviously 10 000 of those isn't going to work. I'm talking about BATCH SPRITES. If you don't know what sprites are - sprite is basically a 2D object that can change it's image based on the angle it's viewed from. And batch sprites are sprites that have the same image in the current frame, so they require a single draw call, making them essentially require the same computing power to draw, despite their number. It's not rocket science.

 

-Yes there are always ways to optimize but engine matters

-7D is obviously not low poly

-They definitely won't use sprites for zombies and they shouldn't tbh

-Can't batch draw calls on high poly with models with multiple materials (like you said)

-The experiment in the video is isolated - nothing else burdens the cpu

-PC specs that can handle the zombies can't be on the high-end or TFP severely reduce their target audience

-Minimizing draw calls to lessen cpu burden doesn't solve everything - gpu still has to process mesh vertices

-Cpu still has to process physics like colliders, raycasts etc for each zombie, Unity's weakest point is probably the physics engine. I think the cpu should be the game's main bottleneck atm.

 

So these links don't mean much for this game at least, since they seem to not be able to add many more zombies at their target specs I guess. It is possible in the future though, if they optimize the game more or maybe rewrite some of their code for ECS.

[KucheKlizma]

-Yes there are always ways to optimize but engine matters

-7D is obviously not low poly

-Can't batch draw calls on high poly with models with multiple materials (like you said)

-The experiment in the video is isolated - nothing else burdens the cpu

-PC specs that can handle the zombies can't be on the high-end or TFP severely reduce their target audience

-Minimizing draw calls to lessen cpu burden doesn't solve everything - gpu still has to process mesh vertices

-Cpu still has to process physics like colliders, raycasts etc for each zombie, Unity's weakest point is probably the physics engine. I think the cpu should be the game's main bottleneck atm.

 

So these links don't mean much for this game at least, since they seem to not be able to add many more zombies at their target specs I guess. It is possible in the future though, if they optimize the game more or maybe rewrite some of their code for ECS.

 

Actually most games are lowpoly, the highpoly was just a joke. If 7dtd was using highpoly meshes during realtime rendering.... it wouldn't be realtime rendering xD

Afaik usually the artists make a high poly model which is then baked onto a lowpoly model using textures.

 

Furthermore something I didn't realize until now is that batching can apparently be used for meshes as well:

 

All in all, It would be interesting to know what the showstopper is, as this should be entirely possible (within Unity) and apparently even without resorting to sprites.

[RestInPieces]

Actually most games are lowpoly, the highpoly was just a joke. If 7dtd was using highpoly meshes during realtime rendering.... it wouldn't be realtime rendering xD

Afaik usually the artists make a high poly model which is then baked onto a lowpoly model using textures.

 

True, still, what they call low poly for real time rendering can be way higher (depending on the game) than a typical low poly game or that horse example. As far as I know as well, since I am no expert on the subject.

 

All in all, It would be interesting to know what the showstopper is, as this should be entirely possible (within Unity) and apparently even without resorting to sprites.

 

They had said that they will focus on optimizing at some point and since larger hordes has always been a very popular request, I am hoping that they will find a way and manage to do it.

[AtomicUs5000]

I don't see improving the BM as a waste of developer resources. I've worked on large projects with millions of lines of code for several years. What would be a waste is when you work on some major feature for years and never complete it. Whether it was time constraints, the budget, or beyond the capabilities of yourself or your team, even settling for something lesser than what you were aiming for over years of time with thousands or person-hours invested would be a waste. If one person working on it for another 500 hours brought that vision to life, it's a good 500 hours.

 

Sure the devs have more pressing issues to deal with, but this does not stop them from improving on the features that they have already invested in. They are playing around with shape selection. This is great! Love it! It wasn't broken though... it worked just fine and we used it that way for a long time... and yet this improvement is still worth it because it solidifies what they've created. It secures that investment.

 

I wouldn't worry too much about bugs. The only time you really focus on bugs is after you have your next version, unless if for some reason some bad code just broke everything. You can't chase bugs all the time when working on something of this scale or it will never get done. There hasn't been such a thing as bug-free software since the advent of operating systems. Getting this game feature-complete is far more of a priority.

[OzHawkeye]

I don't see improving the BM as a waste of developer resources.

 

Nor would I, I'd like to see an even more interesting BM horde as much as the next person, but also to see it prioritised within the larger framework of jobs outstanding between now and Gold. To me, it's current avoidability would be a relatively minor issue in that great big jobs list, but if it rates higher for the Pimps, then I'm all good with that to.

 

I still believe though, that the "best" solution to any sort of "Run away from hordes" problem, isn't so much about preventing the players escape, as about making the Horde so interesting that most people wouldn't want to skip it in the first place.