Waarom de aanvalster sneller regrowt: troepenerherstel na het eerste contact

Direct antwoord. De aanvalster regrowt sneller, omdat diegene zijn balk in het vlakke 30-55%-plateau spendeert en hem laat herstellen aan de steile linkerkant van de regen-curve, terwijl een verdediger die zijn balk naar bijna nul leegspuit, de basis van zijn eigen herstelformule laat instorten. Je refill per tick is (10 + troops^0.73 / 4) × (1 − troops / max): die piekt bij ongeveer 42% van je cap en loopt daarna af tot nul bij de cap. Een balk die bijna vol of bijna leeg staat, refilt beide langzaam; een balk die door het midden cycled, refilt snel. De fix van v0.34.24 verwijderde ook een oude exploit waarbij je, door aanvallen te spammen op een doel dat je in werkelijkheid niet aaneengrenstde, je regen vast kon zetten op het piekniveau en troepen terugkreeg boven de cap, dus het verschil dat je nu ziet is pacing en capgrootte, en geen verborgen bonus voor aanvallers.

Waarom de regrow in de eerste plaats asymmetrisch aanvoelt

De meest voorkomende reden dat de balk van de ene speler sneller klimt dan die van jou, is geen bonus aan de kant van de aanvalster — het is een handicap aan de kant van de verdediger, en die is door de verdediger zelf opgelegd. De engine voegt elke tick troepen toe aan elke levende speler met één gedeelde functie, en die functie heeft precies twee onderdelen: een basisterm en een aftelop-term. De basisterm, 10 + troops^0.73 / 4, groeit naarmate je balk vult: hoe meer troepen je vasthoudt, hoe groter het getal is dat de engine gaat optellen. De exponent 0.73 zorgt dat de groei sublineair verloopt, dus de marginale opbrengst van elke extra troep wordt kleiner, maar de richting is eenduidig — een balk met meer troepen heeft een grotere basis dan een balk met minder. Voer de twee termen door op twee concrete vulniveaus tegen een cap van 100.000 troepen om het te zien: bij 20.000 troepen is alleen de basisterm al ongeveer 10 + 20000^0.73 / 4 ≈ 355, terwijl bij 60.000 troepen de basis ongeveer 10 + 60000^0.73 / 4 ≈ 779 is. De balk die drie keer zoveel troepen vasthoudt, draagt meer dan dubbel zoveel basis. De aftelop-term, (1 − troops / max), doet het tegenovergestelde: hoe dichter je bij je cap zit, hoe kleiner die wordt, en bij de cap zelf bereikt die exact nul. Bij 20.000 van de 100.000 troepen is de aftelop 0,8; bij 60.000 is het 0,4; bij 90.000 is het maar 0,1.

Vermenigvuldig die twee termen en je hebt het volledige gedrag, en de onderstaande getallen zijn de exacte per-tick waarden die de engine zou optellen bij elk vulniveau op een cap van 100.000 troepen, zonder bot-vermenigvuldiger (0,5) of Nation-vermenigvuldiger (0,9/0,95/1,0/1,05 per moeilijkheidsgraad) toegepast. Bij een laag vulniveau is de basis klein maar de aftelop bijna één, dus het product is matig: bij 20.000 troepen is dat grofweg 355 × 0,8 ≈ 284 troepen per tick. Naarmate je het midden invult, groeit de basis sneller dan de aftelop krimpt, en klimt het product naar zijn piek van ongeveer 350 bij ongeveer 42% van de cap. Na de piek blijft de aftelop krimpen terwijl de basis maar traag doorgroeit, dus het product daalt: bij 60.000 is het ongeveer 312, bij 80.000 ongeveer 192, bij 90.000 ongeveer 104, en bij een volle balk exact nul. Het praktische gevolg is dat het midden van de balk is waar de engine je de meeste troepen per tick geeft, en de twee uiteinden waar hij je de minste geeft. Als je buur constant door het midden van de balk cycled en jij je balk constant naar de bodem leegt voordat je herstelt, zal je hem altijd sneller refillen zien, omdat de curve hem simpelweg beter betaalt. Daarom leest de asymmetrie als “de aanvalster is sneller”: de aanvalster is degene die zojuist in het plateau heeft gespendeerd, en de verdediger is degene die op de vloer of op het plafond zit. Het is geen waarnemingsprobleem; het is de letterlijke rekenkunde van de formule, en de rest van deze gids gaat over hoe je je eigen balk op het betere deel van die curve houdt zodat de asymmetrie niet langer eenzijdig is, want dezelfde functie die eruitziet alsof hij de aanvalster bevoordeelt, beloont in werkelijkheid welke kant ook die kiest om in het midden te blijven.

