Config.json Zombies Section Reference

Intermediate30-40 minutesCross-platformUnturned ServerText Editor

The Zombies section of a dedicated server's Config.json governs every mechanical lever a server owner has for tuning zombie difficulty. It controls whether zombies appear at all and in what numbers, which special variants can spawn and at what rates, how fast they return after being killed, how much damage they deal and how much they absorb, whether they drop loot and how much, which environmental objects they attack when pathfinding, and the behaviour of horde beacons and full-moon events. Forty-two keys make up the section, all of them optional. When a key is absent from the config file, the server applies its own hardcoded default silently. This means an empty or omitted Zombies section is not a broken config. It is a config where every design decision has been deferred to the game's general-purpose baseline.

The baseline was chosen to produce a consistent experience across every official map. It was not chosen for a specific server community, a specific player skill level, or a specific difficulty vision. Every key in this section is a point of deliberate control that lets a server operator replace the baseline with something that fits the community they are running the server for. A map played on one server with the default Zombies section will feel entirely different on another server where the owner has tuned these keys to produce a harder or easier experience.

This article documents every key individually, but its real subject is the interactions between keys. Zombie difficulty is not one slider. It emerges from the relationship between how many zombies spawn, how often they return, how much damage they deal, how much damage they absorb, which special variants are in play, whether players can stun them, and whether the reward structure makes fighting them worthwhile. Change one key and the effect is linear. Change three keys in combination and the effect is a curve. The article explains what each curve looks like and why it matters.

Each key description is based on the game's internal documentation of what the key does, restated in plain language for a server operator who has never edited this file before. No numbers are invented or estimated beyond what the game's own field descriptions provide. Every probability, multiplier, and timer described here maps directly to a documented key and a documented default behaviour.

The Complete Key Table

The following table lists every key in the Zombies section exactly as the server expects to find it in the JSON. Key names are case-sensitive: the server expects Spawn_Chance, not spawn_chance or SPAWNCHANCE. The Type column shows the expected JSON type. float means a decimal number; for chance values the expected range is 0 to 1, while for multipliers it is unbounded. uint means an unsigned integer -- a whole number that cannot be negative. bool means true or false, lowercased and unquoted in JSON. The Default column shows the hardcoded value the server falls back to when the key is not present. A dash means the default is not documented in the game's internal field descriptions, which means the server applies its own implicit default that the field documentation does not surface.

Key	Type	Default
Spawn_Chance	float	-
Loot_Chance	float	-
Crawler_Chance	float	-
Sprinter_Chance	float	-
Flanker_Chance	float	-
Burner_Chance	float	-
Acid_Chance	float	-
Boss_Electric_Chance	float	-
Boss_Wind_Chance	float	-
Boss_Fire_Chance	float	-
Spirit_Chance	float	-
DL_Red_Volatile_Chance	float	-
DL_Blue_Volatile_Chance	float	-
Boss_Elver_Stomper_Chance	float	-
Boss_Kuwait_Chance	float	-
Respawn_Day_Time	float	-
Respawn_Night_Time	float	-
Respawn_Beacon_Time	float	-
Quest_Boss_Respawn_Interval	float	-
Damage_Multiplier	float	-
Armor_Multiplier	float	-
Backstab_Multiplier	float	-
NonHeadshot_Armor_Multiplier	float	-
Beacon_Experience_Multiplier	float	-
Full_Moon_Experience_Multiplier	float	-
Min_Drops	uint	-
Max_Drops	uint	-
Min_Mega_Drops	uint	-
Max_Mega_Drops	uint	-
Min_Boss_Drops	uint	-
Max_Boss_Drops	uint	-
Slow_Movement	bool	-
Can_Stun	bool	-
Only_Critical_Stuns	bool	-
Weapons_Use_Player_Damage	bool	-
Can_Target_Barricades	bool	-
Can_Target_Structures	bool	-
Can_Target_Vehicles	bool	-
Can_Target_Objects	bool	-
Beacon_Max_Rewards	uint	-
Beacon_Max_Participants	uint	-
Beacon_Rewards_Multiplier	float	-

How the Zombies Section Is Loaded

When a server starts, it reads Config.json from its configuration directory. The Zombies section is one of several top-level sections in that file. If the section is present, the server reads each key it recognises and applies the value. If the section is absent entirely, the server applies its hardcoded defaults for every key. If individual keys within the section are absent, those specific keys fall back to their individual defaults.

There is no validation beyond type checking. A float key that receives a string value is silently ignored. A uint key that receives a negative integer may produce undefined behaviour because the type is unsigned. A bool key that receives something other than true or false (such as a string "yes", a number 1, or a null) may be treated as false or may cause a parse error for the entire section. Server owners should validate their JSON with a dedicated linter before deploying, and should watch the server console output during startup for any parse warnings that reference the Zombies section or an individual key name within it.

The server does not automatically reload the config during operation. Any change to the Zombies section requires a server restart to take effect. There is no runtime hot-reload for this section.

Spawn Density

Zombie population is the foundation. Every other key in this section modifies the behaviour of zombies that exist. If there are no zombies on the map because Spawn_Chance is set to zero, the damage multipliers, armour values, stun mechanics, target preferences, loot tables, and beacon timers are all dormant. Spawn density should be the first key a server owner sets, and it should be the first thing re-evaluated whenever a change elsewhere alters the difficulty of individual zombies.

Spawn_Chance

Spawn_Chance is a value between 0 and 1 that functions as a population cap over all of the map's placed zombie spawn points. It does not add new spawn points, nor does it remove any the map author placed. The author defines where zombies can appear and how many spawn points exist in each area. Spawn_Chance controls what fraction of those spawn points are active at any given time, and the server's spawn logic ensures that the total active count across all spawn points does not exceed the product of the total number of spawn points and this value.

Consider a town on a map where the creator placed 100 zombie spawn points. If the server's Spawn_Chance is 0.2, the server will allow at most 20 zombies at a time in that town -- the product of the 0.2 chance and the 100 spawn points. As zombies are killed, their spawn points become eligible for a respawn after the relevant respawn timer expires. The server repopulates spawn points up to the cap. If Spawn_Chance is 1.0, all 100 spawn points can be active simultaneously.

The practical effect of a given Spawn_Chance value depends on the map. On a dense urban map where spawn points are packed close together -- a city block might have 20 or 30 spawn points -- a value of 0.5 still produces heavy local clustering because the spawn points are so dense that the cap still allows many zombies in a small area. On a sparse rural map where spawn points are spread across large fields, the same 0.5 might mean the player sees one or two zombies at a time because the spawn points themselves are far apart and the cap is distributed across a large area. A server owner who wants to tune density precisely must walk the map at different Spawn_Chance values and observe how the local clustering feels at ground level.

The interaction between Spawn_Chance and the special-variant chance keys is fundamental. A Sprinter_Chance of 0.1 on a server where Spawn_Chance is 1.0 in an area with 100 spawn points produces more sprinting zombies than the same variant chance on a server where Spawn_Chance is 0.2 in the same area, because the total number of active zombies is the multiplier that gives each variant chance its practical weight. A server owner configuring variants and spawn density simultaneously should calculate the expected count of each variant type in a representative area and verify that the result matches the intended encounter difficulty.

Setting Spawn_Chance to 0 disables zombie spawning entirely. The map still loads its spawn points, but none of them ever activate. The server is effectively zombie-free. This is the simplest way to create a purely PvP or purely exploration-focused server.

