Gold Source Engine

Dit is een korte omschrijving over hoe Servers en Clients samenwerken, FPS, Ping (FPS) Boosters and hoe die delen allemaal samenwerken.

De Engine

De Half-Life Multiplayer Game Engine is samengesteld uit een server en één of meer Clients (tot een maximum van 32) die allemaal op een semi-real-time manier via het internet verbonden zijn. Communicatie tussen Server en Client gaat uit van het UDP protocol, wat erg bruikbaar is bij deze vorm van communicatie (meer daarover verderop in dit artikel).

De server is een "rendering" machine zonder graphics. De Client is een "rendering" machine die zowel op het grafische gebied en het audio gebied bezig is. Hij communiceert met de gebruiker door middel van het toetsenbord, de muis, joystick of welke soort besturing de gebruiker gebruikt.

Normaalgesproken draait de server op 100 FPS (Frames Per Seconde) of 10ms per frame. De server kan echter ook op hogere snelheden draaien, tot 1000 FPS toe. Er zijn echter wat hardware en besturingssystemen die dat tegen kunnen werken.

Als de server draait op 500 of 1000 FPS, dan heeft dat verder geen effect op de FPS van de Clients, elke machine regelt dat zelf. De Server FPS stand wordt ingesteld door middel van het CVAR sys_ticrate (min 0, max 1000).

Als de server in staat is om op 1000 FPS te draaien, dan heeft dat verschillende bijkomende voordelen. We gaan is kijken wat er allemaal gebeurd en waarom dat gebeurd.

The server draait een level, slaat gegevens op, rendert beelden, ontvangt status updates van de Clients en zendt ook gegevens terug naar de Clients.

De Client draait hetzelfde level, rendert de beelden en zendt en ontvangt gegevens naar en van de Server. Daarbij laat de Client de beelden zien aan de speler en ontvangt hij de gegevens die de speler ingeeft.

Daarbij rendert de Client ook de annimaties en posities van models, sprites, geluid, geanimeerde textures (bijvoorbeeld water) and mobiele objecten in het gezichtsveld van de speler. Daarbij horen dus ook wapens en schoten die al afgevuurd zijn.

De Server houdt al deze gegevens bij, maar hij hoeft alleen de plaatsveranderingen door te geven.

We zien dus dat die 2 compleet verschillende afzonderlijke systemen zijn, maar ze zijn wel afhankelijk van elkaar.

Laten we zeggen dat de Server op 500FPS draait. Dat betekent dat de gegevens om de 2 milliseconden beschikbaar zijn voor de Clients. Op 1000 FPS is dat dus per milliseconde.

De Client werkt op 2 manieren samen met de Server. Hij zendt 30 keer per seconde een update naar de server met zijn locatie (cl_cmdrate is standaard 30). Daarbij vraagt hij 20 keer per seconde om een volledige update aan de server (cl_updaterate is standaard 20). We negeren cl_cmdrate voor nu, omdat die niet vraagt om een antwoord van de server.

Als de cl_updaterate op 20 staat, dan vraagt de Client dus om de 50ms een update van de server. Als we dan de reistijd daarbij voegen (1/2 ping) van Client naar Server (met de server draaiende op 500FPS), dan betekent dat dat er een vertraging oploopt van 2ms voordat de update gerendert en teruggestuurd is naar de Client, met een extra van 1/2 ping vertraging.

Op 100FPS is dat dus een 10ms maximum vertraging.

Omdat alle Clients om updates vragen en daarbij ook nog is updates sturen, lijkt dat dus op een soort storm van updates die allemaal op de verschillende tijden aankomen bij de server.

De snelheid waarop de updates heen en weer gezonden worden, wordt geregeld door de CVAR "rate" op de Client (0 tot 20000 max) en de CVARs sv_minrate en sv_maxrate op de Server. De Server instellingen staan echter boven die van de Client. Rate wordt gemeten in bytes per seconde. Gemiddeld stuurt een speler met 7500 "sends and receives" een maximum van 7.5Kbytes per seconde naar de server.

Als de Server op 100FPS draait dan is er dus een periode van 10ms waarin de Clients hun gegevens kunnen samenvoegen waardoor ze klaar zijn voor de volgende zending. Als de Server in staat is de huidige frame voor het eind van de sys_ticrate waarde te berekenen, dan "slaapt" hij de rest van de tijd.

Dat betekent dat als er een grote hoeveelheid Clients aanwezig zijn, de server een grote lading aan updates moet verzenden in die 10ms, waardoor het nogal een last kan worden voor de uploadsnelheid.

Als de Server op 1000FPS draait, kan de Server direct reageren op de Clients. De Server kan dan vrij snel een update uitzenden voor die Client, wat resulteert in kleinere pakketjes, die beter verdeelt worden over de uploadsnelheid (Het totale gemiddelde blijft echter hetzelfde).

Dit doet drie dingen, het verkleint de druk op de uploadsnelheid, het verlaagt de ping naar elke Client. Daarbij komt nog een belangrijk punt. Het update de Clients iets sneller waardoor het hele systeem accurater werkt en de lag wordt tegengehouden.

Samengevat:

1. Server rendert de frames op 100, 500 of 1000FPS, updates zijn elke 10, 2 of 1ms beschikbaar. Clients renderen de frames op 100FPS en laten ongeveer 30 tot 100 FPS zien op het scherm, afhankelijk van de processor en de grafische kaart in de pc. Ook de gebeurtenissen in het level hebben daarop invloed.
2. Clients zenden 30 keer per seconde updates naar de Server.
3. Clients vragen 20 keer per seconde naar updates van de Server. In de tijd daartussen rendert de Client frames en probeert hij de gebeurtenissen te voorspellen terwijl hij wacht op een update.
4. Clients zenden en ontvangen data van de Server.
5. Servers die op een hogere FPS draaien kunnen sneller antwoord geven op de vraag naar informatie, waardoor er minder wachttijd op de Server is (wat een lagere ping geeft).
6. Clients zenden en ontvangen evenveel data, het maakt niet uit op welke FPS de Server draait.
7. Server CVARs sv_maxrate en sv_maxupdaterate worden onmiddelijk doorgevoerd, er kan echter een kleine vertraging optreden voordat de veranderingen doorgevoerd zijn (als er een zichtbaar effect is).