De cijfers: waar de piek precies zit en waarom het band zo vlak is

De piek van troops^0.73 × (1 − troops / max) valt op troops / max = 0.73 / 1.73 ≈ 0.4219, dus het vulniveau met de theoretisch maximale snelheid zit op ongeveer 42,2% van je cap. Dat is het getal dat de community voortdurend afroundt naar “40%” of “iets minder dan de helft”, en het is het hart van het hele pacing-spel: houd de balk hier en je vult zo snel bij als de engine toelaat. Wat nuttiger is dan de exacte piek, is de vorm eromheen, want de curve is vlak over het hele midden en steil aan beide uiteinden. Voor een menselijke speler zonder steden ziet de per-tick waarde, relatief op die piek van 350 per tick, er op een cap van 100.000 troepen zo uit:

Twee dingen vallen op, en beide veranderen hoe je een push moet timen. Ten eerste zit je tussen grofweg 30% en 55% allemaal binnen ongeveer vijf procent van de piek, dus kleine timingfouten binnen dat band kosten je bijna niets: je kunt pushen op 35%, vasthouden op 45%, of weer engageren op 52% en dan exact hetzelfde regrow-werk doen, want de engine kan het verschil niet goed genoeg zien om het uit te maken. Die vlakheid is waarom het spel rond de 40% “vergevingsgezind” aanvoelt: je opereert op een breed, nagenoeg vlak plateau in plaats van op een mespunt, en een paar ticks onzekerheid over precies wanneer je te commiten hebt, worden door de curve opgevangen. Het band is niet symmetrisch — na de 55% begint het af te vallen, en bij 60% ben je neergekomen op ongeveer 89% van de piek. Het tweede, scherpere feit is dat de ineenstorting helemaal bovenaan abrupt is: de daling van 70% naar 90% gaat van driekwart van de piek naar net een derde, en de allerlaatste tick richting de cap voegt exact niets toe. Je grootste timingfout is niet te vroeg pushen — het is de balk opslaan tot 95% of 100% en te ontdekken dat de volgende golf ver weg is, terwijl een buur door het midden cycled. Het 30-55% plateau is de werkzone van deze gids: houd de balk erin en je bent, voor alle praktische pacing-doeleinden, op de beste snelheid van de engine. Als je één regel uit deze tabel wilt afleiden, dan is het deze: de kosten van een beetje van de piek af zitten in het midden een afrondingsfout, terwijl de kosten van naar een van de uiteinden drijven een echt, compoundend verlies aan troepen zijn, elke tick opnieuw, en dat verlies is precies de hele begroting waar de rest van deze gids over gaat.

Capgrootte bepaalt je absolute regrow-snelheid

Hetzelfde vulpercentage is niet dezelfde herstelsnelheid op elke kaart, want de cap is een functie van je gebied én van steden. De cap voor een mens is 2 × (tiles^0.6 × 1000 + 50000) plus 250.000 per afgerust stadsniveau, en bots draaien op een derde van hun cap. Werk een paar concrete gevallen uit zonder steden, zodat de schaling niet abstract blijft: bij 1 tegel is de cap ongeveer 102.000; bij 100 tegels ongeveer 132.000; bij 1.000 tegels ongeveer 226.000; bij 4.000 tegels ongeveer 390.000; en bij 10.000 tegels ongeveer 602.000. De macht 0.6 op het tegelaantal betekent dat de bijdrage van tegels sublineair groeit — verdubbelen van je tegels verdubbelt je cap niet — dus in het vroege spel komt het grootste deel van de hefboom van de vlakke 50.000-basisterm, en de echte sprong komt van steden: elk afgerust stadsniveau voegt een vlakke 250.000 toe, wat bij een middelgrote kern groter is dan de hele tegelbijdrage bij elkaar. Daardoor verschuift één vroege stad de hele regrow-berekening meer dan hoeveel zorgvuldig tegelwerk je eromheen ook doet.