The relationship between Spawn_Chance and the Can_Target_Structures and Can_Target_Barricades keys is also important. A server with high Spawn_Chance AND structure targeting enabled will see walls, barricades, and other player-built defences destroyed much faster than a server with low Spawn_Chance because more zombies are hitting the structures simultaneously. The damage to structures scales with population density.

Special Zombie Types and Their Chances

Fifteen keys in the section are chance values between 0 and 1. Fourteen of them control the probability of a zombie spawning as a specific special variant instead of as an ordinary zombie. One -- Loot_Chance -- sits here in the table sequence but controls loot behaviour rather than variant type.

At a mechanical level, every variant chance works identically: the server arrives at a spawn point, decides that a zombie will spawn there, and then rolls against each variant's chance independently. The rolls are not additive and the server does not guarantee that a zombie will be exactly one special type. When multiple variant chances are enabled at meaningful values, the game's internal resolution logic determines which type the zombie ultimately becomes.

A variant chance set to 0 disables that variant. A key set to 1.0 means every zombie spawns as that variant -- a configuration that on most servers would represent an extreme difficulty setting. Most server operators work in the 0.01 to 0.2 range for individual variants and combine variants at low values rather than maxing out a single type.

The fourteen variant keys fall into three natural groups: standard variants that function on any map, boss variants that are intended as major encounters, and crossover variants from Dying Light that sit at the top of the threat hierarchy.

Standard Variants

These six variants are available on every map without requiring curated map assets. They are the variants most commonly enabled on servers of all difficulty levels.

Crawler_Chance controls how often a zombie spawns as a crawler. A crawler moves along the ground rather than walking upright. It closes distance and attacks on contact like any zombie, but its low profile makes it difficult to see. In tall grass, behind low walls, among scattered debris, or in any environment with visual clutter below waist height, a crawler can reach melee range before the player registers its presence.

Crawlers are not more damaging than standard zombies on a per-hit basis. Their threat is positional: they approach from below the player's natural scan line. A player who is scanning the horizon for upright movement will miss the crawler at ground level. A player who is backing away from a sprinter and watching the open space ahead will not see a crawler approaching through undergrowth from the side. On maps with uneven terrain, vegetation, rubble, or urban clutter, a crawler chance as low as 0.03 produces a noticeable increase in surprise contact frequency. The crawler is not the most dangerous special type by raw stats, but it is one of the most effective at creating tension because it forces players to scan vertically across the full field of view, not just the horizon.

Sprinter_Chance controls how often a zombie spawns as a sprinter. This is the variant that most directly changes the tempo of every zombie encounter, and it is the first variant most server operators adjust when they want to make zombies more dangerous. A standard zombie shambles. There is time to spot it at distance, acquire a sight picture, fire one or more shots, and reposition before contact. A sprinter compresses that timeline: from the moment the zombie enters render range to the moment it reaches the player is a fraction of the standard interval.

Sprinters also pursue further and break pursuit less readily. A standard zombie that loses line of sight or that the player outruns will typically stop and return to its spawn area. A sprinter will chase further, follow around corners, and maintain pursuit through terrain breaks that would cause a standard zombie to disengage. One alert sprinter can pull a chain of other zombies across a larger catchment area because its speed carries it through multiple activation radii.

The psychological effect on player behaviour is significant. On a server with zero sprinters, players can move through the world at a relaxed pace, knowing that any zombie they see can be outrun. On a server with even a 5% sprinter chance, every zombie silhouette on the horizon is a question: is this one going to run? Players slow down, scan more carefully, and plan routes that minimise line of sight to spawn zones.

Flanker_Chance controls how often a zombie spawns as a flanker. A flanker deviates from the direct approach path. Instead of moving in a straight line toward the player's current position, it attempts to circle around and attack from the side or rear. This behaviour is mechanically distinct from standard zombie pathfinding.

Flankers are most dangerous in combination with other variants. A player kiting a sprinter backward is moving in a straight, predictable line. A flanker that has circled during the engagement can intersect that line from behind while the player is tunnel-visioned on the sprinter ahead. Flankers punish players who fixate on a single target during combat and reward players who maintain situational awareness and check their surroundings between shots. A server that runs both sprinters and flankers creates encounters where the player must simultaneously manage a fast-closing frontal threat and an unpredictable lateral threat.

Burner_Chance controls how often a zombie spawns as a burner -- a zombie that is on fire. The visual signature is obvious: a moving flame in a world of muted colours. Contact with a burner ignites the player, applying fire damage over time that continues to tick after the initial hit and after the burner itself is killed.

The persistent damage is what makes burners disproportionately dangerous. A player who kills a burner in melee range has already been ignited and will take the full burn duration regardless. A player who is ignited while fighting other zombies must manage the ticking fire damage while continuing to deal with the remaining threats. In confined spaces -- building interiors, narrow corridors, stairwells, choke points -- a burner that reaches the player is nearly guaranteed to connect because there is no room to dodge. The combination of a burner in an enclosed space with other melee zombies is one of the deadliest standard encounters the game can produce, because the player cannot avoid the ignition while also managing the other threats.

Acid_Chance controls how often a zombie spawns as an acid spitter -- the only standard variant that attacks at range. An acid spitter fires a projectile rather than closing to melee distance. This single mechanical difference changes the geometry of every encounter that includes a spitter. A player who has positioned themselves on a roof, behind a fence, up a ladder, or on any elevated surface where melee zombies cannot reach is still vulnerable to the spitter's projectile. The safe spots that work against an all-melee zombie population do not work against a mixed population that includes spitters.

Acid spitters also force changes in kiting behaviour. The standard tactic for fighting melee zombies is to walk backward while firing, creating distance while dealing damage. This tactic fails against spitters because walking backward in a straight line makes the player an easy projectile target. Players must introduce lateral movement, use cover to break line of sight with the spitter, and track incoming projectiles while also managing the melee zombies that are still closing.

Spirit_Chance controls how often a zombie spawns as a spirit -- a ghost variant. The spirit's behaviour and damage model differ from standard zombies, and its interaction with player weapons differs from corporeal variants. The specific mechanics of how spirits take damage, which weapons affect them, and how they move are handled by the game's internal logic for the spirit zombie type. A server owner enabling spirits should verify that the server's weapon ecosystem includes effective options against spirit-type enemies.

Boss Variants

Five boss-variant chance keys control the spawn rate of the large, high-health zombies designed to be major encounters. Bosses have substantially more health than standard zombies and typically carry area-of-effect or special attacks. Enabling a boss variant at any non-trivial rate changes the fundamental threat profile of the server's zombie population: a single boss in a pack of standard zombies redefines the tactical problem for the entire encounter.

Boss_Electric_Chance controls the electric boss. This variant uses electrical attacks and is one of the core boss types available across multiple official maps. It is larger, more durable, and more damaging than any standard variant. A server with this key enabled should expect players to require coordinated fire or heavy weapons to bring one down efficiently.

Boss_Wind_Chance controls the ground-pounding boss. The wind boss uses area-of-effect attacks that strike multiple targets and can displace or stagger players within the effect radius. The area damage means that positioning near a wind boss is more dangerous than near a standard boss. Players who use close-range shotgun or melee tactics against other bosses must adjust: the wind boss's area attack punishes proximity.

Boss_Fire_Chance controls the fire-breathing boss. Like the burner variant, this boss applies fire damage, but at boss scale with boss durability. A fire boss in an enclosed space is one of the most dangerous encounters the Zombies section can produce because the fire attack fills the confined volume and the player cannot avoid it without leaving the space entirely.

