OpenFront Handelsvlotbestemmingen: waar je schepen écht heenvaren

Het directe antwoord: je kunt een handelsschip niet sturen, dus je stuurt de pool

OpenFront geeft je directe, moment-op-moment controle over vrijwel elke eenheid op de kaart. Je klikt op een oorlogsschip en het patrouilleert op de tegel die je kiest. Je stuurt een transport en hij landt waar je hem naartoe stuurt. Handelsschepen zijn de uitzondering. Een handelsschip heeft geen invoer die je het nog kunt geven nadat het de kade verlaat. Het moment dat het spawnt, heeft de engine al besloten naar welke haven het vaart, en niets wat je onderweg doet verandert dat. De vraag “hoe krig ik mijn handelsschepen ernaartoe te gaan waar ik wil?” heeft dus geen knop. Hij heeft een andere vorm.

De vorm is deze: je stuurt het schip niet, je stuurt de pool waaruit de engine pakt. Elk handelsschip is een willekeurige trek uit een gewogen lijst van geschikte bestemmingshavens, en die lijst wordt opgebouwd uit dingen die je wél volstrekt controleert: welke havens bestaan, op welk niveau, op welke afstand van jou, in welk verbonden water, en onder welke allianties en embargoes. De gewogen lijst is niet hetzelfde als “alle havens op de kaart”. Een haven minder dan 300 tegels van jou is niet zelden minder waarschijnlijk te kiezen — hij staat gewoon niet in de lijst. Een bondgenootse haven die 300 tegels overschrijdt wordt ongeveer twee keer zo vaak gekozen als een neutrale haven op hetzelfde niveau en op dezelfde afstand. Een niveau-3-haven wordt ongeveer drie keer zo vaak gekozen als een niveau-1-haven. “Waar mijn schepen heengaan” is dus een functie van de structuur van het havennetwerk, en die structuur mag jij ontwerpen. De herschikking waar de rest van deze gids op bouwt is: stop met het vragen hoe je een schip richt dat je niet kunt richten, en begin met het vragen welke havens ik geschikt ga maken, opwaarts gewogen, en uitgaand.

Dat betekent ook dat veel volkswijsheden die in de community rondspoken deels kloppen en deels omgekeerd lopen. “Bouwen havens dichtbij zodat je schepen niet ver hoeven varen” is de verkeerde intuïtie voor handelsschepen, hoe dichter een haven bij jou zit, hoe waarschijnlijker hij volledig uit je eigen bestemmingspool wordt uitgesloten. “Je kunt op een handelsschip klikken en hem ergens naartoe sturen” staat simpelweg niet in het spel — die klik-om-te-sturen besturing bestaat bij oorlogsschepen, niet bij handelsschepen. “Mijn schepen gaan willekeurig” is op het niveau van één schip waar en op het niveau van een netwerk onwaar: één vaartocht lijkt op geluk, maar na honderden vaartochten komt de gewogen pool neer op een zeer voorspelbare verdeling, en twee spelers met hetzelfde aantal havens kunnen puur omdat hun pools verschillen verschillende totalen verdienen. Deze gids is de kaart van die pool.

Versiegrens: wat v0.34.22 écht documenteert

Alles in deze gids is gekoppeld aan de formele v0.34.22-releasetag, en de onderstaande constanten zijn de constante die de bron van die tag daadwerkelijk implementeert. Als je dit leest op een andere build, dan is de regel stabiel maar verschuiven de getallen, en de specifieke aanbevelingen die van een getal afhangen — vooral de 300-tegel-uitsluiting en de 330-schip-verzadigingsknie — moeten je tegen welke tag dan ook je server draait opnieuw worden gecontroleerd.