Dit is de stille bron van het gevoel “zij hebben simpelweg meer troepen dan ik”, en het is de reden dat een speler die in het begin een paar extra steden pakte, meetbaar sneller regrowt dan een speler die dat niet deed. Als jij de grotere van twee buren bent, is je absolute winst per tick tijdens het regrowen groter, dus de balk een beetje lager houden vóór een beslissende push kost je meer — je moet het regrow-venster zwaarder wegen en eerder weer engageren, in plaats van een grotere balk onbenut te laten liggen, want elke onbenutte tick is een groter aantal troepen dat je grotere cap je terugkoopt. Als jij de kleinere buur bent, is je absolute winst per tick kleiner, dus de stap “wacht tot de balk is geregrown” is in absolute troepen minder waard, en je kunt de volgende beschikbare golf eerder commiten zonder zo veel op te geven. De percentage-regel blijft in beide gevallen hetzelfde; wat met de grootte verandert, is hoeveel absolute waarde er aan beide kanten van de push-en-vasthouden-beslissing staat, en hoeveel een stadsniveau de hele berekening verschuift. Als jullie allebei steden hebben, heeft de speler met het hogere niveau een grotere cap en dus een grotere absolute regrow, en daardoor is een vroege stad een pacing-voordeel evenzeer als een troepenaantals-voordeel: hij geeft je niet alleen meer troepen om uit te geven, hij zorgt dat elke tick herstel die je kiest te wachten een groter getal teruggeeft. De population growth guide heeft de cap-formule en de stedenbonus in volle omvang in huis; deze pagina gebruikt die cap alleen om uit te leggen waarom dezelfde 42% anders voelt op een kleine kern dan op een grote, en waarom “zelfde percentage, andere snelheid” het juiste mentale model is voor twee buren van ongelijke grootte, en geen teken dat een van jullie een verborgen bonus of een verborgen straf heeft op de regrowsnelheid zelf.

Scenario A: het tweezijdige drukvenster

Jij houdt 4.000 tegels in een FFA-middenspel met een cap van ongeveer 390.000, en twee buren breiden zich op jou uit vanuit het oosten en het westen. Je balk zit op 46%, grofweg 180.000 troepen, dat is net voorbij de 42% piek, dus je winst per tick zit feitelijk op het maximum van het plateau — je vult zo snel bij als de engine je nu toelaat, op ongeveer 99% van je theoretische beste niveau, en elke extra tick vasthouden voegt een bijna volledige tick aan troepen toe. De oostelijke buur toont een balk op 70% en duwt zichtbaar door; de westelijke buur zit op 30% en lijkt zijn kern te consolideren in plaats van te commiten. De beslissing is of je nu een preventieve push lanceert op de zachte westelijke flank, of je de balk een paar ticks laat regrowen en later harder inslaat. De rekenkunde die dit een echte keuze maakt in plaats van een gok, is het verschil tussen vasthouden en spenderen op precies deze twee vulniveaus: op 46% zit je op het plateau, dus een paar ticks vasthouden kopen je een bijna volledige tick aan troepen per seconde, maar je staat met één harde push op een stap van de vloer, en dat is het risico van de optie “wacht nog een beetje” terwijl een zacht doel al voor je ligt.

Aannames: geen kernwapens op het veld, geen steden in aanbouw, beide buren menselijk, en de westelijke buur zal niet binnen de komende paar ticks op jou aanvallen. Als je op 46% naar het westen push, commit je grofweg 45-50% van de balk, en de westelijke flank komt laag terecht (op de steile linkerkant) waar hij snel herstelt, en je spendeert het oostelijke drukvenster met regrowen in het midden. De oostelijke buur op 70% zit in de aftoppingszone, dus zijn absolute winst per tick is daadwerkelijk lager dan de jouwe op 46%, al staat zijn balk voller — op 70% voegt hij ongeveer 75% van zijn piek toe, terwijl jij op 46% ongeveer 99% van de jouwe toevoegt, en bij een vergelijkbare cap betekent dat dat jij de speler met de vollere uitziende balk uitregrowth. Dat is de tegenintuïtieve lezing: de speler met de vollere balk is niet altijd degene die het snelste regrowth, en dat is precies de fout die mensen doet denken dat de tegenstander een bonus heeft. De push op de 30% westelijke flank is hier de correcte zet, want jij zit op de piek van je eigen curve en het zachte doel zit in zijn eigen laag-regrow-herstelband. Als je in plaats daarvan vasthoudt en wacht tot je balk naar 80% klimt, glij je de aftopping in, valt je winst per tick ver onder de westerse buur die herstelende balk, en komt de trage maar wel doorgaande 70% balk van de oostelijke buur eerst bij je grens. De fallback-tak is ook relevant: als je vermoedt dat de oostelijke buur eerst slaat in plaats van door te duwen, geldt dezelfde logiek — je zit al op je piek, dus het regrow dat je met wachten wint is echt, maar alleen als het oosten de afstand niet dichtlegt; het moment dat de zachte westelijke flank weg is, is de “wacht”-optie niets meer waard. De regel: met een balk op piekpositie en een zacht laaggevuld doel beschikbaar, push nu, want de engine betaalt je precies nu de beste snelheid, niet een paar ticks later, en een herstelbare flank voor je neus is de goedkoopste push die je de hele dag zult krijgen.

