[Proposal] Local Overpopulation Pressure (LOP) – A Soft Anti-Blob System for Open RvR

[Grublix]

[Proposal] Local Overpopulation Pressure (LOP) – A Soft Anti-Blob System for Open RvR
Overview

This proposal introduces Local Overpopulation Pressure (LOP), a soft, location-based system aimed at discouraging excessive warband stacking (“blobbing”) in open-field RvR, while preserving large-scale combat in keeps, forts, and cities.

LOP does not prevent players from grouping or massing.
Instead, it realigns incentives so that extreme local stacking becomes inefficient, while splitting forces and controlling the map becomes rewarding.

The Problem

In current open RvR:

• Warband-on-warband blobs are the safest and most efficient option
  
  Smaller groups and flanking play are often invalidated
  
  Zones frequently collapse into a single moving mass

Blobs are not a player failure — they are the result of strong incentives.
This proposal addresses incentives rather than restricting behavior.

Design Goals

• Discourage excessive stacking without hard caps
  
  Preserve epic mass battles where they belong (keeps/forts)
  
  Reward leadership, coordination, and map control
  
  Be technically feasible within RoR’s existing systems

Core Concept: Local Overpopulation Pressure (LOP)

When too many allied players cluster within a small radius in open-field RvR, they generate Overpopulation Pressure, which applies scaling penalties to combat efficiency and rewards.

This is a soft pressure system, not a prohibition.

Where LOP Applies

LOP is active only in:

Open RvR zones

Outside keeps, forts, cities, and warcamp areas

LOP does NOT apply in:

Keeps (inner and outer)

Forts

Cities

Warcamp radius

Keeps and forts remain the intended space for large-scale mass combat.

How Overpopulation Is Calculated

Server periodically checks allied player density (e.g. every 5 seconds)

Counts allied players within a fixed radius (example: ~120 ft)

Pressure tier is determined by nearby allied count

Example Thresholds
Allied Players Nearby Pressure Level
1–24 None
25–48 Mild
49–72 Moderate
73+ Severe

(Exact values are tunable)

Effects of Overpopulation Pressure

1. Combat Efficiency (Soft Penalties)

Mild Pressure

-5% outgoing damage

-5% outgoing healing

Moderate Pressure

-10% outgoing damage

-10% outgoing healing

+5% morale damage taken

Severe Pressure

-15% outgoing damage

-15% outgoing healing

+10% morale damage taken

-10% guard transfer effectiveness

These penalties stack gradually and are intentionally moderate.
Numbers still win — just less efficiently.

2. Reward Scaling

Renown and influence gains scale down while under pressure.

Example

Mild: 90% rewards

Moderate: 75% rewards

Severe: 60% rewards

This targets one of the main drivers of blobbing: safe renown farming.

Incentives to Split Forces (Positive Reinforcement)
Tactical Dispersion Bonus (TDB)

Warbands that:

Operate in separate clusters

Stay below pressure thresholds

Control multiple areas of the zone

Gain:

Increased renown gain

Faster BO capture

Improved zone control efficiency

Splitting is not just “less bad” — it is actively better.

BO Capture Scaling

Optimal capture speed at ~6–12 players

Diminishing returns beyond 24

Excessive numbers slow capture efficiency

Result:

One blob is inefficient at zone control

Multiple coordinated groups excel
-----------------------------------------------------------------------------------------------


Counter-Arguments & Responses

“This punishes casual players and pugs.”

Penalties apply only at very high local density and scale gradually. Casual players benefit from fewer steamrolls and more meaningful fights.

“Outnumbered realms need blobs.”

Numbers still win. LOP reduces extreme efficiency, not numerical advantage. AAO continues to handle realm population imbalance.

“This kills large-scale RvR.”

Keeps, forts, and cities are fully exempt. LOP targets only open-field stacking.

“Players will blob anyway.”

That’s acceptable. The goal is not elimination, but making blobbing less optimal than coordinated alternatives.

“This favors organized guilds.”

Organization already wins in RvR. LOP aligns rewards with good play instead of raw mass.

----------------------------------------------------------------------------------

Metrics to Monitor

• Local player density distributions
  
  Warband splitting frequency
  
  BO interaction rates
  
  Kill heatmaps across zones
  
  Renown per hour by group size
  
  AAO effectiveness
  
  Player participation and retention