Boss_Elver_Stomper_Chance controls the Elver final boss. This variant is tied to the Elver curated map and its zombie assets only exist when the server loads Elver content. On servers that do not run Elver, this key has no effect because the referenced zombie type is absent from the asset pool. On servers that do run Elver, the stomper represents the apex zombie threat on that map.

Boss_Kuwait_Chance controls the Kuwait final boss. Like the Elver stomper, this variant is map-specific and only functions when the Kuwait map assets are loaded. It is the highest-tier zombie threat on Kuwait.

Crossover Variants

DL_Red_Volatile_Chance and DL_Blue_Volatile_Chance control the odds of a zombie spawning as a Dying Light Volatile, with the red and blue designations representing different Volatile versions. These variants were added as crossover content and are designed as end-game-calibre threats that sit above even the standard Unturned boss variants in danger level.

A server owner who enables either Volatile at any meaningful rate should expect the overall zombie difficulty to increase substantially beyond what normal boss variants produce. These are not variants to be enabled at non-trivial chances on a server where combat is meant to be a moderate challenge. A config that includes Volatiles alongside high Spawn_Chance and low Armor_Multiplier is a config where survival is the point and death is expected.

Managing Variant Chances in Practice

Variant configuration is the part of the Zombies section where incremental testing matters most. A server owner should enable one variant at a low value (0.02 to 0.05), run the server for a full play session, observe how the variant changes player behaviour, and only then consider adding a second variant or increasing the first. Enabling five variants simultaneously at moderate chances creates a chaotic combat environment where no one can tell which variant is causing which behavioural change.

Variant chances must also be considered against the loot economy. If a server delivers a hard combat experience -- sprinters, flankers, bosses at non-trivial rates -- the loot drop keys should compensate so that players who spend ammunition on these threats can replenish. A server where every fight is expensive and no fight pays out is a server where players learn to avoid combat. The loot section of this document covers the economic side of that equation.

Map-Specific Variant Viability

The two map-specific boss keys (Boss_Elver_Stomper_Chance and Boss_Kuwait_Chance) raise a practical consideration for server operators who rotate maps. A config that includes these keys and is deployed across multiple maps will see the keys function on their associated maps and silently produce no effect on other maps. This is not an error, but it means the difficulty profile of the server changes depending on which map is active. A server operator who wants a uniform zombie experience across all maps should either set these keys to 0 or accept that the Elver and Kuwait maps will have an additional, higher-tier threat that other maps do not.

Respawn Timers

Four keys control how fast zombies return after being killed. Three are condition-specific timers that activate under different in-game states. One is a cooldown on a specific mechanic.

Respawn_Day_Time

This is the number of seconds the server waits after a zombie dies before respawning it at its spawn point, during normal daylight conditions and at any time when a full moon is not active and a horde beacon is not running. This is the default respawn timer -- the one that applies during the majority of a server's uptime on most maps.

A high value (300 seconds or more, which is five minutes) means zones stay cleared for extended periods. A player or group can clear a town of zombies and work in it -- looting, building, crafting, roleplaying -- for several minutes before anything respawns. A low value (30 to 60 seconds) means respawns happen within the same play session in which the zombies were killed. The first zombies killed in a street will have respawned by the time a player clears the buildings along that street.

The timer interacts with player count in a way the server does not account for. A solo player on a server with a 120-second respawn timer can clear a small area and complete a short task before the respawn fires. A group of ten players on the same server can clear a much larger area -- an entire town -- and hold it zombie-free for the full timer duration because the group's combined damage output kills every spawn point in the area before the first respawn triggers. The server applies the same delay regardless of how many players are active. A server owner should set Respawn_Day_Time with the expected peak player count in mind. A timer that feels right for a solo player will feel very long for a coordinated group.

The timer also interacts with the server's player-versus-player dynamics. On a PvP server where players clear zombies from an area before fighting each other, a long respawn timer means the cleared zone stays clear for the entire engagement. A short respawn timer means zombies return mid-fight, adding a third party to player-versus-player encounters.

Respawn_Night_Time

This is the number of seconds the server waits before a dead zombie respawns during a full moon. The full moon is a periodic in-game event that typically increases zombie danger through this timer and through any moon-phase multipliers or effects the server has active.

The canonical server configuration sets Respawn_Night_Time lower than Respawn_Day_Time, making zombies return faster during the moon phase. This compounds the danger: zombies are not only individually more threatening (depending on multiplier settings), they are also more numerous over time because the replenishment rate is higher. The magnitude of the difference between the two values defines how sharply difficulty spikes during the full moon. If Respawn_Day_Time is 300 seconds and Respawn_Night_Time is 30 seconds, the full moon is a tenfold increase in zombie output -- a fundamentally different game mode. If the values are close (300 and 240 seconds), the full moon is a gentle nudge.

A server owner who wants full moons to be a survival-defining event can set Respawn_Night_Time very low and combine it with elevated Damage_Multiplier and variant chances. A server owner who wants full moons to be a minor atmospheric shift can leave Respawn_Night_Time close to or equal to the daytime value. There is no requirement that the night timer be lower; a server could theoretically set it higher than the day timer, creating a world where zombies are slower to return at night, though this would be an unusual configuration.

Respawn_Beacon_Time

This is the number of seconds the server waits before a dead zombie respawns during an active horde beacon event. The horde beacon is a player-placed device that, when activated, calls waves of zombies to its location. The beacon respawn timer controls the interval between waves.

A value in the 5-to-15-second range creates near-continuous combat. Zombies die and their replacements appear almost immediately, giving players no pause between waves. The entire event is one sustained engagement from activation to completion. This tests player endurance and resource depth: can the group maintain output continuously for the full beacon duration?

A value in the 30-to-60-second range creates distinct waves with clear pauses. Players have time to reload, apply medical items, reposition defences, communicate target priorities, and reset before each new wave. This tests tactics and coordination rather than raw endurance.

A value above 90 seconds creates very slow, deliberate beacon events with extended preparation windows between short, intense fights. This variant is uncommon but can work on servers where beacon events are meant to be social gatherings rather than combat trials.

The choice between continuous and pulsed pacing is one of the most immediately noticeable tuning outcomes in the Zombies section, and it is controlled entirely by this single key. A server owner should decide whether they want beacons to feel like a siege (continuous) or a series of raids (pulsed) and set the timer accordingly.

Quest_Boss_Respawn_Interval

This is the minimum number of seconds that must pass between boss zombie spawns triggered by players who are completing quests. The key exists to close an exploit: players were using quest mechanics to trigger boss spawns at a rate much faster than intended and farming the boss loot tables for high-value drops.

This key establishes a cooldown between quest-driven boss spawns. Setting it to 300 seconds (five minutes) means that once a quest triggers a boss spawn, no quest can trigger another boss spawn for five minutes, regardless of how many players are doing quests or how many quests they complete. Setting it higher extends the lockout and makes quest bosses rarer.

This key does not affect boss spawns that occur through the normal variant chance system. A Boss_Electric_Chance of 0.01 produces boss spawns on its own schedule, independent of this cooldown. This key also does not affect boss spawns during horde beacons. It is specifically and exclusively a throttle on quest-driven spawn mechanics.

A server owner who wants quest bosses to be rare, individually valuable events sets this key high. A server owner who does not mind or wants to encourage quest boss farming sets this key low or omits it entirely.

Combat and Armour

Seven keys control the damage relationship between players and zombies. Four are multipliers (applied to damage values). Three are boolean toggles (enabling or disabling specific combat mechanics). Together they define how dangerous each zombie hit is, how dangerous the player's response is, and which combat rules are in play.

Damage_Multiplier