Scenario B: de eindgame-overstrekval

Late in een gerangschikte 2v2 houdt je team een breed front en is je balk op 95% geduwd omdat je kleine aanvallen hebt opgevangen in plaats van te commiten. Je cap is 200.000, dus op 95% zit je op ongeveer 190.000 troepen en is de aftelop neergekomen op 0.05 — de engine voegt per tick slechts vijf procent van de basisterm toe, wat bij deze cap neerkomt op grofweg een paar honderd troepen per tick, het langzaamste deel van de hele curve en bijna niets in de context van een front van 200.000 troepen. Je wordt verleid om het allemaal in één beslissende push te gieten tegen de grotere vijandelijke lijn. De val: de push wint misschien de lijn, maar hij laat je hele front achter met een balk die de komende lange tijd bijna niets regrowth, en dat is precies het moment waarop de vijand — die troepen heeft opgeslagen in een middenreserve rond de 50% — op zijn eigen piek kan terugengageren en de dun geworden lijn platrolt. Concreet: als de vijand op 50% zit, is hij binnen een fractie van een procent van zijn piek en vult hij elke tick die hij wacht vol tempo bij, terwijl je balk na de push op de vloer nauwelijks refilt; het gat tussen je herstel en het van hen groeit elke enkele tick, dus een gewonnen gevechtje wordt een verloren front, al ging de directe vechtpartij in jouw voordeel.

De oplossing is het omgekeerde van het instinct: vóór een beslissende eindgame push, laat de balk bewust een paar ticks onder het 55%-markertje zitten, of commit de push in twee golven met een kort regrow-venster ertussen zodat elke golf het front binnen het 30-55% plateau laat in plaats van op de vloer. Als je golf één commit op 95% en de balk laat op, zeg, 30% staan, dan is die 30% balk terug op het plateau en vult snel bij, en is golf twee een paar ticks later sterker dan de volledige dump zou zijn geweest, want je spendeerde de eerste golf vanuit een volle balk en herstelde de tweede golf vanuit het midden. De winning overtime guide dekt de eindgame-tempo waarin dit scenario zit; deze pagina levert de specifieke regel dat een balk op 95% de slechtste plaats is om vanaf je grootste push te lanceren, want daar is je herstel per tick het dichtst bij nul en het van de vijand het dichtst bij het maximum, en die twee feiten samenlopen tot een situatie waarin je de ruil wint en de oorlog verliest in dezelfde zet. Dezelfde logiek geldt voor elk lang gevecht, niet alleen voor overtime: de speler die door het midden blijft cycelen houdt de tempo, en de speler die tot het plafond opslaat en dan naar de vloer dump, geeft de tempo aan de tegenstander. In een 2v2 kun je dit expliciet maken met je partner — spreek af dat geen van jullie onder de 30% dump op het gedeelde front, zodat de gecombineerde regrow van het front nooit instort terwijl de vijandelijke lijn in zijn eigen piek opslaat — en de discipline maakt van een kwetsbare one-shot een herhaalbaar ritme dat de vijand niet kan beantwoorden door op te slaan, want elke keer dat zij opslaan, is je middenplateau-balk al aan het herstellen en klaar om weer te commiten op jouw schema, niet op het van hen.

De faalmode en de tegenmaatregel

