gotfurrr schreef op dinsdag 7 november 2017 @ 14:30:
[...]
Dit is geen makkelijke exit, maar ik bedoelde eigenlijk de netcode/desync problemen. Ik begrijp dat het hele performance verhaal met client side dingen anders is.
Maar het desync verhaal lijkt me nou juist iets dat relatief makkelijker op te pakken is.
Overigens is bij het werk wat ik doe 50ms langzamer ook niet acceptabel in veel situaties. Sterker nog, als sommige calls 50ms zouden duren dan werkt hier opeens de helft niet meer vermoed ik. Ik denk dat niet alleen gamers veeleisend zijn

Netcode en desync is gelukkig ook relatief makkelijk te onderbouwen door het op te delen:
1. Packet size (data te versturen)
2. aantal clients / server en de beschikbare resources
1: De game heeft packets tussen client/server lopen waarin een ontzettend grote set data moet zitten. Een kleine greep hieruit betreft:
Server -> Client:
- Enemy locatie
- Object locaties
- terugkoppeling hit registratie
- update hp/inventory data
Client -> Server:
- Client locatie
- Update hp/inventory data
- Hit registratie
- Bullet registratie
De data in deze pakketten moet zo klein mogelijk zijn, maar gelijktijdig ook zo betrouwbaar mogelijk. Om een speedhack bijvoorbeeld tegen te gaan zou de client zijn locatie en vervoersmiddel moeten doorsturen naar de server, bij het 2e pakket met deze informatie moet de server de eerste locatie vergelijken met de 2e locatie met de snelheid van het voertuig en de tijd tussen de twee pakketten om uit te rekenen of dit een haalbare afstand is (met een kleine foutmarge) of dat dit onmogelijk is en dus om een speedhack gaat.
Het desyncen onstaat hierbij als een pakket van de client bijvoorbeeld te laat bij de server wordt verwerkt. Pakket 1 wordt gestuurd, pakket 2 en 3 zijn ook al verstuurd. Het systeem pakt pakket 3 op, terwijl 1 nog niet (volledig) is verwerkt. Daardoor registreert de server alleen jouw positie van pakket 3. De andere 2 zijn bij jou wel bekend maar niet op de server (deze zijn gediscard). Je positie zal dus voor andere mensen niet goed geupdate worden, dit resulteert bij deze mensen in een warpende player of hitregistratie welke niet correct is. (achter een gebouw lopen en een headshot krijgen als jij al achter de muur bent is omdat bij de andere speler het pakket nog niet binnen is dat jij achter deze muur staat. Client side registratie op hun pc geeft aan dat het een hit is en stuurt dit terug naar de server. De server verklaard daarom de hit correct en registreert deze bij jou.
2:
In spellen zoals Counterstrike speelt men op een server met max 30 spelers op een zeer kleine map/world. Dit betekend dat de server gelijktijdig voor 30 man informatie moet updaten over locatie/hp en hitregistratie.
Zie nu de server voor je als een boodschappenlijstje dat van boven naar beneden wordt afgevinkt. Zodra je onderaan ben ga je opnieuw beginnen met "inkopen" doen.
Per vinkje kost het je 10ms om het vinkje te zetten. Laten we zeggen dat elk vinkje een speler is.
Hoe meer spelers er op de server zitten hoe langer het lijstje wordt. Dus met 5 spelers kost het totaal 50ms om het lijstje af te werken en opnieuw te beginnen (1 update/speler elke 50ms). Maar met 100 spelers loopt dit al op naar 1000ms.
Omdat PUBG een hele grote map draait kost dit al een berg resources. Daar bovenop moet elke speler zijn update pakketje ontvangen, een feedback pakketje versturen en daarna weer wachten op de volgende update. Met 100 man kost dit aanzienlijk veel resources/tijd.
Dit kan je ook terugzien in het feit dat aan het begin van de game met 100 man alles nog best laggy voelt, je loot niet gelijk kan oppakken etc. De gameserver kan het gewoon niet aan om die 100 man snel genoeg van informatie te voorzien. Zodra er nog 30 man over zijn zie je dat alles veel beter reageert en hit registraties meer on point zijn.
De tickrate van PUBG zou als ik het goed onthouden heb rond de 30 moeten liggen. Aan het begin van de game zit dit ergens rond de 12-14 en pas halverwege de game komt deze uit rond de 24-28. Dit komt omdat de updates dan pas sneller kunnen verlopen.
Nu de vraag uiteraard, hoe los je dit op en zorg je dat de speler sneller geupdate kan worden en dus een hogere tickrate/betere response kan worden afgedwongen? Simpel, maar toch ook weer niet:
- Het formaat van de pakketten tussen de client/server verkleinen zodat deze sneller verwerkt kunnen worden door de server
- De server performance verhogen door bijvoorbeeld meerdere processor cores beschikbaar te stellen etc zodat de verwerking door de server sneller kan worden afgehandeld
- Uitbreiding van het (glasvezel) netwerk in het serverpark om te zorgen dat er genoeg bandbreedte beschikbaar is (dit is vaak niet de bottleneck).
Tijdelijk meer resources beschikbaar stellen per server kosten miljoenen om te realiseren voor Bluehole, waarom zou de developer miljoenen investeren als het probleem slechts van tijdelijke aard is en dit dus meer een band aid fix betreft.
De optie om de pakketjes te verkleinen is haalbaar tot zekere hoogte (uiteindelijk blijf je met een basis dataset zitten die altijd verzonden moet worden met controles op deze data).
De laatste optie is dus server optimalisatie. Dit zorgt ervoor dat de server meer resources vrij heeft om het verkeer van de clients af te handelen en verlaagd dus de performance issues. Dit is echter dus pas mogelijk nadat de game (zoals eerder door mij aangegeven) in een stabiel eindstadia zit.
Ik heb vernomen dat Bluehole zijn servers pas geleden heeft gemigreerd van Amazon's servers naar Microsoft's servers. Dit heeft twee doelen gehad, ten eerste is het voorbereiden op de publicatie van de game op de XBox. Ten tweede is het netwerk van de Amazon servers niet geoptimaliseerd voor videogame data te verwerken (UDP traffic) waarbij het serverpark van Microsoft deze optimalisatie wel heeft. Dit levert dus al een rauwe performance increase op voor de developers zonder grote wijzigingen in de code door te hoeven voeren.
Hopelijk heb ik het zo een beetje duidelijk kunnen onderbouwen/beschrijven. Zo niet, vraag gerust
[
Voor 7% gewijzigd door
Bloodhoundje op 07-11-2017 15:32
. Reden: Stukje toegevoegd over hit/reg/desync ]