This is a multiplier applied to every point of damage any zombie deals to any player. A value of 1.0 is the baseline: zombies deal their base damage as defined in the game's asset data, unmodified. A value of 2.0 means every zombie attack deals double its base damage. A value of 0.5 halves zombie damage output.

This is the most direct difficulty adjustment in the entire Zombies section. It does not change zombie health, spawn density, respawn speed, variant behaviour, or loot. It changes one thing: how much each hit hurts. The effect is uniform across all zombie types and all damage sources. A server owner who wants zombies to be more threatening can increase this value and the effect is immediate across every zombie encounter on the server.

Armor_Multiplier

This is a multiplier applied to every point of damage a player deals to a zombie. It functions as a universal damage resistance (or vulnerability) applied to the entire zombie population simultaneously. A value of 1.0 is baseline: zombies take full damage. A value of 0.5 means every bullet, swing, and explosion does half damage -- all zombies effectively have 50% damage reduction. A value of 2.0 means zombies take double damage from all sources.

Damage_Multiplier controls how zombies hurt players. Armor_Multiplier controls how players hurt zombies. The two multipliers are completely independent. A server can configure zombies that hit like trucks (high Damage_Multiplier) but fall over in one shot (high Armor_Multiplier -- meaning low damage resistance), creating fast, lethal encounters where the first side to land a hit wins. Or it can configure zombies that barely scratch (low Damage_Multiplier) but absorb ammunition endlessly (low Armor_Multiplier -- meaning high damage resistance), creating attrition fights where the danger is resource depletion, not burst damage.

The Combined Effect of Damage and Armour

When both Damage_Multiplier and Armor_Multiplier are changed from their defaults simultaneously, the effect on encounter difficulty compounds multiplicatively. A server with Damage_Multiplier at 2.0 and Armor_Multiplier at 0.5 has multiplied the baseline danger of each zombie encounter: the zombie deals double damage and requires double the hits to kill. A server with Damage_Multiplier at 0.5 and Armor_Multiplier at 2.0 has reduced the baseline danger of each zombie encounter in the opposite direction.

The product of the two values provides a reference point for individual-zombie encounter difficulty. This reference should be used as a calibration guide, not as a precise measure. It does not account for variant type (a sprinter is harder than a crawler regardless of the damage product), spawn density (more zombies is harder regardless of the damage product), or environmental factors. But it provides a sanity check: a product above 3.0 points toward hardcore territory, a product near 1.0 points toward standard, and a product below 0.5 points toward beginner territory.

Backstab_Multiplier

This is a multiplier applied to the damage a zombie takes when the player attacks it from behind. Backstab mechanics are weapon-dependent: only certain weapons support the backstab damage bonus. A weapon without backstab support deals its normal damage from every angle regardless of this multiplier. For weapons that do support backstab attacks, this value scales the bonus damage applied when the attack connects from the rear.

A server that wants to reward stealth, positioning, flanking, and team coordination can set this value above 1.0 (1.5 to 3.0 is a common range) so that a well-set-up backstab is a decisive tactical move. A server that wants backstabs to be a minor flavour mechanic can leave this at or near 1.0. Setting it below 1.0 would penalise backstabs relative to frontal attacks, which would be a punitive rather than rewarding configuration.

NonHeadshot_Armor_Multiplier

This is a damage multiplier that applies exclusively to hits that do not strike a zombie's head. Body shots, arm shots, leg shots -- anything that is not a headshot -- has its damage multiplied by this value. A value of 1.0 means body hits deal their full normal damage. A value of 0.0 means body hits deal zero damage; only headshots can harm zombies.

Intermediate values define the server's accuracy standard. A value of 0.25 means body hits deal one-quarter damage. Headshots are the only efficient way to kill, but a player who misses the head can still make incremental progress. A value of 0.5 splits the gap: headshots are strongly preferred, body shots are weak but functional.

A common hardcore configuration pairs Armor_Multiplier at 1.0 (standard zombie damage intake) with NonHeadshot_Armor_Multiplier at 0.25 or lower. This keeps zombie health manageable for accurate shooters while making panicked body-spraying an ammunition-wasting exercise. The result is a skill-gated combat model: good aim is rewarded, bad aim is heavily penalised.

Weapons_Use_Player_Damage

This is a boolean toggle. When set to true, weapons attacking zombies use their player-target (PvP) damage profile instead of their zombie-target damage profile. Weapons in Unturned carry separate damage values for different target categories. This key discards the zombie-specific numbers and substitutes the PvP numbers.

The practical effect varies by weapon. Some weapons have higher damage against players than against zombies; enabling this key makes those weapons more effective. Some weapons have lower PvP damage; they become less effective. The weapon roster on the server determines the net effect. A server owner who enables this key should test the entire weapon catalogue against zombies to understand which weapons change and by how much. Players will identify the winners and losers rapidly and will adjust their loadouts accordingly. The key effectively shuffles the weapon tier list for zombie combat, and the server owner should know what the new tier list looks like before players discover it.

Can_Stun

This is a boolean toggle. When set to false, no attack of any kind can stun a zombie. A stun is a brief interruption of the zombie's movement and attack animations -- a moment where the zombie is not advancing and not swinging. Removing stuns means zombies advance and attack without interruption from the moment they detect the player until the moment they are killed or the player breaks contact.

Disabling stuns is a difficulty increase that does not appear in any damage number, any health value, or any spawn rate. It operates on combat control. With stuns enabled, a player fighting two zombies can stagger one with a well-timed attack and deal with the other in the window created by the stagger. The two-on-one becomes a series of one-on-ones. With stuns disabled, the player faces both zombies simultaneously for the entire duration of the fight. There is no window.

The effect is most pronounced in melee combat. Ranged players can create distance and manage threats through positioning, but melee players rely on stuns to create breathing room. A server that disables stuns implicitly pushes players toward ranged combat and away from melee.

Only_Critical_Stuns

This is a boolean toggle. When set to true, only specific weapons and attack types -- documented critical attacks such as backstabs, headshots with certain weapons, or attacks from weapons flagged for critical stuns -- can stagger a zombie. Ordinary melee swings and gunfire cannot.

This key has no effect if Can_Stun is false, because there are no stuns to restrict. It is designed as a middle position between stuns-on and stuns-off. A server with Can_Stun at true and Only_Critical_Stuns at true creates a combat environment where stuns exist but are not freely available. Players must earn them through specific weapon choices, positioning, or aim. The server signals that stunning is a skilled action, not a baseline mechanic.

Slow_Movement

This is a boolean toggle. When set to true, every zombie on the server moves at a reduced speed relative to its normal movement rate. The speed reduction is universal: crawlers, sprinters (still faster than standard zombies, but slower than their normal sprint speed), flankers, bosses, and standard zombies all move slower.

This is a global difficulty reducer that works through positioning and time-to-contact. Slower zombies give players more time to aim, reload, reposition, flee, and make tactical decisions. A player who can outrun a zombie is a player who is never forced into combat. On servers aimed at beginners, at casual play, or at survival-focused gameplay where combat is meant to be an avoidable hazard rather than a central loop, enabling Slow_Movement makes zombies less oppressive in every dimension without touching any damage, health, or spawn number.

Target Selection

When a zombie navigates toward a detected player, it may encounter obstacles. Four boolean keys control which categories of obstacle the zombie will stop to destroy. If all four are false, zombies interact only with players and ignore everything else. They will attempt to path around obstructions if a navigable route exists; if fully blocked, they will stand idle.

Can_Target_Barricades

When true, zombies attack barricades -- player-placed defensive items such as barbed wire, spikes, sandbags, and other deployable obstacles. Barricades are the outer layer of player-built defences.

