PC Mystic Gamestage-"Scaling" in Coop Session... (semi-solved)

White-Gandalf

White-Gandalf

New member
Hi folks, i do not know how to sort this in (if its a bug or a new feature or whatever), so i try to start a request for clarification here in the general area...

In my last coop session with friends, in a player-hosted game (not "dedicated"), after upgrading to version "1.2 (b27)", we experienced an ominous drastic upscaling of the horde difficulty by about a factor of 3, resulting in effect at about a real difficulty factor of at least 10, since both the enemy strength - both in attack as well as in defense value - as well as the enemy count were both boosted, and the overall enemy strength results from the multiplication of attack and defense values and the count of individual enemies.

It was an interesting gameplay experience for us three as well as for our stream audience (https://youtu.be/1f7BF2WecoQ?t=3875).

After some digging in the logs, i stumbled upon:
 

Code: 
2025-01-18T21:35:33 5681.804 INF BloodMoon starting for day 14
2025-01-18T21:35:33 5681.806 INF Party of 3, game stage 271 (!!), scaling 2.8, enemy max 1104, bonus every 36
2025-01-18T21:35:33 5681.806 INF Party members: 
2025-01-18T21:35:33 5681.806 INF Player id 171, gameStage 57
2025-01-18T21:35:33 5681.806 INF Player id 174, gameStage 56
2025-01-18T21:35:33 5681.807 INF Player id 173, gameStage 51
2025-01-18T21:35:33 5681.817 INF BloodMoonParty: SpawnZombie grp 0 feralHordeStageGS255 (count 1, numToSpawn 368, maxAlive 84), cnt 1, zombiePartyGirl, loot 0.02, at player 171, day/time 14 22:00
There, in the second line, sits this ominous term "scaling 2.8".
Calculating the group gamestage by hand, i figured out that it should have been 97 (rounded down). Multiplied by that ominous "2.8", it becomes those "271" we see right in front of that "2.8".

My question now is: Where does this "scaling 2.8" come from?

Is this a new type of game difficulty calculation that is intended to be there? So that by inviting friends, you make the hordes drastically harder? (I highly doubt that...)

Or is this somehow an error? We have started our game back in late summer 2024. Having a girlfriend with spina bifida, we very often have to pause our games, which we play on a single evening per week anyways, thus we landet at having out second horde multiple month after start and thus multiple upgrades (i think two) of the game later. Could it be that this factor was wrongly introduced by one of the latest two upgrades?

Or could it be that this factor has somehow been introduced by a test run as "dedicated server" just the week before that last game evening? I had to test something for a complete other thing (a "black forrest mod"), which was my first time running the game as dedicated server on my own PC. Could it be that some artifacts from that "dedicated" run got carried over to the "normal" player hosted run at our game evening?

A full text search over the entire game did not yield much clues: A difficulty setting named "scaling" is nowhere to be found. So where does it come from?

I would like to ensure that at our next game evening, we do not run into such a case again...

 
Last edited by a moderator:
White-Gandalf said:
My question now is: Where does this "scaling 2.8" come from?
Click to expand...
There was discussion of max alive getting capped at a lower number, spawning fewer but harder zeds if you go past a number. I'm thinking 30 was mentioned. Since your max alive is 84 and 30 * 2.8 = 84, it seems that could be the case - pretty straightforward maths if so.

But I can't say I know; I haven't seen an official patch note, much less tested it myself.

EDIT: Found a source link:




 
Last edited by a moderator:
That's an interesting observation! :D

At lest something i can test (and could correct in case its real) ...
P.S.:




 
Last edited by a moderator:
The problem with this "fix" is that...

1.) You have to adjust it for every different coop game you play.
2.) You have a mechanic that is hidden and without real documentation, thus forcing you to a trial-and-error-series until the setting fits your coop setup.
3.) You cannot TEST that setting until all the coop members agree to participate in a setup-debugging-session where you actually do that trial-and-error-series.
4.) For that trial-and-error-series, you are forced to provide an "artificial" setup with all members promoted to intermediate gamestages where the problems of the off-balance-throwing become relevant. Since you don't have any documentation to enable you to calculate something in advance, even this setup you have to do by pure experimentation in a trial-and-error-series.