De faalmode die de klacht “zij regrowen altijd sneller dan ik” produceert, is naar bijna nul dumpen. Het moment dat je balk de nul nadert, instort de basisterm troops^0.73 / 4 mee, en blijft je over bijna niets per tick optellen. Een concrete vorm van dezelfde fout: vroeg in het spel houd je 2.500 troepen vast en win je grofweg een paar honderd per tick, maar als je onmiddellijk met alles aanvalt daal je naar een paar honderd troepen en valt de winst per tick naar een druppeltempo, dus de balk die zojuist nog groot voelde herstelt zich nu in een rompend tempo, terwijl de speler die een matige 30% stuurde en terug in het midden cycled, al weer op volle snelheid bijvult. De asymmetrie wordt in precies die ruil gecreëerd: jij zit op de vloer en voegt bijna niets per tick toe, en de andere speler zit in het midden en voegt een volledige tick aan troepen toe, dus over de volgende twintig ticks groeit het gat met duizenden troepen zonder een nieuwe aanval van welke kant dan ook. Dat is het gevoel “zij hebben gewoon meer”, geproduceerd door je eigen pacing, en het compoundt, omdat de speler op de vloer ook een kleinere basis heeft, dus de volgende keer dat ze proberen te herstellen beginnen ze weer vanaf een slechtere plek dan de speler die in het midden bleef.

De tegenmaatregel is pacing: stuur in het 30-40% bereik, stuur alleen wanneer je balk hersteld is in het plateau, en spendeer de balk nooit helemaal naar beneden vóór de volgende tick een kans heeft gehad om je terug te betalen. De verwante maar afzonderlijke faalmode is een volle balk vasthouden over een contact heen: je komt het gevecht binnen op 95% of hoger en herstelt daarom het langzaamst erna, waardoor je een overwinning omzet in een langzame bloeding, want de balk waarmee je won is nu de balk die als laatste bijvult. Beide falen zijn dezelfde fout vanuit tegenovergestelde uiteinden gezien — het verlaten van het 30-55% plateau — en de tegenmaatregel is dezelfde discipline: houd de balk door het midden cycelen, en laat de twee uiteinden korte doorreis-statussen zijn, geen ruststatussen. De troop bar attack timing guide is de per-tick timing-referentie waarnaar deze faalmode-sectie uitwijkt; hier is het punt de asymmetrie die pacing creëert tussen jou en de speler die niet paceert, en dat is een asymmetrie die je in de eerste paar seconden van een gevecht kunt voelen. Een nuttige zelfcheck na elke ruil is te vragen waar je balk is beland: als die in het 30-55% band landde, betaalde je de push bijna niets in toekomstig regrow, en als die op de vloer of het plafond landde, betaalde je het maximum. Train de gewoonte om de vulstand van de balk te lezen vóór je commit, niet erna, en het “aanvalster is sneller”-probleem verdwijnt grotendeels, want je stopt ermee de verdediger op de vloer te zijn en begin je de aanvalster in het midden te zijn — dezelfde rol waarvan je je tegenstander vroeger heimelijk beschuldigde, en een rol die, zodra je hem zelf overneemt, laat zien dat er nooit een verborgen bonus was, alleen de gewoonte van op het betere deel van de curve te blijven, die iedereen op kan pakken zodra ze gaan kijken naar hun eigen balk.

Wat de v0.34.24-refundfix verwijderde

Vóór v0.34.24 hield de aanvalcode een aanval met niets meer te veroveren vast tot de volgende tick in plaats van hem af te breken. De meegeleverde comment bij de v0.34.24-tag zegt zonder omschrijving wat een speler ermee kon doen: totdat de volgende tick, de troepen bleven de regen-stap zitten en kwamen gratis terug, dus zo’n aanval per tick hield de regen op zijn pieksnelheid en gaf troepen terug boven de cap. Met andere woorden: de aanvalsschuif spammen op een doel dat je in werkelijkheid niet aaneengrensde — of op een doel dat je al had omsingeld zodat de veroveringswachtrij leeg raakte — hield je regen vast op zijn piek en liet troepen boven de cap ophopen. Dat was een echt, meetbaar regrow-voordeel voor de speler die dat deed, en het is één van de echte redenen waarom de balk van een aanvalster kon lijken sneller bij te vullen dan die van een zorgvuldige verdediger: de verdediger paceerde correct, maar de aanvalster oogstte bovendien een gratis refill erbovenop, naast zijn goede pacing, dus het gat was niet alleen vaardigheid, het was een bug die de verdediger niet kon zien vanuit zijn kant van de kaart.

