OpenFront – Goud doneren in de match: wanneer goud in plaats van troepen sturen

Rechtstreeks antwoord: goud aan een levende bondgenoot die het kan uitgeven, troepen aan een die het kan vasthouden

Doneer goud aan een vriendelijk teamlid wanneer dat teamlid in leven is, een mens is en binnen de komende seconden een specifiek iets met het goud kan kopen — een uitbreiding, een Stad, een Fabriek, een Haven, of de arbeiders die hun inkomsten stroom laten. Doneer troepen wanneer het teamlid een grens verliest en lichamen nodig heeft, geen geld. De twee acties delen hetzelfde radiale menu en dezelfde 10-secondencooldown per doel, maar ze lossen verschillende problemen op. De kernbeslissing is welk teamlid en welke bron, niet of je überhaupt iets geeft. Als je de aankoop die het goud moet financieren kunt noemen, stuur goud; als je die niet kunt noemen en het teamlid bloedt, stuur dan troepen. Een teamlid dat al dood is, een bot, of een vijand kan niets van beide ontvangen, dus het menu-item is uitgeschakeld en de vraag doet zich nooit voor. De 10/25/50/75/100-voorstellen bestaan zodat je in één oogopslag het aandeel van je eigen balans kiest, wat belangrijker is dan het exacte getal.

De reden dat dit is opgevat als een beslissing over wie en wat in plaats van hoeveel, is dat het getal het makkelijke deel is en het doel het dure deel. Een perfecte 50%-gouddonatie aan het verkeerde teamlid is minder waard dan een slordige 25% aan het juiste, want het goud rendert alleen als de ontvanger binnen de komende seconden een specifieke aankoop ermee kan maken. Als je die aankoop niet kunt noemen, is de donatie meestal een geschenk aan de vijand, want de ontvanger kan het niet snel genoeg uitgeven of sterft voordat de inkomsten die het zou moeten kopen er zijn. De hele gids draait om dat ene idee: een gouddonatie is een inzet op de volgende zet van de ontvanger, en een troependonatie is een inzet op zijn volgende tien seconden. Win de inzet en het voorstel doet nauwelijks iets; mis de inzet en zelfs de 100%-knop versnelt alleen het verlies.

Dit is ook waarom de twee knoppen als verschillende vragen moeten voelen, niet als dezelfde knop met twee labels. Als je het radiale menu op een bondgenoot opent, stel jezelf eerst de troepenvraag: staat deze persoon binnen de komende tien seconden op het punt dood te worden? Als ja, dan troepen, en de goudvraag wordt niet gesteld. Alleen wanneer het antwoord nee is, stel je de goudvraag: heeft deze persoon een genoemde aankoop die mijn goud binnen de komende seconden zou financieren? Als beide antwoorden nee zijn, is de juiste zet meestal niets sturen en je balans liquide houden, want een donatie zonder doelaankoop is gewoon je eigen uitbreiding die vertraagt met de naam van een vreemde erop. De community-thread die vraagt “waarom hoorden teamleden aan” beschrijft bijna altijd precies dit ontbreken van een genoemde aankoop, niet hebzucht, en de oplossing is de aankoop expliciet te maken voordat je het voorstel aanraakt.

Waar de actie zit en waarom zoveel spelers hem missen

Beide donaties zitten in het radiale menu dat opent als je een andere speler selecteert. Er zijn twee items, donate gold en donate troops, elk getoond in de bondgenootskleur en elk uitgeschakeld telkenmale dat de onderliggende canDonateGold / canDonateTroops-check false is. Als je erop tikt, opent het gedeelde send-resource modaal, dat je levende bondgenoten toont, je huidige goud- of troepenbalans als basis toont, en de 10 / 25 / 50 / 75 / 100 % voorstellen biedt plus een fijne slider voor een exact cijfer. Hier begint het community-probleem: meerdere Reddit-threads beschrijven spelers die “een paar minuten van paniekerig zoeken nodig hadden om uit te vinden hoe je geld of troepen stuurt”, omdat de actie verstopt zit achter het informatiepaneel van de speler in plaats van een hotkey, en minstens één speler “een video moest bekijken voordat ik wist dat het überhaupt een optie was”. De oplossing is het radiale menu een reflex te maken: selecteer een levende bondgenoot, open het radiale menu, kies de bron, kies een voorstel, bevestig. Omdat de voorstellen percentages zijn van jouw balans, verplaatst dezelfde 50%-knop in minuut drie een ander bedrag dan in minuut twaalf, dus je kiest in feite “de helft van wat ik nu heb”, wat het eerlijke mentale model is.