If this key is false, barricades are permanent barriers. A ring of barbed wire stops zombies absolutely and forever. Zombies will not cross it and cannot break it. Defences require no maintenance beyond initial placement. If true, barricades are consumable -- they slow zombies down, incur a time cost, and eventually break. Players must monitor, repair, and replace their barricades. The choice between permanent and consumable barricades defines the server's perimeter defence culture.

Can_Target_Structures

When true, zombies attack structures -- walls, floors, doorframes, roof pieces, pillars, and all other building components. This is the key that determines whether zombie sieges exist as a mechanic on the server.

If structures are immune, a wall is absolute safety. Players can build a perimeter and know with certainty that zombies cannot breach it. Logging off inside a base is secure. If structures are vulnerable, every wall segment has a countdown attached. Zombies accumulating against a base exterior deal damage over time. The damage rate scales with the number of zombies pressing against the structure, which in turn scales with Spawn_Chance. A server with structure targeting AND high spawn density will see walls degrade significantly faster than one with structure targeting and low spawn density.

This key changes the building culture of a server. When structures are immune, players build for aesthetics, internal layout, and PvP defence. When structures are vulnerable, players build for zombie-proofing: layered walls, repair logistics, active patrol routes, and materials chosen for durability rather than appearance. A server that enables structure targeting should be explicit about it, because it fundamentally alters what a base is for.

Can_Target_Vehicles

When true, zombies attack vehicles that obstruct their movement. Vehicles have health pools and can be destroyed by sustained damage. A vehicle parked in or near a zombie spawn zone will accumulate damage whenever zombies pass through the area. Left unattended long enough, it will be destroyed.

This key matters most on servers where players use vehicles as static cover, as gate blockers, as wall plugs, or as permanent fixtures in high-traffic zombie areas. Enabling this key communicates that vehicles are transportation, not terrain. A vehicle is not a permanent barrier and cannot be relied upon to hold a position indefinitely.

Can_Target_Objects

When true, zombies attack level objects -- fences, lamp posts, signposts, crates, and any map-authored prop that stands between the zombie and the player. These objects belong to the map. Their health, destruction behaviour, and respawn logic are defined by the map's own configuration, not by player maintenance.

Enabling this key means the map environment changes over the course of a session. A fence that was intact at the start of a day may be broken by the end, having absorbed cumulative zombie damage. This matters on persistent servers with extended uptimes and no scheduled map resets. The server owner should verify that the map's object respawn behaviour is reasonable before enabling this key, to avoid a scenario where the environment degrades permanently without recovery.

Loot Drops

Seven keys control the item output from zombie kills. Six are min-max pairs for three zombie tiers (standard, mega, boss). One is Loot_Chance, a probability gate on single-item drops.

The loot system operates in two sequential steps for each zombie killed:

1. The server selects a random integer between the applicable minimum and maximum (inclusive). This is the number of items the zombie will attempt to drop.
2. If the rolled number is exactly 1, the server checks Loot_Chance. If the Loot_Chance roll passes, the item drops. If it fails, nothing drops. If the rolled number is 2 or greater, all items drop unconditionally -- Loot_Chance is not consulted.

This two-step process has an important design consequence: a server that sets Min_Drops to 2 or higher on any tier bypasses Loot_Chance entirely for that tier, because the minimum roll is above the threshold that triggers the Loot_Chance check.

Loot_Chance

Loot_Chance is a value between 0 and 1 that gates drops when the min-max roll produces exactly one item. A value of 0 means single drops never happen: a zombie that rolls a 1 for its drop count drops nothing. A value of 1 means single drops always happen. A value of 0.5 means a coin flip.

The practical effect depends on the drop range. If Min_Drops is 0 and Max_Drops is 3, single-drop rolls occur when the server rolls a 1 but not a 0, 2, or 3. In this configuration, single-drop scenarios where Loot_Chance is consulted will occur on some fraction of kills. If Min_Drops is 1 and Max_Drops is 1, every kill produces exactly one drop and Loot_Chance is the sole gate on loot output.

Min_Drops and Max_Drops

These control the drop count for standard, non-mega, non-boss zombies. Standard zombies make up the vast majority of the zombie population on any server. These two values define the baseline loot economy.

If Max_Drops is 0, standard zombies never drop items. Combat is purely a resource expenditure with no material return. Players loot the world, craft, or trade for their gear. If Max_Drops is 3 or higher and Min_Drops is 1 or higher, standard zombie kills reliably produce multiple items, making routine combat a significant gearing path.

Most servers operate with Min_Drops at 0 or 1 and Max_Drops between 1 and 3. This produces occasional drops -- enough that killing zombies feels worthwhile in aggregate, but not enough that players gear up entirely from zombie kills.

Min_Mega_Drops and Max_Mega_Drops

These control the drop count for mega zombies that are not classified as bosses. Mega zombies are larger, hardier, and more dangerous than standard zombies. They take more time, ammunition, and risk to kill. The drop range for mega zombies should reflect that cost: a mega zombie that drops the same number of items as a standard zombie is a bad trade for the player, because the effort-to-reward ratio is worse.

The standard configuration sets Min_Mega_Drops and Max_Mega_Drops to values higher than Min_Drops and Max_Drops. This ensures that the increased combat cost is matched by an increased loot return, maintaining a consistent risk-reward ratio across zombie tiers.

The same Loot_Chance gate applies to mega zombies: a single-drop roll consults Loot_Chance; a multi-drop roll is unconditional.

Min_Boss_Drops and Max_Boss_Drops

These control the drop count for boss-tier zombies: electric boss, wind boss, fire boss, Elver stomper, Kuwait boss, and Dying Light Volatiles. Bosses are the apex of the zombie hierarchy. They are the most expensive kills on the server in terms of ammunition, medical supplies, time, and risk.

A common and recommended configuration sets Min_Boss_Drops to 2 or higher. This provides a specific mechanical guarantee: because the minimum roll is above 1, Loot_Chance is never consulted for boss kills. Bosses always drop at least two items. This guarantee is important on servers where boss encounters are rare -- because variant chances are low -- and the server owner wants every boss kill to be a meaningful event that reliably rewards the player or group that achieved it.

The Loot-Difficulty Relationship

The loot drop keys and the combat difficulty keys are economically linked. A server can be plotted on two axes: combat difficulty (how hard zombies are to kill) and loot return (how much they drop when killed). The four quadrants produce four distinct server dynamics:

• Hard combat, stingy loot: Zombies are dangerous and unrewarding. Players avoid combat. Zombies are environmental hazards to be bypassed, not content to be engaged. This works for stealth or exploration servers where combat is meant to be failure, not gameplay.

• Easy combat, generous loot: Zombies are supply crates with legs. Players seek combat actively. Zombies are the primary gearing mechanism. This works for action-oriented servers where combat is the main loop.

• Hard combat, generous loot: High risk, high reward. Fighting is dangerous and expensive, but success pays out substantially. This creates tension: every encounter is a gamble. This works for servers that want combat to feel consequential.

• Easy combat, stingy loot: Zombies are an annoyance. They exist, they are easy to dispatch, and they do not repay the ammunition spent. Players ignore them unless forced to engage. This works for PvP-focused servers where zombies are background flavour.

The server owner's job is to decide which quadrant describes the intended server, then to set the damage, armour, and loot keys to place the server in that quadrant.

Beacon and Horde Behaviour

Five keys control the mechanics of horde beacons and the full-moon experience bonus. Three are loot-related, governing beacon drop volume. Two are experience-related, governing the XP value of beacon and full-moon kills.