You see, we are, at this point, already at a trial-and-error stack depth of two, and we have the necessary requirement of ALL coop members participating in those trial-and-error loops UNTIL EVENTUALLY the whole matter starts working as intended.

I consider the whole affair as a perfect example of incompetence of programmers. They deployed trainees for coding without having managers had instructed them.

You can, of course, set the game on the easiest possible setting, depriving it of the fun of challenges, thus chasing away potential coop partners. Completely agree with that attitude. You CAN tackle this that way. You may even find here and there the one and other player who agrees doing it that way. But then: There are thousands of better games out there that still provide challenges and fun... I for myself would never lower myself to playing games that get proactively designed (!) by their creators to destroy fun and challenges. :D

 
Last edited by a moderator:
Well, they are trying to make the game more challenging. So you "never feel safe" I believe Joel said. 

Plus it is a game still being developed, so changes between builds is kind of the status quo.

If it is too hard for you, then either use mods, or adjust the settings.

Don't blame the company for fault when you just cannot meet the challenge presented.

 
I would point out that they said this is subject to change, so they are clearly testing it to see if it works or not.  I have said that I think it should be an option rather than forced, and I think that is all that is necessary.  There isn't anything actually wrong with the change.  It just isn't a good change for anyone except those who have fps problems on horde night.

 
White-Gandalf said:
To finalize the topic of this thread (a documentation of the implemented mechanic), see:
Click to expand...
Hmm, where's that from? It doesn't seem to match your original data here (84 MA, 97GS vs 271GS => 2.8); did you happen to make a perfect mistake in calculating the 97, or has it changed between now and then?

 
3 players, maxalive 64: exp ( ln ( 64*3 / 30 ) / 1.8 ) = 2.80 (as in the initial post; i don't know where you have your "84" from, sorry)
3 players, maxalive 16: exp ( ln ( 16*3 / 30 ) / 1.8 ) = 1.3  (actually in game: 1.36 - thus i still declare that formula as "approximate")
3 players, maxalive 12: exp ( ln ( 12*3 / 30 ) / 1.8 ) = 1.11 (actually in game 1.12)

P.S.: I see, you misinterpreted the maxalive from the horde definition.
Well: That's just the horde definition. That has nothing to do with limitations and formulas that are applied after the reading of that definition.
The scaling gets applied BEFORE the horde definition gets read.
Thus:
1. calculate which horde definition to read, based on the formula i have given

2. read the matching horde definition

3. apply limitations to whatever gets read from the horde definition

 
Last edited by a moderator:
White-Gandalf said:
i don't know where you have your "84" from, sorry
Click to expand...
That's from your console log, last line; just scroll right a little 😃 If that's not an actual maxAlive for the horde, then, well, weird double coincidink as it fit perfectly to the linear math 😃 

So, "where from" is you own testing and figuring out a matching formula? Don't get me wrong, I appreciate the effort; but I like to know so I can quote stuff properly if need be ;)

 
Yes, got that: coincidences happen, especially if they are convincingly fitting. The three "data points" given are from my last two coop sessions. In the second one, we tested the setting before continuing with our game, in order to avoid being surprised again by a devastating horde. For the future, i now know that i have to set the maxalive to 10 for a group of three. And even in solo games (contrary to what was stated in the update notes), this handling comes into effect. Thus, to avoid getting overly difficult hordes, even in solo mode you have to limit yourself to 30 maxalive (respectively to 32 as the next best fit, since you cannot set it freely).

If i were among the funpimp programmers, i would recommend to just drop that nonsense overhead - since it does no good from any viewpoint, just complete throws the balance of course. If they want to warn the players about exceeding 30 maxalive, they could just...

a) put this into a note (doing nothing programmatically, just count on the intelligence of the players)
b) limit the maxalive choice to 30 for solo or to 30/number_of_players for coop
c) just limit the amount of zombies spawning as they had done it already the whole time!

The amount of zombies already got limited to something around 64 since Alpha 17 or so. While the horde definitions defined something in the hundreds maxalive, those never got spawned, but quietly limited to about 64 (maybe on servers to something configurable, i don't know). Thus, if they REALLY want to lower that spawn limit, they could simply change that internal - and never documented - limit down to 30 or whatever they think appropriate.

But instead, they implemented something completely new, complete confusing and completely destroying the game balance.

 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top