Noem het waard, omdat het verandert hoe je oefent: het modaal toont je huidige balans als basis, en de voorstellen berekenen opnieuw vanuit die basis elke keer dat je het opent, dus er is geen verborgen “laatste bedrag”-status om te onthouden. De slider is voor het zeldzame moment dat je een exact cijfer wilt — meestal wanneer je de prijs kent van de bouw die de ontvanger in de wachtrij zet en je die wilt matchen in plaats van af te ronden naar een voorstel. In een snelle teamgame zul je bijna altijd de 25% of 50% voorstellen kiezen en verder gaan, wat precies is waarom de feature in het werk is: het comprimeert een vierstapsberekening (balans, prijs, aandeel, bevestig) naar één oogopslag en één tik. De spelers die het missen, missen het niet omdat het moeilijk te gebruiken is zodra je het gevonden hebt; ze missen het omdat het niet is waar hun aandacht al is. Dat is een gewoonteprobleem, niet een UI-bug, en de praktische oplossing is de reflex op te bouwen tijdens de kalme openingsminuten — stuur een 10%-goudvoorstel naar een teamlid dat duidelijk ruimte heeft — zodat de actie al spiergeheugen is in plaats van een zoektocht tegen de tijd dat de frontlinie breekt.

De regels die een donatie pas mogelijk maken

Voordat er sprake is van besluitvorming, afdwingt de engine vier harde poorten, allemaal in canDonateGold en canDonateTroops in PlayerImpl. Alleen mens-naar-mens: het configuratiecommentaar is expliciet dat donaties zijn ingesteld voor mensen alleen, dus een mens kan niet doneren aan een bot en een bot’s donatie verplaatst zich niet; bots starten ook bij nul goud, dus er is niets te ontvangen. Beide levend: het modaal berekent zijn basis als nul in het moment dat de zender of het doel dood is, en de voorstellen grijsen uit. Vriendelijk doel: de ontvanger moet je team delen of verbonden zijn; je kunt niet doneren over een vijandige grens. Cooldown per doel: elk (donor, ontvanger)-paar houdt een eigen 100-tik-timer voor goud en een aparte voor troepen, dus na goud te hebben gegeven aan de frontlinie-anker kun je onmiddellijk goud geven aan een tweede feed — de cooldown is per ontvanger, niet globaal. Het spel draait op tien ticks per seconde, dus 100 ticks is exact tien seconden. Deze poorten zijn niet optioneel en niet modus-afhankelijk zoals sommige schakelaars zijn; ze zijn de vorm van de feature, en ze begrijpen vertelt je precies wanneer de knop grijs is en waarom.

De meest misleiderijke is de cooldown-per-doel, omdat het instinct zegt dat je na een donatie tien seconden moet wachten, maar de waarheid is dat je tien seconden moet wachten per ontvanger. Als je twee feeders hebt die beide een bouw nodig hebben, kun je goud aan de eerste geven, en in de volgende tik goud aan de tweede, en beide donaties tellen hun eigen klok. Dat is een enorme versnelling in een teamgame, en het is de reden waarom de community-thread die vraagt “hoe stuur ik geld aan twee mensen tegelijk” eigenlijk een misverstand is over de cooldown: je kunt het niet letterlijk tegelijk doen, maar je kunt het zo snel doen dat het erop lijkt. De praktijk is: identificeer de twee of drie teamleden die nu een genoemde aankoop hebben, en geef ze in een korte rij de goudvoorstel, elke met zijn eigen tien-seconden-raster dat parallel met de anderen draait.