De vijf getallen waarop de hele gids steunt zijn deze. Eerst: de korte-afstand-uitsluitingsafstand is exact 300 tegels: een bestemmingshaven waarvan de Manhattan-afstand van jouw haven strikt minder dan 300 is, wordt uit je bestemmingspool verwijderd. Dit is een harde knip, geen straf — onder de lijn is het gewicht van de haven nul, dus kunnen niveau en alliantie hem niet redden. Ten tweede: de nabijheidbonus dekt de eerste N dichtstbijzijnde geschikte havens, waarbij N het havenaantal gedeeld door drie is, afgeperkt tussen 4 en het totale havenaantal. Met 6, 12, 15, 18 of 24 geschikte havens betekent dat dat de eerste 4, 4, 5, 6 of 8 dichtstbijzijnde worden verdubbeld. Ten derde: elke haven voegt per niveau één kopie toe aan de gewogen pool, dus een niveau-L-haven heeft L keer het basisgewicht van een niveau-1-haven. Vierde: een bondgenootse of zelfde-team ontvanger voegt één extra kopie toe (verdubbeling), en die bonus stapelt met de nabijheidbonus. Vijfde: de globale spawn-throttle heeft een verzadigingsknie rond 330 schepen in het spel en een zachte vloer tot ongeveer 800 schepen, waarom per-haven handelsinkomsten in het late spel dalen ook al heeft niemand iets veranderd.

Twee extra grensfacten tellen en worden makkelijk over het hoofd gezien. De bestemming wordt exact één keer gekozen, in het moment dat het schip spawnt, en hij wordt niet opnieuw getrokken als het netwerk verandert terwijl het schip vaart. Als de bestemmingshavn afgebroken is, of er na vertrek een embargo wordt uitgeroepen, dan keert het schip gewoon naar huis terug en betaalt de vaartocht niets; de engine routeert het niet om naar een nieuwe haven. En de bestemmingspool bevat alleen maar havens bezeten door andere spelers die met jou mogen handelen: je eigen havens verschijnen nooit als bestemmingen voor je eigen schepen, een speler onder embargo wordt in beide richtingen uitgesloten, en een haven die niet in hetzelfde verbonden watercomponent ligt als het water naast jouw haven is onzichtbaar voor je schepen, ongeacht zijn niveau of alliantie. Elke sectie na deze is een uitbreiding van deze vijf getallen plus deze twee grensfacten.

De bestemmingstrek: hoe de engine je pool opbouwt

De engine kiest niet uit “alle havens”. Hij bouwt elke keer dat een van je havens op het punt staat een schip te spawnen een verse gewogen lijst op, en de lijst wordt opgebouwd in drie passes die je daadwerkelijk kunt voorspellen. Begrijpen wat de drie passes zijn, is de hele vaardigheid, want zodra je de pool in je hoofd kunt berekenen, kun je voordat je goud besteedt zeggen of een nieuwe haven zal helpen of stil van niets zal doen.

Pass één is geschiktheid. De engine kijkt naar elke haven op de kaart die bezeten wordt door een speler die niet jij bent en die met jou mag handelen, en behoudt alleen die welke een verbonden watercomponent delen met het water direct naast jouw haven. Alles andere is weg nog voordat de gewichting begint. Dit is waarom een groot eiland aan de overkant van een smalle seestraat tien niveau-5-havens kan hebben en toch nul van je schepen kan ontvangen: als het water naast jouw haven en het water naast hun haven niet één verbonden component zijn, zitten ze in verschillende pools en ontmoeten ze elkaar nooit. Dit is ook waarom een landvergrendelde economie die alleen per spoor handelt helemaal geen handelsschepen krijgt — handelsschepen varen op watercomponenten, en een landvergrendelde haven ligt niet op het component dat je schepen kunnen bereiken.

Pass twee is het basisgewicht. Voor elke geschikte haven duwt de engine die haven in de lijst één keer voor elk niveau dat hij heeft. Een niveau-1-haven verschijnt één keer, een niveau-2-haven twee keer, een niveau-3-haven drie keer. Het schip is dan een uniform willekeurig element van de hele lijst, dus een haven die drie keer verschijnt wordt drie keer zo vaak getrokken als een die één keer verschijnt. Dit is de enige plek waar ruw “hoe sterk is die haven” bijkomt: niveau is de vermenigvuldiger, en het vermenigvuldigt de andere twee bonussen die volgen.