v0.34.24 sloot dat: AttackExecution trekt nu onmiddellijk terug zodra de veroveringswachtrij leeg is, dus de tot-de-volgende-tick-houden truc werkt niet meer en de refund is weg. De grens die voor deze gids geldt, is precies: de pacing- en capgrootte-asymmetrie die hierboven wordt beschreven is stabiel over deze versies, maar de refund-exploit is specifiek voor v0.34.24. Als je een oudere match terugspelt waarin de balk van een tegenstander onmogelijk snel leek te regrowen tegen een omsingeld doel, dan is dat de exploit en geen pacing-verschil, en geen hoeveelheid van je eigen pacing zou het gat hebben kunnen dichten. Op huidige v0.34.24 en latere versies betekent een lege veroveringswachtrij een onmiddellijke terugtocht, en een terugtocht kost 25% van de aanvallende troepen (malusForRetreat = 25), dus aanvallen spammen is nu een netto kostenpost en geen regrow-truc: elke onjuiste aanval die je vuurt verovert niet alleen niet, hij verbrandt ook een kwart van de troepen die je committeerde. Dat verandert de lezing van een agressieve tegenstander — als diegene de schuif spamt zonder echt front, dan bloeden ze nu 25% per verspilde aanval, en dat is een teken van wanhoop of een misklik, geen verborgen regrow-bron. De praktische regel voor jou is om te stoppen met “zij moeten sneller regrowen” als verklaring aan te nemen voor de getallen van een tegenstander: op de huidige versies zijn de enige regrow-ingangen pacing (waar op de curve) en cap (hoe groot), en de refund-hefboom is weg. Controleer het aanvalsbouw-pad na elke release die het raakt, want daar woont de fix, en als een toekomstige release een pad opnieuw introduceert om leeg vast te houden, komt het refund-voordeel met terug — maar op de versies waarop je nu speelt is de refund geen factor, en elke regrow-voordeel die je ziet is de pacing- en cap-rekenkunde die deze gids al heeft uiteengezet, wat betekent dat het volledig leesbaar is en volledig matchbaar is vanuit je eigen kant van het bord.

Mode- en kaartaanpassingen

De plateaugregel is modus-onafhankelijk, maar de getallen die hem belangrijk maken verschuiven, dus dezelfde 30-55% richtlijn landt anders afhankelijk van waar en hoe je speelt. In FFA is de relevante variabele je cap ten opzichte van je twee dichtstbijzijnde buren, want elke buur is een potentieel doel en de zachte flank is altijd beschikbaar; houd de balk in het 30-55% plateau en push op welke buur ook die in zijn eigen laag-regrow-herstelband zit. FFA heeft ook geen teamgenoot waarmee je een gedeeld front kunt coördineren, dus de discipline “dump het gedeelde front niet” uit het 2v2-geval geldt hier niet — in plaats daarvan is je hele balk van jezelf om te cycelen, en de faalmode is dat je je enige balk naar de vloer dump in een mislukte preventieve slag zonder back-up die komt. De regel voor FFA is om minimaal één golf aan regrow-ruimte te behouden: laat de balk nooit onder het 30% band zakken tenzij je een specifieke reden hebt, want zonder partner die het front dekt, is een op de vloer liggende balk een onherstelbaar venster waarin het regrow van elke buur een dreiging is en je eigen het slechtste, en dat is de slechtst denkbare combinatie om in vast te zitten wanneer drie buren allemaal naar dezelfde open ruimte kijken die je zojuist hebt verlaten.

In gerangschikte 2v2 is de variabele de teambrede pacing: het front dat als eerste naar nul dump, is het front dat bloedt, dus coördineer met je partner om in golven te commiten die beide balken in het plateau laten in plaats van dat één kant alles in één keer dump. De concrete vorm van die regel is af te spreken op een gedeelde vloer — zeg 30% — onder welke geen van jullie op het gedeelde front commit, zodat de gecombineerde regrow van het front nooit instort terwijl de vijandelijke lijn in zijn eigen piek opslaat. Op kaarten met veel vroege steden groeit de cap sneller, dus de absolute per-tick regrow is groter en de stap “wacht een paar ticks” is meer waard — houd de balk een tikkeltje lager vóór grote pushes, want elke tick vasthouden koopt meer absolute troepen dan op een kale kaart, en de door steden gedreven cap-sprong betekent dat je plateau op een hoger absoluut getal zit dan dat van je tegenstanders die geen steden opsloten. Op kaarten met schaarse steden en trage gebiedswinst is de cap klein en het regrow-venster kort, dus kun je eerder weer engageren en de balk een tikkeltje hoger houden, want de absolute waarde van een vastgehouden tick is lager en de vijand schaleert zijn cap niet op dezelfde manier als jij. De ranked 2v2 guide en de winning overtime guide hebben de tempo in huis waarnaar deze aanpassingen voeden; deze pagina levert alleen het regrow-snelheidsdeel van die tempo, en dat is het deel dat de meeste spelers voelen maar niet kunnen kwantificeren, en het deel dat, zodra gekwantificeerd, het verschil is tussen een front dat houdt en een front dat bloedt, want een front dat houdt is een front waarvan de gecombineerde balk op schema door het midden cycelt terwijl het vijandelijke front gedwongen is zijn eigen opslag én zijn eigen vloer tegelijk te bekijken.