Success is measured by healthier distribution, not blob extinction.


-----------------------------------------------------------------------------------------------------
Phased Rollout Plan

Phase 0 – Baseline Data Collection (2–4 weeks)
Gather density, renown, and BO data with no changes.

Phase 1 – Visibility Only (1–2 weeks)
LOP detection + UI indicators, no penalties.

Phase 2 – Light Pressure (2–3 weeks)
Mild pressure only, very small penalties.

Phase 3 – Full Activation (4+ weeks)
All pressure tiers enabled, reward scaling active.

Phase 4 – Refinement
Tune values, address edge cases, evaluate permanence.

All values are server-side and easily adjustable or reversible.
---------------------------------------------------------------------------------------------------------------

Final Summary

Local Overpopulation Pressure does not remove player freedom or large-scale combat.
It realigns incentives so that open RvR becomes more tactical, distributed, and engaging — while preserving the epic battles that define Warhammer RvR.

Feedback, tuning suggestions, and alternative approaches are welcome.



PS: This proposal is based on my own ideas and discussion points. I used ChatGPT to help organize, summarize, and format them into a clearer, forum-ready post.

[Serjekk]

I appreciate the time and effort put into this post. If implemented correctly, I believe this could actually work.

[Akalukz]

Sort of similar to LoTD but much more detailed. Good post, unfortunately something does need to happen to discourage blobbing.

[M0rw47h]

Yes, we need LOTD mechanic in oRvR <3

[leftayparxoun]

Not against the idea, if anything I've thought for a long time that a similar system in orvr could help with the same issue.

However, let me play the devil's advocate and attack the idea from the angle of feasibility/implementation:

First let me ask you what the biggest gripe players have with the LOTD game mode. If I ask 100 players, I'm willing to bet more than 90 will answer the lags/frame drops.

Why is that the case? Or alternatively, what sets appart LOTD from a regular 200v200 in Praag?
There is the PvE aspect of LOTD with multiple NPC squads scattered around the map but that factor contributing to lag got largely solved by R1CH some months ago. So what difference remains?
The answer is the LOTD debuff.

Full disclaimer: I do not know for sure how the LOTD debuff (Diminishing Rations) is calculated even after taking a look at the ability database.
What I do know is that it is also calculated every 5 seconds.

Considering how the LOTD debuff can be assumed to be the main factor behind the lag/frame drops this goes to show that, unless the devs find a more efficient way to accurately calculate N-dependent buffs/debuffs, implementing a similar system in oRvR will definitely contribute to lag increase.

Granted, LOTD-style systems are not a lag-switch; they simply burden the already server with a sizeable amount of calculations and are "the drop the makes the glas spill". We can infer that, because lag also exists in regular rvr and especially in crowded keep/fort sieges. On the other hand, after combat dies down in LOTD or after people start to leave LOTD the lag disappears very fast.

But why is the LOTD debuff so hard on the server. From my understanding the main reason is that it is computationally expensive due to checking how many allied players are in proximity of each player and calculates it every 5 seconds for each player present in LOTD. Unless there's some smart algorythm implementation that I'm not aware of, that should theorerically lead to O(n^2) computations due to the debuff.
I.e. if there are 400 players at LOTD then the server does an extra ~400×400 = 160.000 calculations (400×200 actually due to being faction check) every 5 seconds. In reality it might be bundled up efficiently in packets or it might even require 3 or 4 times the calculations, but it should be at that order of magnitude.

When comparing that to other game calculations, I imagine that e.g. 400 dps using their AOE Channels on the same GCD (which hit 24 people each) will be a ~400×24×2 calculation (the 2 is here due to the avoidance check) resulting in ~20.000 calculations. Again, this might be off by factor of 1/4, 1/2, 2, 4 etc. but the point is that even if it is equal to that, 400 channels hitting on the same GCD does not inspire the image of lag-free combat to me. If anything, it reminds me directly of that lag caused on Fort pushes with countdown.

Adding that sort of extra load on the server on populations that exceed 200vs200 can only lead to extreme lag and crashes (which thankfully ROR manages to avoid most of the time).


I am not familiar with the game's code language, the specific code or with how packets are handled in general, but I'm willing to bet that if the devs could manage to further reduce the computational complexity of such a system they would have already applied it to LOTD.