Pass drie is de twee bonussen en één uitsluiting. De engine gaat door de geschikte havens in volgorde van afstand vanaf jouw haven, past een nabijheidbonus toe op de eerste N dichtstbijzijnde die de 300-tegel-uitsluiting haalden (verdubbeld, uit de N van de vorige sectie), en een vriendelijkebonus op elke geschikte haven die bezeten wordt door een bondgenootse of zelfde-team speler (verdubbeld). Een haven die zowel dicht als bondgenoots is kan dus tot vier keer zijn niveau aan kopies dragen, terwijl een vijandelijke haven op dezelfde afstand alleen zijn niveau draagt. En de uitsluiting loopt door de hele pass heen: een haven onder 300 tegels wordt nooit in de lijst geplaatst, dus hij draagt nul kopies bij ongeacht de bonussen. De trek is dan willekeurig element van de lijst, en dat is de bestemming van het schip voor de hele vaartocht.

De drie gewichten en één uitsluiting, elk met een getal

Je kunt de drie bronnen van gewichten omzetten in eenvoudige vermenigvuldigers, want ze zijn allemaal gewoon “hoeveel kopies van deze haven zitten in de lijst”. Het basisgewicht is het niveau. Een niveau-3-haven heeft 3 kopies, dus tegenover een niveau-1-haven op dezelfde afstand en relatie wordt hij 3 op 1 getrokken. Dit is de stille hefboom die de meeste spelers nooit aanraken: het upgraden van een verre haven waar je wilt dat je schepen hem voeden maakt niet alleen dat die haven meer besteedt, het maakt elk van je schepen ongeveer drie keer waarschijnlijker om daar te landen zodra hij geschikte is. De vang is dat niveau alleen een haven vermenigvuldigt die al in de lijst staat. Een niveau-5-haven onder 300 tegels heeft nul kopies hoeveel upgrades hij ook heeft, dus een grote nabije bondgenoot is net zo onzichtbaar als een kleine tot hij de lijn oversteekt.

De nabijheidbonus is een ring, geen helling. Hij geldt voor de eerste N dichtstbijzijnde geschikte havens en voor geen andere, waarbij N traag schaalt met het aantal geschikte havens dat bestaat (vier als er zes of twaalf zijn, vijf bij vijftien, zes bij achttien, acht bij vintigvier). De praktische lezing is dat er een zoet band is: de havens direct na de 300 tegels zijn de meest bevoordeelde geschikte havens op de kaart, omdat ze de eerste zijn die de uitsluiting halen en ze aan het hoofd van de dichtstbijzijnde-als-eeerst volgorde zitten die de ring uitdeelt. Een haven op 310 tegels wordt meer gewogen dan een haven op 900 tegels, alles overigens gelijk. Dat keert de naïeve “hoe verder hoe beter” heuristiek om die de uitbetalingscurve alleen zou suggereren. De afstand doet nog steeds veel — een vaartocht van 900 tegels betaalt veel meer goud dan een van 310, zoals de gids handelsroute-knelhal uiteen zet — maar de selectiewaarschijnlijkheid groeit niet met de afstand zoals de uitbetaling doet. Je kunt de meest waardevolle haven in de pool hebben die de minste schepen van enige haven in de pool ontvangt, omdat hij ver is en buiten de nabijheidsring.

De vriendelijkebonus is een alliantieschakelaar met een voorwaarde op afstand. Een bondgenootse of zelfde-team ontvanger die geschikte is (minstens 300 tegels ver) krijgt zijn niveau verdubbeld, dus een bondgenootse niveau-2-haven gedraagt zich als een niveau-4-haven voor het doel hoe vaak je schepen hem kiezen. Daarom kan samenwerken rond een gedeelde handelshub erop aanvoelen alsof de bondgenoot je inkomsten afvoert: de vriendelijkebonus leidt een groot deel van je pool naar hen om. De voorwaarde is dezelfde vloer van 300 tegels, dus een bondgenoot die een haven tien tegels van jou parkeert ontvangt helemaal geen van je schepen — wat de meest voorkomende bron is van de “waarom krijgt mijn bondgenoot zoveel” klacht, en het wordt beantwoord door de uitsluiting, niet door de bonus. De uitsluiting is tenslotte geen gewicht, het is een verwijdering: onder 300 tegels heeft de haven geen kopies, stop.