Wanneer het radiale menuitem voor een bepaalde speler grijs is, is de oorzaak bijna altijd een van deze vier poorten, en ze in de volgorde controleren — levend, vriendelijk, mens, cooldown — duurt minder dan een seconde en bespaart je de frustratie van een klik die niets doet. De volgorde is belangrijk omdat de eerste drie het doel uitsluiten (als het doel dood, vijandig of een bot is, is er niets te geven en de vraag eindigt daar), terwijl de laatste alleen bepaalt wanneer je kunt geven, niet of. Die onderscheid is de hele feature: de eerste drie poorten zijn absolute en de cooldown is tijdelijk, dus een grijs item dat over tien seconden terugkomt is een teken van “wacht en geef”, terwijl een grijs item dat nooit terugkomt een teken is van “dit doel kan niet ontvangen” en je aandacht verdient om ergens anders te leggen.

Het beslissingskader: wie krijgt goud en wie krijgt troepen

Het kader is twee vragen in strikte volgorde, en de volgorde is het punt. Vraag één, altijd eerst, is de troepenvraag: staat dit teamlid binnen de komende tien seconden op het punt te vallen? Als ja, stuur troepen en stop — de goudvraag wordt niet gesteld, want goud dat je nu stuurt naar een teamlid dat doodgaat in tien seconden is geld dat je aan de vijand geeft, omdat de ontvanger het niet kan uitgeven vóórdat hij valt. Vraag twee, alleen als vraag één nee is, is de goudvraag: heeft dit teamlid een genoemde aankoop die mijn goud binnen de komende seconden zou financieren? Als ja, stuur goud met een voorstel dat de prijs dekt; als nee, stuur niets en houd je balans liquide.

De reden dat de volgorde strikt is, is dat goud en troepen op verschillende tijdschalen werken. Troepen kopen de komende tien seconden — ze verschijnen onmiddellijk en verdedigen de grens nu. Goud koopt het inkomen van de komende minuut — het moet door de ontvanger worden omgezet in een bouw, die pas in de volgende rotaties draait. Een teamlid dat nu valt, heeft geen tijd om goud om te zetten, dus goud is daar nutteloos; een teamlid dat veilig is maar geblokkeerd, heeft geen need voor meer lichamen, dus troepen zijn daar verspilling. Het kader dwingt je om het tijdsframe van de bron te matchen met de urgenty van het probleem, en dat is de hele beslissing op één regel.

De tabel is de versnelling van het kader: in het moment dat je het radiale menu opent, scan je de vijf rijen en kies je de rij die past. De meest gewone rij is “veilig, genoemde bouw”, omdat dat de situatie is waarin een teamlid het meest waarde uit je goud haalt. De tweede meest gewone is “veilig, geen genoemde bouw”, en het juiste antwoord daar — niets sturen — is precies wat de community-thread die “waarom hoorden teamleden aan” beschrijft: de spelers die niets sturen zijn niet gierig, ze ontbreken een genoemde aankoop, en de oplossing is de aankoop te maken voordat je het menu opent, niet het menu te forceren.

De cijfers die het oordeel vormen: cooldown, voorstellen en onbeperkt goud

Drie cijfers vormen de beslissing, en ze zijn allemaal direct uit de bron van de v34 tag af te leiden. De cooldown is 100 ticks, en omdat het spel op tien ticks per seconde draait, is dat exact tien seconden per (donor, ontvanger)-paar, met een aparte timer voor goud en troepen. De voorstellen zijn 10 / 25 / 50 / 75 / 100 % van jouw huidige balans, geen vaste bedragen, en er is een slider voor een exact cijfer als je de prijs van de bouw die de ontvanger in de wachtrij zet kent. En het derde, cruciale cijfer: goud heeft geen capaciteitslimiet op de ontvanger. Een goud donatie is onbeperkt — je kunt je volledige balans in één tik sturen, en de ontvanger neemt het allemaal aan — terwijl troepen donaties wél capaciteitsbeperkt zijn.