Het geheel: een besluitlijst

Vóór elke push draai je vier checks door, en de volgorde telt, want elke check bepaalt of de volgende mag doorgaan. Eerst: waar zit je balk? Als die in het 30-55% plateau zit, ben je op de beste snelheid van de engine en is de push-en-regrow-cyclus goedkoop — de tick die je opgeeft om te commiten, is de tick die de curve je bijna op piek terugbetaalt, dus de push is goedkoop en het herstel erna snel. Als die boven de 70% of onder de 20% zit, ben je op een langzame rand en je moet eerst herstellen of een langzamer refill daarna accepteren; op 95% is het opgeven van de refill bijna gratis maar het terugwinnen ervan bijna onmogelijk, en op de vloer is het bijvullen het slechtste van de hele curve, dus die twee vulniveaus moet je vermijden om vanaf te commiten, want commiten vanaf hen betekent uitgeven vanuit een balk die al op het langzaamste deel van zijn eigen herstel zit. Tweede: waar zit de balk van het doel? Een zachte flank in zijn eigen laaggevulde herstelband is nu een goedkope push, want je raakt een balk die al snel bijvult en je niet zal uitregrowen in het venster; een doel dat op een volle balk zit, is een waar je eerst moet laten afspelen, want een volle balk raken betekent vechten tegen een lijn die zojuist committeerde en op het langzaamste deel van zijn eigen herstel zit, en dat is het tegenovergestelde van wat je in een lang gevecht wilt.

Derde: wat is het cap-verschil? Als jij de grotere buur bent, wegen het regrow-venster zwaarder omdat je absolute winst per tick groter is, dus elke vastgehouden tick is meer waard en je moet eerder weer engageren; als jij de kleinere bent, engageer eerder omdat je absolute winst kleiner is en een vastgehouden tick in absolute troepen minder waard is. Vierde: is de veroveringswachtrij echt? Op v0.34.24 en later trekt een aanval met niets te veroveren onmiddellijk terug en kost 25% van de troepen, dus spam de schuif nooit als regrow-truc — die hefboom bestaat niet meer, en op de huidige versies is het strikt een verlies dat ook je wanhoop aan elke kijkende buur adverteert. Werk de vier checks samen op één push: je balk op 45% (plateau, goedkoop), een westelijke flank op 30% (zacht, herstellend), jij de grotere van de twee buren (weeg het venster, engageer snel), en een echt front om te veroveren (geen valse aanval). Elke check wijst dezelfde kant — push nu op de westelijke flank en engageer snel — dus de push is de zet, en de vier-checks-routine is de gewoonte die je erop houdt de dump-naar-nul- en oplaag-tot-vol-fouten niet op impuls te maken. De discipline die het geheel werkend houdt is dezelfde herhaalde zin: houd de balk door het midden cycelen, push op zachte laaggevulde flanken, houd de balk lager vóór grote pushes als je cap groot is, en engageer eerder als hij klein is. De asymmetrie is geen bonus voor aanvallers; het is de prijs van een verdediger die het plateau verlaat, en het is volledig onder jouw controle. Als je je eigen balk op het betere deel van de curve houdt, stopt het “aanvalster is sneller”-probleem met een mysterie te zijn en wordt het een keuze die je maakt, niet een feit dat je overkomt, en het regrow dat je vroeger de tegenstander genieten zag, wordt het regrow dat jij zelf produceert, op jouw schema, zonder verborgen ingangen en zonder versiespecifieke trucs die nog te vinden zijn.