Waarom Fall Guys oneerlijk voelt: de netcode achter die vreemde valpartijen

Dat “oneerlijke” gevoel in Fall Guys komt meestal neer op één ding: de server beslist, en jouw scherm loopt daar soms achteraan. Je sprint over Door Dash, duikt nog net door een open deur, en toch kaatst je bean terug alsof er een onzichtbare wand staat. Op jouw beeld zag het er clean uit. Aan de serverkant werd dezelfde situatie net anders berekend, en dat verschil voel je direct.

Fall Guys is een physics-based party royale met 60 spelers tegelijk, en dat maakt synchronisatie tussen client en server pittig. Met zoveel beans die duwen, vallen en botsen, hoeft er maar een kleine timing-afwijking te zijn om rare uitkomsten te krijgen. Daardoor ga je soms onderuit zonder duidelijke aanraking, en is botsingsregistratie in dit genre een stuk lastiger dan in video games die minder tegelijk hoeven te simuleren.

Server-authority en de illusie van controle

Fall Guys draait op een server-authoritative model, dus de server is de baas over de waarheid. Jouw client toont wat hij denkt dat er gebeurt, terwijl de server uiteindelijk vastlegt wat er echt gebeurde. Elke sprong, duw en botsing is pas definitief na bevestiging, en daar zit altijd vertraging tussen, meestal 50 tot 150 milliseconden afhankelijk van je ping en de datacenterregio.

Die keuze is logisch als je cheaters buiten de deur wilt houden. Als clients zelf hun positie mochten bepalen, dan was teleporteren naar de finish met een aangepaste build een kwestie van tijd. Het gevolg is dat je lokaal vaak een nette voorspelling ziet, terwijl de server ondertussen een uitkomst doorrekent die net anders valt.

Client-side prediction versus serverwaarheid

Om die vertraging te maskeren gebruikt Fall Guys client-side prediction. Zodra je de stick kantelt beweegt je bean meteen, zonder te wachten op de server. Ondertussen stuurt je client de input door en komt er enkele frames later een correctie terug. Zolang jouw voorspelling overeenkomt met de serverberekening, loopt alles soepel, en pas bij verschil triggert het spel een reconciliation-stap.

Op dat reconciliation-moment voelt het alsof je “onterecht” valt. De server rekent uit dat je die rand toch niet haalde en zet je terug naar de positie die wél klopt. Op je scherm lijkt dat op een vreemde glitch, terwijl het technisch gezien een late correctie is van iets wat aan de serverkant al vastlag.

Hitboxes die groter zijn dan je denkt

Veel frustratie komt ook door de botsingsvormen zelf. De beans zien er rond en zacht uit, maar hun collision shapes zijn capsules met aardig wat marge. Mediatonic doet dat bewust om de physics stabiel te houden met 60 spelers die tegelijk tegen elkaar aan staan te beuken.

Met strakkere hitboxes voelt contact realistischer, maar de physics worden er vaak instabiel van, met haperingen en spelers die door objecten heen klippen. Die brede capsule geeft de engine ruimte om duwen, vallen en stuiteren consistent door te rekenen. De prijs daarvan is duidelijk: je raakt soms iets dat er visueel net naast lijkt te zitten.

Waarom draaiende hindernissen het ergst zijn

Bij levels zoals Hit Parade of See Saw valt dit extra op. Draaiende hamers en bewegende platforms hebben op de server hun eigen update-cyclus, en die timing hoeft niet één op één te matchen met wat jouw client rendert. Als jij wegduikt op het moment dat de hamer langskomt, kan de server die hamer net een fractie verder hebben doorgezet.

De gevolgen zijn vaak dramatisch:

• Je rolt op je scherm onder de hamer door, maar wordt toch gelanceerd.
• Een andere speler lijkt naast je te grijpen, waarna je alsnog opzij vliegt door een geregistreerde duw.
• Je landt op een platform, en glijdt er toch af door een kantelbeweging die later binnenkomt.
• Je pakt op je scherm een rand, maar de server registreert je hand net naast het object.