Grid-like solutions that provide the same debuff values to all people inside could perhaps optimize it and something like that was changed with BOs earlier this year, but I'm pretty sure you'd have to make a very fine mesh to provide reasonable debuffs on players which would not reduce the complexity after all.
That's as far as I go, but maybe R1CH or Dalen could comment further on the feasibility of further optimizations/alternative calculation methods for such a system.

[gersy]

Yes, we need LOTD mechanic in oRvR <3

definitely not. causes insane lag in lotd and doesn't make the fights more fair at all. it just reduces your damage numbers and makes game feel boring and slow.

[Grublix]

Not against the idea, if anything I've thought for a long time that a similar system in orvr could help with the same issue.

However, let me play the devil's advocate and attack the idea from the angle of feasibility/implementation:

First let me ask you what the biggest gripe players have with the LOTD game mode. If I ask 100 players, I'm willing to bet more than 90 will answer the lags/frame drops.

Why is that the case? Or alternatively, what sets appart LOTD from a regular 200v200 in Praag?
There is the PvE aspect of LOTD with multiple NPC squads scattered around the map but that factor contributing to lag got largely solved by R1CH some months ago. So what difference remains?
The answer is the LOTD debuff.

Full disclaimer: I do not know for sure how the LOTD debuff (Diminishing Rations) is calculated even after taking a look at the ability database.
What I do know is that it is also calculated every 5 seconds.

Considering how the LOTD debuff can be assumed to be the main factor behind the lag/frame drops this goes to show that, unless the devs find a more efficient way to accurately calculate N-dependent buffs/debuffs, implementing a similar system in oRvR will definitely contribute to lag increase.

Granted, LOTD-style systems are not a lag-switch; they simply burden the already server with a sizeable amount of calculations and are "the drop the makes the glas spill". We can infer that, because lag also exists in regular rvr and especially in crowded keep/fort sieges. On the other hand, after combat dies down in LOTD or after people start to leave LOTD the lag disappears very fast.

But why is the LOTD debuff so hard on the server. From my understanding the main reason is that it is computationally expensive due to checking how many allied players are in proximity of each player and calculates it every 5 seconds for each player present in LOTD. Unless there's some smart algorythm implementation that I'm not aware of, that should theorerically lead to O(n^2) computations due to the debuff.
I.e. if there are 400 players at LOTD then the server does an extra ~400×400 = 160.000 calculations (400×200 actually due to being faction check) every 5 seconds. In reality it might be bundled up efficiently in packets or it might even require 3 or 4 times the calculations, but it should be at that order of magnitude.

When comparing that to other game calculations, I imagine that e.g. 400 dps using their AOE Channels on the same GCD (which hit 24 people each) will be a ~400×24×2 calculation (the 2 is here due to the avoidance check) resulting in ~20.000 calculations. Again, this might be off by factor of 1/4, 1/2, 2, 4 etc. but the point is that even if it is equal to that, 400 channels hitting on the same GCD does not inspire the image of lag-free combat to me. If anything, it reminds me directly of that lag caused on Fort pushes with countdown.

Adding that sort of extra load on the server on populations that exceed 200vs200 can only lead to extreme lag and crashes (which thankfully ROR manages to avoid most of the time).


I am not familiar with the game's code language, the specific code or with how packets are handled in general, but I'm willing to bet that if the devs could manage to further reduce the computational complexity of such a system they would have already applied it to LOTD.

Grid-like solutions that provide the same debuff values to all people inside could perhaps optimize it and something like that was changed with BOs earlier this year, but I'm pretty sure you'd have to make a very fine mesh to provide reasonable debuffs on players which would not reduce the complexity after all.
That's as far as I go, but maybe R1CH or Dalen could comment further on the feasibility of further optimizations/alternative calculation methods for such a system.

Thank you very much for your insight Only !
You’re absolutely right that this ultimately hinges on engine/server realities, not design intent.
I’d genuinely welcome commentary from people with deeper technical knowledge, even if the answer is simply a clear data-backed No which would bring an endpoint for the idea.

[Gugly]

Thanks for taking the time to present your ideas. I am sure we all appreciate the effort. It’s well presented and thoughtful.

I think there’s a simple(ish) solution to the blob issues. Players need to be trained, just like anything else, to behave in a way that you want. They have proven incapable of choosing to spread out of their own volition. To this end…