Waarom “in de buurt bouwen” het verkeerde plan is voor een handelshaven

De meest voorkomende handelintuïtie in OpenFront is clusteren: bouw je havens dicht bij je bondgenoten en dicht bij je eigen gebied, zodat je schepen korte, veilige reizen hebben en alles verbonden aanvoelt. Voor fabrieken en voor de dekking van oorlogsschepen is dat vaak de juiste keuze. Voor handelsschip-inkomsten is het de verkeerde keuze, en het is verkeerd om een reden die geen straf is maar een verwijdering. Onder de 300 tegels staat een haven helemaal niet in je bestemmingspool, dus een cluster van havens rondom je thuisbasis produceert een lokaal gebied met zeer hoge havendichtheid en zeer lage handelsschip-bestemmingsdichtheid. Je schepen mogen, door constructie, nooit landen op de dichtstbijzijnde havens bij jou.

Denk na over wat dat doet met de vorm van je inkomsten. Een speler die tien niveau-2-havens binnen 200 tegels van huis clusteren heeft een dicht lokaal netwerk gebouwd dat zijn eigen handelsschepen grotendeels negeren, omdat elk van die havens onder de uitsluiting zit. De schepen spawnen en landen dan op de dichtstbijzijnde havens die minstens 300 tegels ver zijn — die van iemand anders zijn havens, of de weinige verre havens die deze speler ook bezit. Het cluster doet nog steeds echt werk: het geeft oorlogsschepen plekken om terug te vallen, het ankeren spoorlijnen, het geeft een dichte territoriale kern. Maar als de reden waarom je het bouwde was om handelsschip-goud te voeden, dan faalt het cluster die klus stil, en het falen is onzichtbaar omdat de schepen zichtbaar varen en zichtbaar ergens landen — alleen niet waar je denkt.

De juiste plaatsing voor een handelshaven is het tegenovergestelde van het cluster: hij moet de 300-tegellijn overschrijden vanaf de havens waarvan je wilt dat hij de schepen ontvangt. Als je wilt dat je basis een voorhoede-economie voedt, dan moet de voorhoedehaven minstens 300 tegels ver zitten van de handelshavens van de basis, en ideaal direct na die lijn zodat hij in de nabijheidsring komt. Als je een bondgenoot wilt voeden, dan moet de hub van de bondgenoot 300 tegels of meer van jouw haven vandaan liggen en in hetzelfde watercomponent, en ideaal bondgenoots zodat hij ook de vriendelijke verdubbeling krijgt. En als je probeert te begrijpen waarom je inkomen dun is ondanks een groot lokaal havenaantal, controleer dan de afstand: tel hoe veel van je nabije havens daadwerkelijk boven de 300 tegels liggen vanaf de haven die de schepen spawnt. Het getal is doorgaans veel kleiner dan het havenaantal, en dat gat is de volledige uitleg. De gids hoeveel havens bouwen dekt de aandragsvraag; dit is de afstandvraag, en de twee antwoorden zijn onafhankelijk van elkaar.

De globale spawn-throttle en waarom late-game handel dunner wordt

Elke haven doet onafhankelijk van de anderen een spawnaanslag, en die aanslag slaat meestal niet altijd door, omdat er een globale knop zit die het totaal aantal handelsschepen in het spel afremt. Elke tien ticks probeert elke geschikte haven een schip te spawnen, maar de kans op succes daalt naarmate de wereldwijd al actieve handelsschepen meer worden. De verzadigingsknie zit rond de 330 schepen en de kansen krommen naar een zachte vloer die rond 800 schepen nagenoeg nul nadert. Dit is wat er gebeurt als je je netwerk groter maakt en het totale schipaantal over die knie duwt: je eigen havens doen nog steeds elke aanslag, maar een toenemend deel van die aanslagen mist nu, omdat de wereld al dicht zit met schepen die ergens anders varen.