Dat laatste punt is de hele beslissingsverdeling. Goud is de flexibele bron: je kunt een klein bedrag sturen om een specifieke bouw te dekken, of je volledige balans om een teamlid dat achterloopt te laten inhalen, en er is geen “vol”-status op de ontvanger die een tweede donatie blokkeert. Troepen zijn de capaciteitsbeperkte bron: ze worden begrensd door de eenheidslimiet van de ontvanger, dus je kunt niet oneindig troepen sturen en de overloop wordt verspild. In de praktijk betekent dat dat goud de bron is voor “ik wil dat je dit kunt kopen” en troepen de bron is voor “ik heb nu lichamen nodig op die grens”. De voorstellen bestaan zodat je het aandeel van je balans kiest in één oogopslag, en de onbeperkte natuur van goud betekent dat het 100%-voorstel een legitieme actie is — je volledige balans — in een teamgame waarin één teamlid de anker is en de feeders alles moeten overbrengen.

De tien-seconden-raster is de praktische grens. Je kunt niet vaker dan eens per tien seconden aan hetzelfde teamlid geven, dus als je een bouw financiert die twee donaties nodig heeft, moet je tien seconden wachten tussen de twee. Dat is een redelijke tijd in een teamgame, want de bouw die de ontvanger in de wachtrij zet, draait niet in de tien seconden dat je wacht, dus het wachten verbrandt geen inkomens. De slide voor een exact cijfer is voor het zeldzame moment dat je de prijs kent — bijvoorbeeld dat de volgende Stad de helft van je balans kost en je niet de rest wilt verspillen aan een bouw die de ontvanger niet kan gebruiken. De meesten van de tijd kies je 25% of 50% en ga je verder, wat de feature werkt in het werk: het comprimeert de berekening naar een tik.

Scenario A — de beschermde feeder die één stoomwals moet pompen

Stel je een teamgame op een grote kaart voor, minuut zes, en je teamlid aan de zuidelijke feeder is veilig, verdedigd door twee muren en een patrouillerende eenheid, en staat klaar om een Fabriek te kopen die zijn eenheidsproductie verdubbelt. De Fabriek kost de helft van jouw huidige balans. Dit is de situatie waarin goud de juiste bron is, en het kader werkt als volgt: troepenvraag nee (hij valt niet binnen tien seconden), goudvraag ja (de Fabriek is een genoemde aankoop), voorstel 50%, en je stuurt het. De Fabriek draait in de volgende rotaties, en de verdubbelde productie betekent dat hij in de volgende twee rotaties de eenheden kan leveren die je op de noordelijke grens nodig hebt, die nu leegloopt.

De aanname hier is dat de feeder beschermd is en dat de Fabriek de binding constraint is op zijn eenheidslevering. Als de feeder niet beschermd is — als er een vijandige eenheid op hem af komt — dan verandert het antwoord naar troepen, want de Fabriek die je financiert zal onmiddellijk worden aangevallen en je goud wordt verspild. De aanname van “beschermd” is daarom de poort voor dit scenario: controleer dat de feeder geen dreiging heeft binnen de komende tien seconden voordat je het 50%-voorstel aanraakt. De cijfers: 50% van jouw balans, tien seconden cooldown per doel, onbeperkte ontvanger-capaciteit, en de Fabriek die in de volgende rotaties draait. Het kader zegt goud; de situatie zegt goud; de twee komen overeen.