Disincentivise and do not reward the blob-style gameplay.

Select an arbitrary number, such as 40% AAO, as an example. After that threshold is reached, the side with more numbers gets NOTHING kill board kills don’t count, no renown, no war crests… Nothing.

As soon as a ram is spawned in a map, if you have had no contribution or renown during the preceding 5 minutes, you get NOTHING. No more x-realming to get an easy lock/ free rewards. The rewards are also locked for active players at the time the Ram is spawned. Prevents flooding to stop the opposite side from getting rewards.

In short, using an already in-game system as a kill switch to make blobbing not rewarding.


AFK in the WC or near the entrance to falsely bump the player count. No worries, after 3 minutes of no contribution/renown, you get ported to the middle of the lakes or kicked back to your capital city with quitter debuff. Want or need to AFK longer? Do it away from the lakes.


At the risk of derailing the thread.

Guilds need content. Giving them a way to fight each other that isn’t about farming pugs will make them happy/let them flex. We have all seen how a guild forms up and, suddenly, as if by magic, the player population shifts to whichever side they are on in the hope of an easy farm.

Maybe let each guild claim a keep. Example from a single map 7- 9 server time and lock it for rewards from everyone not in the respective guilds or alliances. Others can still go there, but why would they? They are getting nothing.

As a final point, please pick a side... WTH is it with the x-realming mentality? To balance the fights?? Yeah? No! Whoever thinks that must be delusional! It’s human nature to take the path of least resistance and join the currently dominating side. It’s up to game mechanics to disincentivise that. Most people opt for easy fights, rather than good fights or fairness.

If you got this far thanks for reading.

[Grublix]

Thanks for taking the time to present your ideas. I am sure we all appreciate the effort. It’s well presented and thoughtful.

I think there’s a simple(ish) solution to the blob issues. Players need to be trained, just like anything else, to behave in a way that you want. They have proven incapable of choosing to spread out of their own volition. To this end…

Disincentivise and do not reward the blob-style gameplay.

Select an arbitrary number, such as 40% AAO, as an example. After that threshold is reached, the side with more numbers gets NOTHING kill board kills don’t count, no renown, no war crests… Nothing.

As soon as a ram is spawned in a map, if you have had no contribution or renown during the preceding 5 minutes, you get NOTHING. No more x-realming to get an easy lock/ free rewards. The rewards are also locked for active players at the time the Ram is spawned. Prevents flooding to stop the opposite side from getting rewards.

In short, using an already in-game system as a kill switch to make blobbing not rewarding.


AFK in the WC or near the entrance to falsely bump the player count. No worries, after 3 minutes of no contribution/renown, you get ported to the middle of the lakes or kicked back to your capital city with quitter debuff. Want or need to AFK longer? Do it away from the lakes.


At the risk of derailing the thread.

Guilds need content. Giving them a way to fight each other that isn’t about farming pugs will make them happy/let them flex. We have all seen how a guild forms up and, suddenly, as if by magic, the player population shifts to whichever side they are on in the hope of an easy farm.

Maybe let each guild claim a keep. Example from a single map 7- 9 server time and lock it for rewards from everyone not in the respective guilds or alliances. Others can still go there, but why would they? They are getting nothing.

As a final point, please pick a side... WTH is it with the x-realming mentality? To balance the fights?? Yeah? No! Whoever thinks that must be delusional! It’s human nature to take the path of least resistance and join the currently dominating side. It’s up to game mechanics to disincentivise that. Most people opt for easy fights, rather than good fights or fairness.

If you got this far thanks for reading.

Thanks for the reply — I appreciate you taking the time to share your thoughts and knowledge.

I’ve thought about hard cut-offs as well. My main concern with absolute “nothing at all” thresholds is that they create a hard stop moment where a player logs in, sees the situation is already past the line, and simply logs off. At that point, I believe such a change would affect the player base too heavily. Ideally, I’d hope any final implementation would be as non-invasive as possible to the current state of the game.

So for me, it’s less about being permissive and more about keeping players engaged and gently nudged in a better direction, rather than hard-gated out, while still making blob play the least attractive option over time.

[Avernus]

No, just no. Punishing the players for stacking their numbers in the game that is oriented for mass PvP is not the way to go.