Er zit een tweede lag, een genadetimer, die tegen de extreme dunheid inwerkt en de vorm van het spel in de late fase verandert. Een haven die lang geen schip heeft gespaund heeft een grotere kans te slagen dan een haven die zojuist gespaund heeft, dus het systeem stroomt de schepen uit over de tijd in plaats van ze allemaal tegelijk te laten landen. Het effect van beide lagen samen is dat het per-haven handelsinkomen een neerwaartse trend heeft over een match, zelfs als je niets hebt veranderd: het aantal schepen groeit, de kans per aanslag daalt, en je deel van de taart wordt minder. Dit is een van de belangrijkste redenen waarom een economy-first opener die vroeg een groot handelsnetwerk legt meer verdient dan een die laat op dezelfde havens begint, en waarom de late fase een verschuiving is naar andere inkomstenbronnen die niet op die throttle hangen.

De praktische implicatie is niet “stop met handelshavens te bouwen”, want de throttle remt alle spelers af en de relatieve stand is wat telt. Het betekent wel twee dingen. Eén: je voordeel van een goed ontworpen pool (goede niveau-upgrades, bondgenootshubs, havens op de sweet-spot van de nabijheidsring) is groter in de vroege en middenseen, want dan zit de wereld onder de knie en worden alle aanslagen verwerkt, dus het volle gewicht van je pool telt. Twee: als je late-game merkt dat je handel dunner is terwijl je rivalen stabiel blijven, is de eerste diagnose niet dat iemand slechter bouwt maar dat jullie allemaal tegen de throttle botseren en je relatieve pool-aandeel is wat je behoudt. Verhoog je aandeel met niveau-upgrades van de havens die je al in je nabijheidsring hebt, niet door meer havens op dezelfde plek te stapelen die elkaar niet kunnen voeden.

Allianties en embargoes: de twee schakelaars die je pool herschrijven

De vriendelijkebonus en de embargo-uitsluiting zijn de twee meest onmiddellijke en meest omkeerbare veranderingen die je kunt aanbrengen aan een bestemmingspool, en ze werken tegengesteld. Een alliantie vermenigvuldigt een haven in de pool van beide spelers, en een embargo verwijderd hem volledig uit beide richtingen. Omdat ze allebei onmiddellijk ingaan en onmiddellijk ontbinden zodra de relatie of de embargo verandert, zijn ze de instrumenten van het spel dat je het meest op het moment kunt gebruiken — in tegenstelling tot niveau en afstand, die je vooraf moet inleggen.

Start met wat een alliantie doet aan twee havennetwerken die al 300 tegels of meer uit elkaar liggen in hetzelfde water. Voordat de alliantie draait, krijgt de haven van speler A van B alleen het basisgewicht van zijn niveau, en omgekeerd. Zodra ze bondgenoten zijn, krijgt elke geschikte haven van de ander de verdubbeling, en elke speler stuurt nu een veel groter deel van zijn schepen naar de haven van de ander. Dit is de dubbelzijdige afdeling die de meeste spelers misleest: een alliantie is geen gratis inkomstenbron voor degene die de sterkere hub heeft, het is een spiegel, en beide partijen sturen schepen naar de pool van de ander. Als je een grotere hub hebt, dan ontvang je inderdaad meer van hun schepen, maar ze ontvangen ook een groot deel van de jouw, en de nettowinst hangt af van de verhouding van hun pool tot de jouwe, niet alleen van de grootte van jouw pool. De juiste vraag vóór je een alliantie sluit voor handelsdoeleinden is daarom niet “heeft die speler een grote haven” maar “hoe verhoudt hun pool zich tot de mijne zodra beide onderling verdubbeld worden”.

