LM3/4 - LVL Modifiers - Hotspots and Barricades

[UltimaOath]

Please use the next post for 'final form', as this was initial concept and has changed significantly in the second interation.

Initial concept in Discord:
https://discord.com/channels/752310043214479462/756850940694495253/1080675231309500436

# This system combines the kills of all players together for simplicity sake; while I like the
# idea of doing this per-player it would add an unncessary layer of complexity to manage the
# chunks on a per-player basis.
# All entities initially start at Level 1 (or the minLevel set for the scenario).

presets:
  hotspot_Levelling:
    # This Strategy Preset controls the player-variable based level modification system.
    name: 'LVLling Strategy - Hotspot'
    strategies:
      hotspot-levelling:
      # The Level Multiplier will multiply the final value by this amount, providing the scale
      # to how the levels are adjusted. A lower multiplier will stretch the scale out, meaning
      # it would take more entities to increase the level.
        level-multiplier: 1.25
      # The Level Modifier will add an amount to the final value prior to applying the multiplier.
      # This helps to provide a strength component to the scale. A higher modifier will
      # add value to the average level before it's applied to new entities.
        level-modifier: 2.0
      # This cooldown will apply to each entity killed, and the entities will be dropped from
      # the list once the cooldown has been reached based on that entities' killtime.
        cooldown-timer: 600s  # 10 minutes
      # These set of settings represent the 'Barricade' system; this measures the time that a player
      # chooses to remain in an affected chunk. If the player exceeds 'timer', then the 
      # 'penalty' modifier is applied to the formula. This will continue on loop every 'timer' time
      # until all players have left the affected chunks, in which case the cooldown begins and if
      # the area is left alone after 'cooldown' time the penality is dropped from affected chunks.
      # The modifier becomes capped at the 'cap', though entities can not receive a level higher than max.
      # The barricade penality is reduced by the 'cooldown-regen' every 'cooldown' time.
        barricade-penalty: 0.25
        barricade-cooldown-regen: '-0.5'
        barricade-cap: 5
        barricade-timer: 5m
        barricade-cooldown: 15m
      # These set of settings represent the 'Heatmap' system; this measures the number of times a player has
      # entered a chunk, and that measurement is totalled to generate a modifier to apply to levels. This system
      # is distinct from 'barricade', because this does not take into account the amount of time spent in a place.
      # This would generate a heatmap of sorts which is made up of lines of chunks which players have travelled
      # through currently or in the past; if a particular route is more travelled, then that route will generate
      # a higher modifier score in comparison to a lesser travelled route. These travel paths are forgotten
      # once the cooldown timer has elapsed and no player (new or otherwise) had been through this chunk.
      # If a player has already been in a chunk recently, and recount is true, then the modifier will be increased.
      # If the same player came throughh a chunk withh recount set to false, then the modifier will not increase,
      # unless the cooldown has passed. If the cooldown has passed without an update, then the penality is 
      # reduced by the 'cooldown-regen' every 'cooldown' time.
        heatmap-penalty: 0.25
        heatmap-cooldown-regen: '-0.5'
        heatmap-cap: 5
        heatmap-cooldown: 15m
        recount-players: true
      # This represents any nearby chunks that are affected by the new level average; if a chunk
      # is already set to a different level or has not been set yet, the highest level available
      # between the three will be used. If this is set to zero, then setting not used.
        apply-to-nearby-chunks: 5

The idea is that the world is level 1/minlevel, player(s) go to kill entities; their levels, the chunk they died in, and time of death are recorded in a list. A secondary list is made and sorted into the different affected chunks. Those chunks are given an 'average level value' which is generated by taking 'a sum of the levels of all entities which died in the same chunk' and 'a count of all entities which were used in the sum', then applying the modifier and multiplier settings will begin to increase the average over time based on the number of entities killed and the level of those entities being taken into account. 
This map of chunks with their level averages set is what sets the level of any subsequently spawned in entities within the affected chunks. These higher level entities will help to boost the average faster if players are determined to stay in the area, and if a player can handle it they are rewarded with the higher level entities. If they can't they can leave the area to an unaffected area of chunks or to an area with a lower average at the time until things calm down in the area they were working in. Using the 'nearby chunks' feature helps to spread the effect out away from the player as they travel around.