De reden dat dit scenario goud en niet troepen is, is de tijdsframe van de aankoop. De Fabriek draait pas in de volgende rotaties, en die rotaties zijn veilig zolang de feeder beschermd blijft. Als je in plaats daarvan troepen stuurt, versterk je een grens die geen dreiging heeft en verbrand je de eenheden die je op de noordelijke grens nodig hebt. Goud is de bron die de toekomstige inkomens koopt, en troepen zijn de bron die de huidige dreiging dekt; in dit scenario is er geen huidige dreiging, dus de bron die je nodig hebt is goud. Het 50%-voorstel is de keuze omdat het exact de prijs van de Fabriek dekt, en je wilt de resterende 50% liquide houden voor een eventuele noordergrens die later breekt. Het 50%-voorstel is dus de exacte dekking van de genoemde aankoop, en dat is de hele kracht van de voorstelsysteem: je hoeft niet de prijs van de bouw te kennen om de juiste bron te sturen, want het voorstel dekt het aandeel en de ontvanger dekt de rest. De combinatie van de tien-seconden-raster en het onbeperkte ontvanger betekent dat je deze donatie niet terug kunt trekken, dus de enige bescherming is de aanname van “beschermd” vóórdat je het voorstel aanraakt: als de feeder niet beschermd is, is het 50%-voorstel de reden waarom je later de noordelijke grens verliest, niet de reden waarom de Fabriek te laat draait. Controleer de dreiging, kies het voorstel, stuur, en laat de resterende balans in de hand voor de grens die echt breekt.

Scenario B — het teamlid op het punt van overweldiging: goud of troepen, snel

Nu dezelfde kaart, minuut zes, maar je teamlid aan de noordelijke grens wordt overweldigd door drie vijandige eenheden die binnen tien seconden zijn muren bereiken. De troepenvraag is ja, en dat is het hele antwoord: stuur troepen, niet goud. Goud dat je nu stuurt aan een teamlid dat in tien seconden valt, is geld dat je aan de vijand geeft, want hij kan het niet omzetten in een bouw vóórdat hij valt. De troepen verschijnen onmiddellijk en verdedigen de grens nu, en dat is de hele reden voor de strikte volgorde van het kader.

De aanname hier is dat de grens nu breekt en dat de ontvanger lichamen nodig heeft in plaats van inkomens. Als de dreiging weg is — als de drie eenheden al zijn neergeslagen en de grens veilig is — dan wissel je over naar het goudframe, want de ontvanger is nu “veilig, genoemde bouw” en de juiste bron is goud voor de reconstructie. De cijfers: troepen, capaciteitsbeperkt door de eenheidslimiet, verschijnen onmiddellijk, en de tien seconden dat de dreiging over is, is de tijd die je hebt om de bron te kiezen vóórdat de grens breekt. Het kader zegt troepen; de situatie zegt troepen; de twee komen overeen.

Het onderscheid tussen scenario A en B is de hele guide: dezelfde teamlid, dezelfde minuut, twee verschillende bronnen, bepaald door de tien-seconden-horizon. De tien seconden zijn de hele beslissing, en de reden dat het kader de troepenvraag eerst stelt, is dat de tien seconden de enige tijd zijn die je hebt om de bron te kiezen. Als je de goudvraag eerst stelt en de aanname is dat het teamlid veilig is, maar de drie eenheden bereiken zijn muren in tien seconden, dan heb je goud gestuurd naar een teamlid dat nu valt, en het goud wordt verspild. De troepenvraag eerst stellen is dus geen formaliteit; het is de bescherming tegen de meest kostbare fout in de feature, namelijk goud sturen naar een teamlid dat het niet kan uitgeven vóórdat het valt. De praktische consequentie is dat de tien seconden niet een abstracte tijd is maar de tijd die je hebt om de bron te kiezen: als je ze gebruikt om goud te sturen in plaats van troepen, verliest je de noordelijke grens, en de noordelijke grens is de grens die de Fabriek van de zuidelijke feeder beschermt. De feature is ontworpen om snel te werken — de voorstellen zijn er precies zodat je de bron in één tik kiest — en de tien seconden is de tijd die de feature geeft om die keuze te maken zonder de grens te verliezen.

Falen en de tegenmaatregel die elk ervan ongedaan maakt

De meest mislukte donatie is goud sturen naar een teamlid dat al verliest: je geeft 50% van je balans aan een teamlid dat doodgaat in twaalf seconden, en het goud dat je stuurt kan niet omgezet worden vóórdat hij valt. De tegenmaatregel is de strikte volgorde van het kader: stel de troepenvraag eerst, en als het antwoord ja is, stuur troepen en stop. Goud is de bron voor “veilig, genoemde bouw”, en een teamlid dat valt is niet veilig, dus het antwoord is troepen of niets, nooit goud.