Een embargo is het exacte omgekeerde en het is de enige schakelaar die een haven uit beide richtingen tegelijk verwijdert. Een speler onder embargo wordt uit de geschiktheidsset van elke speler verwijderd, en verwijderd hij ook uit de set van hen zelf, dus hun eigen schepen stoppen met het varen naar de haven van de geblokkeerde speler en hun haven stopt met het ontvangen. De timing is alles hier, want het effect is onmiddellijk en onomkeerbaar zolang de embargo loopt: de gids embargo-timing-en-handelscontrole dekt wanneer een embargo je eigen inkomsten kost in plaats van die van de tegenstander, en hier is het korte punt dat als je een alliantie ontbindt of een embargo oplegt op een speler die een groot deel van je schepen naar hem stuurt, dan verdwijnt dat deel van je inkomsten dezelfde tick.

Waterverbinding: de onzichtbare muur rondom je pool

Van alle restricties op de pool is waterverbinding de meest onzichtbare en de moeilijkst te ongedoen maken, want hij is geen getal dat je kunt opzoeken maar een structuur op de kaart die je moet visueel aflezen. De bestemmingspool van een haven bevat alleen andere havens in dezelfde verbonden watercomponent als het water dat direct aan die haven grenst. Twee havens die op de kaart dicht bij elkaar liggen maar gescheiden zijn door een strook land, een landbrug, of een ondoorgangbare waterbarrière, zitten in verschillende componenten en zien elkaar nooit. Een haven aan de overkant van een smalle seestraat die door land wordt afgesloten is onzichtbaar voor je schepen ongeacht zijn niveau of alliantie.

Dit is de reden dat een groot eiland dat tien niveau-5-havens huisvest kan zijn en toch absoluut geen enkele van je schepen ontvangen als het water eromheen niet met jouw watercomponent verbonden is via een doorvaarbare route. Het is ook de reden waarom een landvergrendelde speler die alleen per spoor handelt nooit handelsschepen krijgt: handelsschepen varen op watercomponenten en een haven die puur landaansluiting heeft ligt op geen enkel watercomponent waar je schepen zijn. De praktische test voordat je een handelshaven ergens bouwt is daarom niet alleen “is het hier minstens 300 tegels van mijn spawnhaven” maar “ligt het water hier in hetzelfde doorvaarbare component als het water aan mijn spawnhaven”. Als het antwoord nee is, dan is de haven irrelevant voor handel hoe sterk hij ook is.

De consequentie voor het ontwerp van een netwerk is dat je vaak een haven moet plaatsen niet waar het goud het dichtst zit maar waar de waterverbinding het grootst is. Een haven op de oever van een smalle zeestraat die twee componenten verbindt kan meer schepen ontvangen dan een haven dieper in de baai, alleen omdat meer havens op de andere kant van de straat in hetzelfde component zitten en dus in je pool vallen. Omgekeerd kan een haven die op het land lijkt op een ideaal niveau en in de nabijheidsring te zitten volledig dode ruimte zijn voor handel omdat hij op een component zit dat je schepen niet kunnen bereiken. Controleer altijd de verbinding van het water vóór je de afstand en het niveau controleert, want verbinding is de poort die de andere twee pas toegankelijk maakt. Een havennetwerk dat er op de kaart perfect uitziet kan in werkelijkheid twee losse netwerken zijn die elkaar nooit raken, en dat is de fout die het vaakst onopgemerkt blijft omdat de schepen wel degelijk varen en landen. Het verschil tussen die twee losse netwerken is niet zichtbaar in het aantal havens of in de totalen, alleen in de verdeling van de bestemmingen die je pas ziet als je de pool zelf in je hoofd reconstrueert.

Waar het goud vandaan komt: de uitbetalingscurve en de sweet spot

De bestemmingspool beslist waar je schepen landen; de uitbetalingscurve beslist hoeveel elke landing opbrengt, en de twee zijn onafhankelijk van elkaar. De uitbetaling per schip schaalt met de afstand van de vaartocht over een sigmoïde: korte reizen betalen relatief weinig per tegel, de curve buigt dan flink omhoog rond de 300-tegels-midder en vlakkeert af bij zeer lange afstanden. Dat betekent dat de meest waardevolle vaartocht in absolute goud die is die het schip het verst laat varen, maar dat het verschil tussen 800 en 1200 tegels veel kleiner is dan het verschil tussen 150 en 300 tegels. De sweet spot voor absolute inkomsten zit daardoor ver, niet dichtbij.