Beacon_Rewards_Multiplier

This is a multiplier applied to the total number of items a horde beacon drops when its event concludes successfully. A value of 1.0 means the beacon drops its unmodified base payout. A value of 2.0 doubles the item count. A value of 0.5 halves it.

The multiplier applies before the Beacon_Max_Rewards cap. If the base payout is 15 items, the multiplier is 3.0 (total 45), and the cap is 20, the beacon drops 20 items and the remaining 25 are discarded. Raising the multiplier without also raising the cap wastes the multiplier when the multiplied total exceeds the cap.

Beacon_Max_Rewards

If set to a value greater than 0, this key caps the total number of items a horde beacon can drop per event. It exists because beacon loot scales with the number of players participating. On a large server with many participants, the unscaled payout can reach numbers that destabilise the item economy.

Setting this to a specific number places a hard ceiling on per-event beacon output. A value of 0 means no cap; the beacon drops whatever the participant-scaled and multiplier-adjusted total produces. The server owner should set this value with the server's intended economy in mind. A survival server where items are meant to be scarce should set a low cap. An event server where beacons are the main attraction should set a higher cap or leave it uncapped.

Beacon_Max_Participants

If set to a value greater than 0, this caps the number of players the beacon uses when calculating its base loot payout. The beacon's loot formula includes a scaling factor based on participant count. Each additional player increases the output. Without a cap, a full-server beacon event where every player shows up produces an output proportional to the entire server population.

Setting this key means the beacon scales its payout as if the capped number of players are participating, even if more are present. Additional players beyond the cap contribute to combat but not to loot scaling. A value of 0 means no participant cap -- the beacon uses the actual participant count, however large.

The participant cap and the rewards cap work together. The participant cap limits the scaling factor. The rewards cap limits the final output. Between them, a server owner can define a bounded, predictable reward box for beacon events regardless of server population.

Beacon_Experience_Multiplier

This is a multiplier applied to the experience points earned from kills made during a horde beacon event. A value of 2.0 means every zombie killed within the beacon zone grants double XP. This key gives server owners a way to make beacon events valuable for players who are focused on skill progression rather than item drops.

A high multiplier encourages participation from players who do not need beacon loot but do want XP. A value of 1.0 means beacon kills grant standard XP -- no bonus, no penalty.

Full_Moon_Experience_Multiplier

This is a multiplier applied to the experience points earned from zombie kills during a full moon. Full moons are typically more dangerous than normal conditions because the respawn timer is faster and other moon-phase effects may be active. This key compensates for the increased danger with increased progression rewards.

A server that runs punishing full-moon settings -- high damage, fast respawns, elevated variant chances -- might set this multiplier to 3.0 or higher so that players risking full-moon combat are proportionally rewarded. A server where full moons are a mild atmospheric change can leave this at 1.0 or omit it.

Beacon Config by Server Scale

Beacon configurations that work for a private server with five friends do not work for a public server with fifty strangers. The three loot keys must be scaled to the player population:

Small server (under 10 players): Participant caps are typically irrelevant because the actual player count sits below any reasonable cap. The active levers are the rewards multiplier and max rewards ceiling. A config might set Beacon_Rewards_Multiplier to 2.0 or 3.0, leave Beacon_Max_Participants at 0 (uncapped), and set Beacon_Max_Rewards at 0 or a generous value.

Medium server (10 to 30 players): The participant cap becomes useful. If beacons are designed for squads of 5 to 8, the cap should reflect that. The config might set Beacon_Max_Participants to 8, Beacon_Rewards_Multiplier to 1.5 to 2.0, and Beacon_Max_Rewards to 15 to 25. This creates a satisfying payout for a full squad without flooding the economy.

Large server (30+ players): All three keys are essential. The participant cap prevents scaling from running away with the server population. The rewards multiplier is set conservatively. The max rewards cap is the final safety net. A config might set Beacon_Max_Participants to 10, Beacon_Rewards_Multiplier to 1.5, and Beacon_Max_Rewards to 20.

On any server size, the server owner should test beacon output at peak population and verify that the actual drop count matches the intended ceiling. A config that looks right on paper can produce very different results when 40 players show up to a beacon event.

Canned Beans

The Zombies section of Config.json contains no reference to food items, consumable item IDs, or canned beans. None of the forty-two keys in this section governs which specific items a zombie can drop when killed. The keys Min_Drops, Max_Drops, Min_Mega_Drops, Max_Mega_Drops, Min_Boss_Drops, Max_Boss_Drops, and Loot_Chance control how many items a zombie drops. They do not control which items. The item pool -- which specific weapons, ammunition types, medical supplies, clothing pieces, and food items can appear in a zombie drop -- is defined elsewhere: in the map's spawn tables and in the server's loot configuration systems. Those are separate from the Zombies section.

What the Zombies section can influence is the rate at which items enter the server economy through zombie combat. A server with high Max_Drops and Loot_Chance at 1.0 produces more items per zombie kill than a server with low values. If the spawn table that the zombie references happens to include canned beans, then increased drop volume means more beans in circulation. But the Zombies section cannot itself add beans to the drop pool, and it cannot remove them.

A server owner who wants to configure the specific items that zombies drop -- including whether canned beans appear at all, and at what rates -- must work with the map's spawn table files and the server's loot table configuration. Those systems are documented separately.

The canned beans themselves -- their in-game stats, their role as a survival staple, their distribution across official Unturned maps, their cultural significance in the 57 Studios server canon, and their history as an object of lore -- are documented in depth at The Canned Beans Lore.

Config Profiles for Common Server Types

The forty-two keys are a toolbox, not a checklist. Most servers set only a subset of keys, leaving the rest at their defaults. The profiles below describe typical starting configurations for common server types. They are calibration references, not mandates.

Survival and Roleplay Servers

A survival or roleplay server uses zombies as persistent environmental pressure, not as a dominant gameplay loop. Zombie encounters should be meaningful when they happen but should not define every moment of play.

Key Group	Typical Values	Rationale
Spawn_Chance	0.4 to 0.7	The world feels populated but not overrun.
Respawn_Day_Time	180 to 300	Cleared zones stay clear long enough for roleplay and building.
Respawn_Night_Time	60 to 120	Full moons are a distinct, more dangerous phase.
Respawn_Beacon_Time	30 to 60	Beacon events have paced waves with recovery windows.
Damage_Multiplier	1.0 to 1.5	Zombie hits matter but are not catastrophic.
Armor_Multiplier	1.0	Standard weapon performance.
Backstab_Multiplier	1.0 to 1.5	Modest positional reward.
Can_Stun	true	Combat has control mechanics.
Only_Critical_Stuns	false	Stuns are broadly available.
Can_Target_Structures	false	Bases are safe zones unless under declared siege.
Can_Target_Barricades	true	Perimeter defences require ongoing maintenance.
Can_Target_Vehicles	false	Vehicles are safe when parked.
Standard variant chances	0 to 0.03 each	Rare variety without the variants defining the experience.
Boss variant chances	0	Bosses are event content, not routine spawns.
Loot_Chance	0.3 to 0.5	Some payout, not guaranteed.
Min_Drops / Max_Drops	0 to 1 / 1 to 2	Modest standard drops.
Min_Mega_Drops / Max_Mega_Drops	1 to 2 / 2 to 3	Mega kills feel proportionally rewarding.
Beacon rewards	Moderate	Beacon events are worthwhile but not economy-warping.

Hardcore and Challenge Servers

A hardcore server places zombies at the centre of the experience. Combat is the primary activity, survival is the primary goal, and death is expected.