De tweede falen is de cooldown per doel missen en denken dat je tien seconden moet wachten na elke donatie, terwijl de waarheid is dat je tien seconden per ontvanger wacht. Je hebt twee feeders die beide een bouw nodig hebben, en je geeft goud aan de eerste en wacht onnodig tien seconden voordat je aan de tweede geeft. De tegenmaatregel is het per-doel-raster te onthouden: identificeer de twee of drie teamleden met een genoemde aankoop en geef ze in een korte rij, elke met zijn eigen tien-seconden-timer die parallel draait.

De derde falen is een bot of een vijand proberen te helpen en het menu-item grijs vinden, wat de exacte moment verspil waar je op had moeten handelen. De tegenmaatregel is de mens-alleen-poort te onthouden: bots starten bij nul goud en alleen menselijke teamleden kunnen ontvangen, dus het doel van de donatie is altijd het menselijke teamlid dat het gebrek draagt, niet de bot die het vult.

De vierde falen is blind een voorstel kiezen omdat een teamlid “verliest”: het voorstel is een aandeel van jouw balans, niet een aandeel van het gebrek van de ontvanger, dus dezelfde 100%-balans is een reddingsschot voor een klein gebrek en een gebaar voor een groot. De tegenmaatregel is het gebrek in real time te schatten en ofwel het voorstel te kiezen dat het dekt, of een tweede na de cooldown te sturen als de eerste onvoldoende is.

De vijfde falen is de mens-alleen-grens mislezen in een drukke moment: je probeert een bot-teamlid te “helpen” en vindt de knop grijs, en de tien seconden dat je aan de knop staren, is de tien seconden waarin de grens breekt. De tegenmaatregel is de poort te controleren vóórdat je het menu opent — levend, vriendelijk, mens, cooldown — zodat je nooit de tijd verliest aan een klik die niets doet, en de tien seconden die je bespaart gebruikt om de grens zelf te verdedigen.

Modus- en kaartafstellingen

De beslissing is in elk geval dezelfde — het doelaankoop noemen of het gebrek noemen — maar de aankoop die de partij wint, verandert met de topologie, dus is kaartstrategie de referentie voor welke bouw op welke kaart de volgende is die een feeder kan inrijen. Op een kleine kaart die vroeg breekt, is de kritieke goud de Fabriek of de troepenstation die de rotatiecapaciteit van de anker verhoogt vóór de eerste golf; op een grote kaart is de kritieke goud vaak de Stad of de Haven die het inkomens van de achterlijn verhoogt, want de partij is lang genoeg dat het inkomens werkt. In een teamgame waarin één speler de anker wordt, is de kaartbeslissing waar de anker moet zitten, en de donatiebeslissing volgt daaruit: troepen naar de anker, goud naar elke feeder die zijn rotatie draagt.

Deze modusverandering is geen verschil in feature maar een verschil in welk teamlid de binding constraint is. De feature — tien seconden per doel, 10/25/50/75/100% voorstellen, mens-alleen, onbeperkt goud — is identiek in alle teammodi, en het kader is identiek. Wat verandert is de aankoop die de goud moet financieren, en die aankoop is kaartafhankelijk. De community-thread benadrukt precies deze kaartafhankelijkheid: dezelfde 50%-voorstel, naar het juiste teamlid op de juiste kaart gericht, redt de partij; naar het verkeerde, of naar de verkeerde kaart, vertraagt alleen de collapse.

Een concrete kaartvoorbeeld maakt het verschil zichtbaar. Op een grote kaart met een lange kustlijn is de Haven de bouw met de grootste inkomenshef in de tweede helft, want de kustroutes verminderen de eenheidsbeweging tussen de achterlijn en de grens; een feeder die de Haven kan inrijen vóórdat de vijand de kust controleert, verlaagt het troepenbehoefte van de hele rotatie en betekent dat je minder troepen hoeft te sturen om dezelfde grens te houden. Op een kleine kaart zonder kust is die logica fout, want de Fabriek en de troepenstation zijn de enige inkomenshebben, en een feeder die daar op de Haven wacht, vertraagt alleen wat de Fabriek onmiddellijk had gegeven.