De vang is dat de sweet spot voor inkomsten niet dezelfde is als de sweet spot voor kans. De havens die het verst liggen betalen het meest per schip maar worden het minst vaak gekozen, omdat ze ver van de nabijheidsring zitten en het basisgewicht niet opwaarden door hun afstand. De havens die direct na de 300-tegellijn zitten worden het vaakst gekozen (dicht + nabijheidsbonus + eventueel vriendelijk) maar betalen minder per schip dan de verre havens. Een goed handelsschipnetwerk is er een dat beide belanden: het heeft een ring van dichtstaande bondgenootse havens die vaak schepen ontvangen en een paar verre, goed verbonden havens die zelden maar dik betalen. Als je alles dicht bouwt dan krijg je veel schepen die weinig betalen, en als je alles ver bouwt dan krijgt je netwerk nauwelijks schepen. Het antwoord is gemengd: dichtstaande havens om de pool vol en vaak getrokken te houden, verre havens om de absolute inkomsten per schip op te krikken.

De praktische regel is dat je de uitbetaling per schip van een bestemming kunt schatten met de afstand, en dat afstand de enige bron van de uitbetaling is — niveau, nabijheid en alliantie beïnvloeden alleen de kans, niet de uitbetaling. Dat is de kern van de onsymmetrie van deze hele gids: het ene ding (kans) kun je sturen met structuur, het andere ding (uitbetaling per schip) kun je alleen sturen met afstand, en de twee staan haaks op elkaar. Een speler die alleen naar de dichtstbijzijnde havens kijkt mist de verre inkomsten, en een speler die alleen naar de verste havens kijkt mist de frequentie. De gids haven-tegen-fabriek dekt de bredere keuze tussen inkomstenbronnen; hier is het punt dat binnen de handelsbron de mix van dicht en ver je inkomen bepaalt, en dat een netwerk dat die mix bewust bouwt de twee sweet spots tegelijk ophaalt in plaats van de ene te offeren aan de andere.

De onsymmetrie van bestuurbareheid: waarom oorlogsschepen sturen en handelsschepen niet

Het scherpste contrast in het hele spel is dat oorlogsschepen handmatig bestuurbare zijn en handelsschepen dat niet. Een oorlogsschip accepteert een handmatige patrouille-oversturing: je klikt op een tegel en het schip patrouilleert daar omheen, en je kunt die oversturing zo vaak wijzigen als je wilt tijdens de vaart. Een handelsschip accepteert geen enkele van die besturingen. De klik-om-ergens-heen-te-sturen besturing die je bij elk ander schip op de kaart hebt, ontbreekt bij het ene schip dat je inkomsten voert. Dit is geen vergeten kenmerk of een bug; het is de fundamentele onsymmetrie die deze hele gids beschrijft, en het is waarom “sturen” het verkeerde woord is voor handel en “het netwerk ontwerpen” het juiste woord is.

De reden waarom het spel dit zo vormt is dat handelsschepen een autonome inkomstenbron zijn en oorlogsschepen een actieve controlebron. Als handelsschepen handmatig bestuurbare waren, dan zou de inkomensstroom van elke speler aan zijn handelingstempo gebonden zijn — je zult nooit meer goud kunnen verdienen dan je hand schiet. Door de bestemming bij de spawn vast te leggen en ze daarna autonoom te laten varen, wordt handel een structuur die je een keer bouwt en die daarna continu werkt, in plaats van een klus die je telkens zelf uitvoert. De prijs van die autonomie is dat je er tijdens de vaart niet meer over kunt meekijken, en de hele vaardigheid in OpenFront-handel is precies het accepteren van die prijs: je investeert je tijd in het ontwerpen van de pool één keer en je laat de engine de willekeur doen in plaats van de engine de besturing. Dit is waarom de spelers die de handel van OpenFront echt beheersen degenen zijn die het minst op hun schepen kijken: ze hebben de pool zo ontworpen dat de willekeur in het voordeel van hun structuur werkt, en ze hoeven alleen nog te controleren of die structuur nog steeds klopt naarmate de kaart verandert.