Once an entities' killtime has exceeded the cooldown timer, that entity is dropped from the list and therefore it is no longer affecting the averages. There are two effects to this: if the player has left or stopped fighting then the average will begin to reduce. If the player remains and is still fighting it out, then it is only adding fuel to the fire as the lower levels are removed from the averages and are replaced with higher levels. (edited)

I could also see this being a lvl-mod_ rather than an actual strategy; it would override whatever level was set in a strategy by changing the levels of future spawned entities only in the affected chunks, but leaving the unaffected chunks to the original strategy.

A sample/demonstration excel spreadsheet regarding this system is available here.

UPDATE: Added barricade mechanic, which changes the formula used in excel to:

CURRENT-LVL-AVERAGE = ((((( SUM-ENTITY-LEVELS ) / ( ENTITY-COUNT )) + LVL-MOD) x LVL-MULTI) + BARRICADE-PENALTY) + HEATMAP-PENALTY

Where the entities are only those killed in affected chunks being searched.

UPDATE 2: Added heatmap mechanic, which applies a modifier based on the paths that players commonly take rather than the duration they spend in a specific chunk.

[UltimaOath]

Got bored after waking up and decided randomly to sudocode this idea; I also had a few modifications to the general concept mostly associated with converting the entire thing into three separate level modifiers rather than true levelling strategies.

presets:
  lvl-mod_Hotspots:
    # This Level Modifier covers the 'Hotspots' mechanic.
    # HOTSPOTS_MOD = ( ( SUM-ENTITY-LEVELS ) / ( ENTITY-COUNT ) ) + HOTSPOTS-PENALTY ) x HOTSPOTS-MULTIPLIER )
    name: 'LVL Modifier - Hotspots'
    strategies:
      hotspots_Modifier:
      # The hotspots penalty will add the specified amount to the final hotspots mod value prior
      # to applying the hotspots multiplier. This adds additional strength to future levels being
      # applied. A higher value will cause greater leaps in strength over time.
        hotspots-penalty: 2.0
      # The hotspots multiplier will multiply the specified amount to the final hotspots value after
      # the previous hotspot penalty. This is used to stretch or shrink the scale of how many more
      # entities it would take to jump to the next difficulty tier. A lower value will stretch the scale
      # while a higher value would shrink the scale exponentially. 
        hotspots-multiplier: 1.25
      # This is the highest value (cap) the hotspot modifier can apply to a level.
        hotspots-cap: 10
      # This cooldown will apply to each entity killed, and the entities will be dropped from
      # the list once the cooldown has been reached based on that entities' killtime.
        hotspots-cooldown: 10m
      # This will apply any affects of this modifier to all surrounding chunks within this distance.
      # Each of these modifiers are unique, so would stack on to each other.
        apply-to-nearby-chunks: 5


  lvl-mod_Barricades:
    # This Level Modifier covers the 'Barricades' mechanic.
    # BARRICADES_MOD = ( BARRICADE-PENALTY x INSTANCE )
    name: 'LVL Modifier - Barricades'
    strategies:
      barricades_Modifier:
      # The barricades penalty will add the specified value for each elapsed timer instance, up to the cap.
        barricades-penalty: 0.25
      # This is the highest value (cap) the barricade modifier can apply to a level.
        barricades-cap: 10
      # This is the timer associated with how often this modifier is updated.
        barricades-timer: 45s
      # This cooldown will drop players from the list based on the timestamp of the players' exit.
        barricades-cooldown: 5m
      # This will apply any affects of this modifier to all surrounding chunks within this distance.
      # Each of these modifiers are unique, so would stack on to each other.
        apply-to-nearby-chunks: 5

---

Hotspots Modifier:
TLDR Meant to increase the difficulty of an area of above-average combat.

We start with a log associated with this modifier, which contains the primary list of chunk ids and the chunk's modifier value with each chunk id containing a nested secondary list of entity ids, entity levels, and timestamps of death.
When a player kills an entity, we need to take the chunk id associated with the entities' death coordinates and check if that chunk already exists within the log. If it does not exist, then we need to add to the log a new entry with this chunk id and all nested information for the latest killed entity within. If the chunk id already exists, then we need to add to the nested entries within that chunk the information for the latest killed entity.