Key Group	Typical Values	Rationale
Spawn_Chance	0.8 to 1.0	Maximum population density.
Respawn_Day_Time	60 to 120	Cleared zones do not stay cleared.
Respawn_Night_Time	30 to 60	Full moons are dramatically more dangerous.
Damage_Multiplier	2.0 to 3.0	Every hit is a serious event.
Armor_Multiplier	0.5 or lower	Zombies are bullet sponges.
NonHeadshot_Armor_Multiplier	0.1 to 0.25	Body shots are extremely inefficient. Headshots required.
Backstab_Multiplier	2.0 to 3.0	Backstabs are the primary efficient kill mechanic.
Can_Stun	false, or Only_Critical_Stuns true	Stuns require specific preparation.
Can_Target_Structures	true	Bases are under constant siege pressure.
Can_Target_Vehicles	true	Vehicles are temporary cover, not permanent fixtures.
Can_Target_Barricades	true	All defences are consumable.
Sprinter chance	0.1 to 0.2	Sprinters define the tempo of outdoor movement.
Flanker and burner chances	0.05 to 0.1	Threat variety in every encounter.
Boss chances	0.005 to 0.02	Bosses are rare but genuinely threatening.
Loot_Chance	0.5 to 0.8	Combat reliably produces some return.
Min_Drops / Max_Drops	1 to 2 / 2 to 5	Combat is a primary loot source.
Min_Boss_Drops / Max_Boss_Drops	2 to 3 / 4 to 8	Boss kills are always rewarding.
Beacon rewards	Generous, capped	Beacons are major loot events with hard ceilings.

Beginner and Casual Servers

A beginner server invites players to learn the game without being punished by the zombie system for every mistake.

Key Group	Typical Values	Rationale
Spawn_Chance	0.2 to 0.4	Sparse zombie presence.
Respawn_Day_Time	300+	Zones remain cleared for extended looting and learning.
Damage_Multiplier	0.5	A zombie hit is a warning, not a crisis.
Armor_Multiplier	2.0	Zombies die quickly to any weapon.
Slow_Movement	true	Players can outrun every zombie type.
Can_Stun	true	Stuns are freely available.
Can_Target_Structures	false	Building is safe.
Can_Target_Barricades	false	Defences are permanent.
Can_Target_Vehicles	false	Vehicles are secure.
All variant and boss chances	0	No special variants. Only standard zombies.
Loot_Chance	0.7 to 1.0	Zombie kills almost always drop something to reward engagement.

Horde Beacon Event Servers

Event servers that centre on horde beacons as the primary content treat the overworld as a staging area and the beacon zone as the actual gameplay space.

Key Group	Typical Values	Rationale
Respawn_Beacon_Time	10 to 30 (continuous) or 30 to 60 (pulsed)	Wave pacing tuned to the event design.
Beacon_Rewards_Multiplier	2.0 to 4.0	Beacons are the primary reward mechanism.
Beacon_Max_Participants	8 to 16	Scales to intended group sizes.
Beacon_Max_Rewards	20 to 50	Hard ceiling on per-event payouts.
Beacon_Experience_Multiplier	2.0 to 5.0	Beacon kills are the main XP source.
Full_Moon_Experience_Multiplier	2.0 to 3.0	Full moons are secondary XP events.
Non-beacon zombie settings	Default, low, or beginner	Overworld zombies are not the focus and should not compete for attention.
Spawn_Chance (overworld)	0.2 to 0.5	Enough zombies for atmosphere, not enough to distract from beacons.

Testing Your Config

The Zombies section rewards methodical, incremental testing more than most other parts of the server configuration. A complete zombie config drafted on paper, deployed to the live server, and presented to the community will almost certainly not work as intended on the first try. The interaction between spawn density, variant chances, respawn pacing, damage scaling, combat mechanics, and loot economics is complex enough that the only reliable calibration method is iterative: set a baseline, play, adjust one group of keys, play again, and repeat.

Step one: set population and rhythm. Deploy the server with only Spawn_Chance and the three respawn timers set. Leave all variant chances at 0, all multipliers at their defaults, and all boolean toggles at their defaults. Walk the map at normal play pace and ask: does the zombie density feel appropriate for each area type (urban, suburban, rural, wilderness)? Do cleared zones stay clear for the right length of time? Does the full moon feel like a distinct phase? Adjust these four keys until the answer to all three questions is yes. The cadence is the foundation.

Step two: set the damage axis. Tune Damage_Multiplier and Armor_Multiplier together. Test across the weapon categories the server supports -- melee, pistols, rifles, shotguns, and any modded weapons. A damage config that feels right with a rifle may feel punishing with a melee weapon or trivial with a shotgun. The goal is consistency: every weapon category should produce roughly the same subjective encounter difficulty.

Step three: add variants one at a time. Enable one variant at a low value (0.03 to 0.05). Play for a full session. Note how players change their movement, their scanning behaviour, their engagement decisions. Then adjust the chance or add the next variant. Never add two new variants in the same config change. The diagnostic information is lost when too many variables change at once.

Step four: set the reward structure. After combat difficulty is stable, tune the loot drop ranges and beacon keys. Walk the economic equation: for an average player doing average combat over a one-hour session, does the loot income from zombie kills roughly offset the ammunition and medical supply expenditure? If the player is running a net deficit, they will learn to avoid zombies. If they are running a large surplus, zombies become the primary gearing path. Decide which dynamic the server should have and tune the drop ranges to produce it.

Step five: full-cycle playtest. Run a complete in-game cycle -- day, night, full moon -- with the final or near-final config. Play through a horde beacon event with the expected number of participants. Note every moment where the zombie behaviour felt wrong: too many zombies, too few, too fast, too slow, too hard, too easy, wrong variant frequency, wrong loot feel. Then address the most impactful issue with a single-key adjustment. Do not revise five keys at once to address five issues. Solve one problem, verify the fix, then solve the next.

Step six: community feedback loop. After the config is stable in solo testing, deploy it and observe. Listen to player feedback about zombie difficulty, loot payouts, and beacon value. Players will notice things that a solo tester cannot. But filter the feedback through the understanding of the keys: a player who says "zombies are too hard" might mean damage is too high, or armour is too high (they take too long to kill), or sprinter chance is too high, or respawn is too fast, or stuns are disabled. Diagnose the specific key that maps to the specific complaint and adjust that key, not a different one.

The config will converge toward the intended experience through repeated single-key adjustments informed by observation, rather than through broad multi-key revisions done at a desk.

Common Mistakes and Pitfalls

Setting Spawn_Chance Too High Without Understanding Map Density

The most common mistake in the Zombies section is setting Spawn_Chance to 1.0 on a map the server owner has not walked at ground level. Some maps, particularly dense urban maps or curated maps with high spawn-point counts, become functionally unplayable at full spawn density because every street has 15 to 20 active zombies simultaneously. The same value on a sparse rural map might feel appropriate. Before setting Spawn_Chance, walk the map at the intended value and observe the local clustering. The global cap number is not the experience; the local density at player height is.

Enabling Multiple Boss Variants Simultaneously

Five boss variant keys exist, plus two Volatile keys. A common instinct is to set all seven to small but non-zero values so that players encounter "variety." The result is that the boss spawn rate -- the aggregate chance of any boss appearing -- becomes the sum of seven small chances, which can be substantially higher than intended. A server with each boss chance set to a small value sees a combined boss rate that is the sum of all active chances, not the individual per-key rate. Server owners should sum their active boss chances and verify that the aggregate rate matches their difficulty intent.