De praktische regel is dus: bepaal de kaart vóórdat je het radiale menu opent, en dat betekent dat je de topologie hebt gezien — de kust, de muren, de afstand tot de achterlijn — voordat je de voorstel kiest. Die topologie bepaalt de bouw, en de bouw bepaalt het voorstel, en het kader bepaalt de bron. De kaartbeslissing is de context, niet het detail: ze verandert welke bouw de goud moet kopen, maar nooit de vier vragen van het kader, die op elke kaart identiek blijven. Die stabiliteit is precies wat de feature bruikbaar maakt: één set regels, tien seconden per doel, voorstellen van je balans, onbeperkt goud, die op elke kaart dezelfde beslissing opleveren als je de kaartcontext in het kader stuurt.

Wat deze gids niet dekt, en wat je verder moet lezen

Deze gids dekt de beslissing van de goud-donatie binnen een teammatch: wanneer goud sturen in plaats van troepen, welke voorstel te kiezen, en hoe de cooldown-per-doel werkt. Ze dekt niet de clan-tresoor-donaties, die een aparte feature is met een eigen mechanisme en eigen regels — als je wilt weten hoe je goud naar de clan-tresoor stuurt in plaats van naar een teamlid, is de gids over clan-tresoor-donaties de juiste bron, want die behandelt de tresoor-limiet, de clan-roster, en de verschillen tussen de twee donatiepaden. De feature die hier behandeld is — de radiale-menu-donatie aan een teamlid binnen een match — is onafhankelijk van de tresoor-donatie en werkt in elk teammatch, ongeacht of je in een clan zit.

De gids dekt ook niet de bredere team-economie, want die gaat over hoe de inkomens van een team verdeeld worden over de hele partij, niet over de tien-seconden-beslissing die hier centraal staat. Als je wilt begrijpen waarom je teamlid zijn inkomens hoort aan te houden in plaats van te besteden, of hoe de feeders de rotatie van de anker dragen, is de gids over team-economie en ruimte de juiste bron, want die behandelt de langere-termijn verdeling van goud en eenheden over de hele partij. Dezelfde voor de kaartstrategie: deze gids vertelt je welke bouw de goud moet kopen, maar niet waarom die bouw op die kaart de binding constraint is; de gids over kaartstrategie is de referentie voor de topologie, en deze gids is de referentie voor de donatiebeslissing die daarop draait.

De twee knoppen — goud en troepen — zijn de hele interface, en ze delen het radiale menu, de cooldown-per-doel, en de mens-alleen-poort. De gids dekt de beslissing van beide knoppen, en de aanname is dat je in een teammatch zit waarin je menselijke teamleden hebt die kunnen ontvangen. Buiten die context — solo, bots, of een vijandige grens — is de feature niet toepasbaar en de gids dekt dat bewust niet, want de beslissing daar is er geen. Lees de team-rollen gids samen met deze, want de rol die je in het team speelt — anker of feeder — is wat de voorstel beïnvloedt, en deze gids is de referentie voor de donatiebeslissing die op die rol draait. De volgorde waarin je de vier gidsen leest, is dus de volgorde waarin de beslissing in de match zelf ontstaat: eerst de kaartstrategie die vertelt welke bouw de binding constraint is, dan de team-economie die vertelt welk teamlid dat inkomens draagt, dan de team-rollen die vertelt welke rol jij in het team speelt, en dan deze gids die vertelt welke bron je in de tien seconden die de dreiging je geeft, sturen. Die volgorde is de volgorde van de context, en de context is wat de tien-seconden-beslissing mogelijk maakt: zonder de context is het voorstel een gok, met de context is het voorstel de exacte dekking van een genoemde aankoop.