Each entry will remain within the log for the hotspots-cooldown: duration in relation to the timestamp of death. Once the duration had elapsed, that entity is no longer considered for the modifier and can be dropped from the log entirely. If a chunk no longer contains any nested information at this point, the chunk can also be dropped from the log entirely.

We then use the following formula to generate a modifier score for each chunk based on the nested information within each chunk: HOTSPOTS_MOD = ( ( SUM-ENTITY-LEVELS ) / ( ENTITY-COUNT ) ) + HOTSPOTS-PENALTY ) x HOTSPOTS-MULTIPLIER ) .
Where SUM-ENTITY-LEVELS represents the combined sum total of the levels of all associated entities within the chunk; ENTITY-COUNT represents the total number of associated entities within the chunk; and HOTSPOTS-PENALTY / HOTSPOTS-MULTIPLIER represent their respective configuration value in the demo and are used to adjust the strength and scale of the modifier. Once the final HOTSPOTS_MOD value is calculated it is stored to the chunk.
When a new entity spawns into the world and is affected by the modifier, after all prior level processing (except Player Levelling), we take the current level of the entity as it would be and modify it by the HOTSPOTS_MOD value, not to exceed the hotspots-cap:.

---

Barricades Modifier:
TLDR Meant to increase the difficulty of an area where players travel or encamp.

We start with a log associated with this modifier, which contains the primary list of player ids with each player id containing a nested secondary list of chunk ids connected to the player, and one or more timestamps associated with when the barricades-timer: is pinged. We then need a second log associated with this modifier, which contains the primary list of chunk ids from the previous list. For all players, for each chunk id, we need to count the number of timestamps associated with that chunk id. If the chunk id is listed multiple times (IE two or more players have an entry associated with that chunk), we need to combine the total number of timestamps associated with the chunk and that total is used for the single chunk id entry. This provides a 'score' associated with each affected chunk.

When the barricades-timer: pings, we need to take the chunk id associated with the players' current coordinates and check whether the chunk already exists within the specified players' nested information. If it does not exist, then we need to add to the nested information for that specified player a new entry with this chunk id and the current timestamp at the time of the ping. If the chunk does exist, we need to include an additional timestamp entry with the current timestamp at the time of the ping.

Each nested entry will remain within the log for the barricades-cooldown: duration in relation to each timestamp entry. Once the duration had elapsed, that entry is no longer considered for the modifier and can be dropped from the log entirely. Players who are offline would no longer update the log and would eventually be dropped naturally, as would players who leave one world and venture to another or teleport, as their signature would be moved to an entirely different place.

We then use the following formula to generate a modifier score for each chunk based on the formation of the second log mentioned at the beginning: BARRICADES_MOD = ( BARRICADE-PENALTY x INSTANCE ) .
Where BARRICADE-PENALTY represent the respective configuration value in the demo and are used to adjust the strength and scale of the modifier; and INSTANCE represents the number of timestamps associated with the chunk id within the second log. Once the final BARRICADES_MOD value is calculated it is stored to the chunk id associated within the second log.
When a new entity spawns into the world and is affected by the modifier, after all prior level processing (except Player Levelling), we take the current level of the entity as it would be and modify it by the BARRICADES_MOD value, not to exceed the barricades-cap:.

[UltimaOath]

Updated my last post to make the processing less taxing, absorbing 'heatmaps' into the 'barricades' system, and gave a stronger explaination of the backend.

[UltimaOath]

Suggested to shift formatting into a new modifiers section as subsection of strategies as part of LM4

Example:

presets:
  lvl-mod_Hotspots:
    name: 'LVL Modifier - Hotspots'
    strategies:
      modifiers:
        hotspots-mod:
          hotspots-penalty: 2.0
          hotspots-multiplier: 1.25
          hotspots-cap: 10
          hotspots-cooldown: 10m
          apply-to-nearby-chunks: 5
          hotspots-placeholder: hotspots_mod  #would create placeholder `%hotspots_mod%` for use


  lvl-mod_Barricades:
    name: 'LVL Modifier - Barricades'
    strategies:
      modifiers:
        barricades-mod:
          barricades-penalty: 0.25
          barricades-cap: 10
          barricades-timer: 45s
          barricades-cooldown: 5m
          apply-to-nearby-chunks: 5
          barricades-placeholder: barricades_mod  #would create placeholder `%barricades_mod%` for use