Forgetting That Loot_Chance Is Not Consulted Above a Roll of 1

A server owner who sets Min_Drops to 2 and Loot_Chance to 0.5, expecting that half of all drops will be gated, will be surprised to find that Loot_Chance is never reached because the minimum roll is above the threshold. Every kill drops at least two items unconditionally. The Loot_Chance key is only active when the drop count roll lands on exactly 1. If the server owner wants half of all drops gated, they must ensure that single-drop rolls are possible, which means setting Min_Drops to 1 or 0.

Setting NonHeadshot_Armor_Multiplier Too Aggressively

A server that sets NonHeadshot_Armor_Multiplier to 0.0 creates a world where only headshots deal damage. This is a valid hardcore configuration, but it interacts poorly with certain weapon types. Shotguns, automatic fire, and explosive weapons are balanced around multiple hits or area damage, not precision. A server where only headshots work and the weapon roster includes area-effect or spread-fire weapons creates frustrating gameplay where half the arsenal is functionally useless against zombies. Before enabling headshot-only mode, test every weapon category on the server against a zombie and ensure that every weapon type the server supports has a viable path to a headshot.

Overlooking the Can_Target_Structures Interaction with Build Servers

A server that advertises itself as a building and creativity server but leaves Can_Target_Structures at true (or at its default, if the default is true) will receive confused and frustrated players who build elaborate structures only to watch zombies tear them down. The structure targeting key should be one of the first things a server owner verifies and communicates to the community. A building server with structure targeting disabled is a fundamentally different experience from a building server with it enabled.

Setting Respawn Timers Without Considering Player Count

A Respawn_Day_Time of 60 seconds feels appropriate for a solo player who clears zombies slowly. On a server with 20 players, that same timer means that by the time a group finishes clearing a town, the first zombies killed are already respawning behind them. The respawn timer should be calibrated for the number of players who will typically be active in a given area, not for a single player. If the server peaks at 30 concurrent players, test the respawn timer with at least 10 players in the same zone to understand how it feels at scale.

Confusing Armor_Multiplier Direction

The name Armor_Multiplier describes a multiplier on zombie armour -- their damage resistance. A value of 0.5 means zombies have half the effective health (they take more damage, meaning less armour). A value of 2.0 means zombies have double the effective health (they take less damage, meaning more armour). The direction is the opposite of what the name intuitively suggests to many server owners. Before deploying, test the armour value against a single zombie with a known-damage weapon and confirm that the number of hits to kill matches the expectation.

Enabling Dying Light Volatiles Without Testing

The Dying Light Volatiles (red and blue) are crossover variants designed as end-game threats. Enabling them at even 0.01 without testing what a Volatile encounter feels like on the current damage, armour, and spawn-density settings is a common source of player complaints. A Volatile on a server tuned for hardcore boss combat is appropriate. A Volatile on a server tuned for casual survival is a wipe event. The server owner should spawn or encounter a Volatile in controlled conditions before enabling the variant chance on the live server.

Key Interaction Quick Reference

The forty-two keys do not operate in isolation. The following table identifies the most important interactions between key groups, so server owners know which keys to adjust together and which interactions to verify after a change.

When you change...	Also check...	Because...
Spawn_Chance	All variant chance keys	Higher spawn density multiplies the practical effect of every variant chance.
Spawn_Chance	Can_Target_Structures, Can_Target_Barricades	More zombies = more structure damage per minute if targeting is enabled.
Damage_Multiplier	Loot drop ranges	Higher damage should be compensated with more loot to keep combat worthwhile.
Armor_Multiplier	NonHeadshot_Armor_Multiplier	If body shots are already penalised, increasing zombie armour makes body shots nearly worthless.
Sprinter_Chance	Respawn_Day_Time	Fast zombies that respawn quickly create an oppressive outdoor environment.
Any boss chance key	Min_Boss_Drops, Max_Boss_Drops	Boss kill frequency should correlate with boss kill reward.
Can_Stun	Only_Critical_Stuns	Setting Only_Critical_Stuns to true has no effect unless Can_Stun is also true.
Beacon_Rewards_Multiplier	Beacon_Max_Rewards	Raising the multiplier past the cap threshold wastes the multiplier.
Beacon_Rewards_Multiplier	Beacon_Max_Participants	A high multiplier with no participant cap on a large server produces extreme item inflation.
Slow_Movement	Sprinter_Chance	Slower movement applies to sprinters too -- they are still faster than standard zombies but not as fast as uncapped sprinters.
Can_Target_Structures	Respawn_Day_Time	Structures regenerate health slowly or not at all; fast zombie respawns with structure targeting means constant structure damage.

JSON Syntax Notes

The Zombies section must be valid JSON. The following syntax rules apply to every key:

• All keys must be double-quoted strings. Single quotes are not valid JSON and will cause a parse failure.
• float values are written as numbers with a decimal point: 0.5, 1.0, 2.0. Trailing zeros are optional (0.5 and 0.50 are both valid). Leading zeros are optional for values under 1 (0.5 and .5 are both valid, though 0.5 is conventional).
• uint values are written as whole numbers without a decimal point: 3, 10, 0.
• bool values are written as lowercased, unquoted true or false. The strings "true" and "false" are not boolean values and will not be recognised. The numbers 1 and 0 are not boolean values and will not be recognised.
• Commas separate key-value pairs. A trailing comma after the last pair in the section is technically invalid JSON but some JSON parsers tolerate it. Do not rely on parser tolerance.
• The section itself is an object within the larger Config.json structure. It should be enclosed in curly braces and follow the key-value pair syntax of the parent file.

A minimal valid Zombies section:

"Zombies": {
  "Spawn_Chance": 0.5,
  "Damage_Multiplier": 1.0,
  "Armor_Multiplier": 1.0
}

A more complete example illustrating the mix of types:

"Zombies": {
  "Spawn_Chance": 0.7,
  "Loot_Chance": 0.5,
  "Sprinter_Chance": 0.1,
  "Flanker_Chance": 0.05,
  "Boss_Electric_Chance": 0.01,
  "Respawn_Day_Time": 180.0,
  "Respawn_Night_Time": 90.0,
  "Respawn_Beacon_Time": 30.0,
  "Damage_Multiplier": 1.5,
  "Armor_Multiplier": 0.8,
  "Backstab_Multiplier": 2.0,
  "NonHeadshot_Armor_Multiplier": 0.5,
  "Min_Drops": 0,
  "Max_Drops": 2,
  "Min_Mega_Drops": 1,
  "Max_Mega_Drops": 3,
  "Min_Boss_Drops": 2,
  "Max_Boss_Drops": 5,
  "Slow_Movement": false,
  "Can_Stun": true,
  "Only_Critical_Stuns": false,
  "Weapons_Use_Player_Damage": false,
  "Can_Target_Barricades": true,
  "Can_Target_Structures": false,
  "Can_Target_Vehicles": false,
  "Can_Target_Objects": false,
  "Beacon_Max_Rewards": 20,
  "Beacon_Max_Participants": 10,
  "Beacon_Rewards_Multiplier": 2.0,
  "Beacon_Experience_Multiplier": 1.5,
  "Full_Moon_Experience_Multiplier": 2.0
}

The example above is a survival-server configuration: moderate spawn density, occasional sprinters and flankers for variety, rare electric bosses, slightly elevated damage, slightly increased zombie durability, backstab bonus rewards positioning, headshots preferred but body shots functional, standard drops modest but mega and boss kills reliably rewarding, structures and vehicles safe, barricades consumable, beacon events capped at 10 participants and 20 items with double rewards.