De praktische consequentie is dat je de oorlogsbesturing en de handelsbesturing met twee verschillende tools moet behandelen. Voor oorlogsschepen is het instrument de muisklik en de patrouille, en je denkt per schip. Voor handelsschepen is het instrument het bouwen en upgraden van havens en het sluiten en ontbinden van allianties, en je denkt per netwerk. Een speler die probeert zijn handelsschepen “naar huis te brengen” of “ergens anders naartoe te sturen” zit vast in het oorlogs-mental-model en zal steeds tegen de muur van de onsymmetrie aanlopen. Het moment waarop je overgaat van “waarom gaat mijn schip hierheen” naar “welke havens heb ik hier geschikte en opgewaarderd gemaakt” is het moment waarop je de handel van OpenFront echt begint te besturen.

De beslislijst: welke hef voor welke situatie

De rest van deze gids eindigt hier, want de hele theorie komt neer op een paar situaties die je in een echte match tegenkomt en één correcte hef voor elk van die situaties. De onderstaande tabel is die lijst, en de regel die je eruit kunt meenemen is dat de juiste hef de is die de pool verandert die je daadwerkelijk hebt, niet de pool die je wilt dat je hebt.

Situatie	Correcte hef	Waarom
Jouw schepen landen nooit op je bondgenoot	Controleer of de hub van de bondgenoot minstens 300 tegels van jouw spawnhaven ligt in hetzelfde watercomponent	Onder 300 is de haven volledig uit je pool verwijderd; de vriendelijkebonus kan hem niet redden
Je bondgenoot ontvangt enorm veel van jouw schepen	Accepteer de spiegel van de alliantie of verplaats je hub	Een alliantie stuurt schepen van beide kanten naar de pool van de ander; je verliest geen goud, je deelt frequentie
Je lokale havencluster voedt geen van je schepen	Bouw je handelshavens buiten de 300-tegellijn, direct na die lijn	Dicht clusteren is de verkeerde keuze voor handel; de sweet spot is direct na de uitsluitingslijn
Je inkomsten dalen in de late fase terwijl je niets hebt veranderd	Verhoog de niveau van de havens in je nabijheidsring, stapel er geen nieuwe havens bij	De globale throttle remt alle aanslagen af; je aandeel groeit met gewicht, niet met het aantal havens
Een speler die je wilt voeden ontvangt niets	Controleer waterverbinding vóór afstand en niveau	Een haven in een ander watercomponent is onzichtbaar voor je schepen hoe sterk hij ook is
Je wilt meer absolute goud per schip	Voeg een paar verre, goed verbonden havens toe naast je nabijheidsring	Uitbetaling schaalt met afstand; verre havens betalen dik maar zelden
Je wilt de frequente basis van je pool	Houd een ring van dichtstaande, eventueel bondgenootse havens	Dichtstaande havens worden het vaakst getrokken en houden de pool vol
Je ontbindt een alliantie of legt een embargo op	Reken op een onmiddellijke daling van je eigen handel	Een embargo verwijdert de haven uit beide richtingen dezelfde tick

De kortste versie van de hele gids is deze. Je kunt een handelsschip niet sturen, dus je stuurt de pool: de havens die je bouwt, op welk niveau, op welke afstand, op welk water, en onder welke allianties. De engine doet de rest. Alles wat je in deze gids hebt gelezen — de drie gewichten, de drie uitsluitingen, de throttle, de onsymmetrie van bestuurbareheid — is het uitbreiden van die ene zin in een besluitvorming die je in een echte match daadwerkelijk kunt toepassen. Het moment waarop je overgaat van het sturen van schepen die niet gestuurd kunnen worden naar het ontwerpen van de havens die de engine zal gebruiken, is het moment waarop je de handel van OpenFront echt begint te besturen, en dat is precies waar dit stuk eindigt.