Dit soort momenten zijn meestal geen klassieke bugs. Het zijn situaties waarin jouw voorspelling en de serverwaarheid uit elkaar zijn gelopen, en bij twijfel wint de server altijd.

Tickrate, interpolatie en de kosten van 60 spelers

De tickrate bepaalt hoe vaak de server de wereld opnieuw berekent en updates terugstuurt. Met een hogere tickrate wordt synchronisatie strakker, daarom draaien competitieve shooters zoals Valorant op 128 Hz en Counter-Strike vaak op 64 Hz, en bij Dota 2 posities 1-5 ligt de focus weer anders. Fall Guys zit lager, omdat 60 beans met volledige physics-simulatie simpelweg veel serverkracht vragen.

Bij een lagere tickrate zit er meer tijd tussen serverupdates. Jouw client probeert dat op te vullen via interpolatie en extrapolatie, waarbij hij inschat waar andere spelers naartoe bewegen. Zodra iemand onverwacht van richting verandert, klopt die inschatting niet meer, en dan zie je “teleports” of duwen die lijken te komen vanaf een plek waar die bean volgens jou niet stond.

Waarom dit genre dit probleem nooit volledig oplost

Shooters kunnen lag compensation gebruiken om hits te valideren op basis van wat de schutter zag op het moment van schieten. In physics-based party games pakt dat slecht uit, omdat één botsing meteen meerdere spelers beïnvloedt. Achteraf terugspoelen wie wie raakte levert dan weer nieuwe inconsistenties op, dus Mediatonic kiest voor serverautoriteit zonder uitgebreide rollback, en dat pakt structureel nadelig uit voor spelers met een hogere ping.

Daarom hoor je in Europa ook vaak klachten als iemand tijdens off-hours op Amerikaanse servers belandt, met “sticky” duwen en grijpacties die niet lijken te registreren. Elke extra 50 ms latency maakt het venster groter waarin jouw client en de server verschillende uitkomsten kunnen hebben.

Hoe erken je desync in je eigen gameplay?

Desync leren herkennen helpt, omdat je dan sneller ziet of het aan je timing lag of aan de netcode. Daardoor richt je je frustratie op dingen die je wel kunt beïnvloeden, in plaats van op onzichtbare servercorrecties. In de praktijk zie je desync vaak terug in vaste patronen.

• Je bean wordt teruggezet nadat je een actie leek af te ronden: klassieke reconciliation.
• Andere beans bewegen schokkerig of maken kleine sprongetjes: tekenen van hoge latency of pakketverlies.
• Grijpen komt pas na een halve seconde, of helemaal niet: de server bevestigt je input te laat.
• Je krijgt een tik van een draaiend object dat op je scherm al voorbij was: tickrate-mismatch.

Komen dit soort signalen vaak terug, dan zit het meestal in je verbinding of serverregio en minder in je skill. Een kabel in plaats van wifi, spelen op een server in je eigen regio en het sluiten van bandbreedte-vretende achtergrondprogramma’s scheelt vaak al merkbaar.

De fundamentele spanning tussen eerlijkheid en spektakel

De charme van Fall Guys zit juist in de onvoorspelbare physics. Dezelfde systemen die zorgen voor hilarische stuiters, knock-outs en chaotische finales, veroorzaken ook momenten waarop je valpartij onterecht aanvoelt. Met strakkere netcode en kleinere hitboxes wordt het eerlijker, maar ook een stuk minder wild.

Daar zit de ontwerpparadox waar Mediatonic continu mee balanceert. Het spel moet aanvoelen als georganiseerde chaos, en dat botst met pixel-perfecte precisie. Server-authority, ruime capsules en een gematigde tickrate zijn dus geen slordigheden, maar keuzes die stabiliteit, schaalbaarheid en speelgevoel voor 60 spelers tegelijk overeind houden.

Als je snapt hoe die netcode werkt, verdwijnt de irritatie niet meteen, maar het wordt wel beter te plaatsen. De volgende keer dat je zonder duidelijke reden van Slime Climb afglijdt, weet je in elk geval dat er een technische verklaring achter zit, en dat die kwalificatieronde morgen gewoon weer klaarstaat.