[ALG] Game over internet speelbaar houden

[Orphix]

Ik ben in m'n hoofd bezig met het maken van een simpel spelletje dat ik ooit heb gezien. Dit bestaat uit balletjes die continu tegen elkaar botsen. Je hebt punten als balletjes, maar ook obstakels. Het doel van het spel is zoveel 'punt' balletjes jouw doel in te ketsen.

Leuk en aardig, 2-speler functie onontbeerlijk natuurlijk want dat is de hele gein erachter.

Nu zat ik erover te denken hoe je zoiets als dit over het internet zou kunnen spelen. Alleen ik kan geen methode verzinnen om dit speelbaar te houden bij een beperkte bandbreedte/ping. Dit omdat de interactie tussen de balletjes zeer precies komt.
Het aantal balletjes zal maximaal rond de 20 liggen. Bandbreedte is dan misschien niet het probleem, maar bij 30fps kan je wel erg gaan laggen.

Hoe kan ik dit het best opzetten dat het voor beide partijen speelbaar is?

[D2k]

realtime zeker?
uhm een java-applet oid komt dan het eerste op bij mij
maar het is idd wel een redelijk probleem waar ik niet zo 1-2-3 van zeg "zo moet je het doen"

[Gerco]

Balletjes (eenparig bewegende/botsende objecten) zijn toch uitstekend te simuleren? Wat je doet is simuleren hoe de balletjes bewegen tot je weer een locatie/snelheid update krijgt en dan verplaats je de balletjes naar hun goede plaats.

Dat doen spellen als UT en Q3 ook, alleen dan noemen ze het lag prediction.

[Orphix]

Op vrijdag 14 juni 2002 15:51 schreef Gerco het volgende:
Balletjes (eenparig bewegende/botsende objecten) zijn toch uitstekend te simuleren? Wat je doet is simuleren hoe de balletjes bewegen tot je weer een locatie/snelheid update krijgt en dan verplaats je de balletjes naar hun goede plaats.

Dat doen spellen als UT en Q3 ook, alleen dan noemen ze het lag prediction.

Maar beide spelers besturen ook een balletjes, dit is de variabele in het spel. Stel dat speler 1 de bal laat afremmen, dit komt pas 2 frames later bij speler 2 aan. Speler 2 heeft dan een ander speelveld dan speler 1 en zal het niet meer synchroon lopen.

[tomato]

En laat de verbinding niet via de server lopen, maar natuurlijk direct van speler naar speler.

Misschien is het trouwens leuk om eens naar Java Webstart te kijken ipv Applets. Al weet ik verder niet wat voor technieken je van plan was te gaan gebruiken.

[Verwijderd]

Je wilt lage latency dus gebruik je UDP. Dat kan tot gevolg hebben dat er enkele pakketjes niet, of in verkeerde volgorde, bij je clients aankomen. Vandaar dat je niet alleen de coordinaten, maar ook de richtingsvectoren van je balletjes in je pakketjes stopt. De clients kunnen zo een prediction doen wanneer er pakketjes niet of verkeerd aankomen.

<edit>
Het timing-probleem los je op door een server-tick te laten lopen, en de pakketjes te timestampen.

En ook als je peer-to-peer wilt spelen, zal je game verdeeld moeten worden in een client en een server. Of je die server als apart programma of als deel van je client implementeert is om het even.
</edit>

[Orphix]

Op vrijdag 14 juni 2002 15:56 schreef mietje het volgende:
Je wilt lage latency dus gebruik je UDP. Dat kan tot gevolg hebben dat er enkele pakketjes niet, of in verkeerde volgorde, bij je clients aankomen. Vandaar dat je niet alleen de coordinaten, maar ook de richtingsvectoren van je balletjes in je pakketjes stopt. De clients kunnen zo een prediction doen wanneer er pakketjes niet of verkeerd aankomen.

Hoe groot is het verschil tussen TCP/UDP?

Kan je niet een teller meegeven aan het pakketje die aangeeft voor welke frame het bedoeld is? (dus dat wanneer een oudere 'update' na een nieuwere 'update' komt die wordt genegeerd) ?

Maar in dit geval speelt er dus 1 computer als server. Dit lijkt mij wel de enige praktische oplossing om altijd de speelvelden synchroon te houden.

[Orphix]

Op vrijdag 14 juni 2002 15:56 schreef mietje het volgende:
<edit>
Het timing-probleem los je op door een server-tick te laten lopen, en de pakketjes te timestampen.

En ook als je peer-to-peer wilt spelen, zal je game verdeeld moeten worden in een client en een server. Of je die server als apart programma of als deel van je client implementeert is om het even.
</edit>

Haha hoe wist je dat ik dat ging vragen

Het wordt gewoon peer-to-peer. Front-end zal waarschijnlijk een directx windows app worden, maar dat is niet het probleem.

Dus de oplossing is dat de 'server' continu de staat van het speelveld toestuurt, verder laat je de 'client' gewoon doorspelen met de laatste bekende state waardoor het voor de speler wel 'soepel' blijft gaan.

[Verwijderd]

Op vrijdag 14 juni 2002 16:02 schreef Orphix het volgende:
Dus de oplossing is dat de 'server' continu de staat van het speelveld toestuurt, verder laat je de 'client' gewoon doorspelen met de laatste bekende state waardoor het voor de speler wel 'soepel' blijft gaan.

You've got it Dit heeft overigens wel nadelen in sommige MPOGs: doordat je de complete "worldstate" naar iedere client broadcast, zijn proxy-cheats mogelijk.

<edit>
En het verschil tussen UDP en TCP ontstaat doordat er (oa.) geen ontvangstcontrole in UDP geimplementeerd is. Vandaar dat je je UDP-pakketjes timestampt (of een sequence-number geeft), dan kun je controleren of ze in de juiste volgorde aankomen.
</edit>

[Soultaker]

Op vrijdag 14 juni 2002 16:02 schreef Orphix het volgende:
Dus de oplossing is dat de 'server' continu de staat van het speelveld toestuurt, verder laat je de 'client' gewoon doorspelen met de laatste bekende state waardoor het voor de speler wel 'soepel' blijft gaan.

Dat is niet echt eerlijk, omdat het niet symmetrisch is. De acties van de server worden direct in de spelstaat verwerkt. De client moet tenminste een round-trip-time (RTT) wachten voordat 'ie z'n actie in de spelstaat terugziet.

Op deze manier wordt de latency in de netwerkverbinding, waar in principe beide spelers schuldig aan zijn, geheel afgewikkeld op de client. Als het om behendigheid gaat, is dit nauwelijks acceptabel.

Ik zou dan ook voor een symmetrische oplossing kiezen, waarbij beide spelers dezelfde rol vervullen. Ze sturen elkaar dan continue updates en houden beiden een bepaalde buffer aan 'oude' spelstaten bij, zodat ze 'te laat' binnengekomen frames nog kunnen corrigeren. Om deze correctie enigszins te beperken (het ziet eruit als 'n 'glitch') zou elke wijziging per definitie al een latency van 'n halve RTT moeten hebben.

Op deze manier hebben zowel de client als de server een latency van een halve RTT.

[Verwijderd]

Op vrijdag 14 juni 2002 16:18 schreef Soultaker het volgende:
Dat is niet echt eerlijk, omdat het niet symmetrisch is. De acties van de server worden direct in de spelstaat verwerkt. De client moet tenminste een round-trip-time (RTT) wachten voordat 'ie z'n actie in de spelstaat terugziet.

Natuurlijk zullen de clients moeten wachten, ik stel voor om een server-clock te introduceren die niet percé gelijk hoeft te blijven lopen met de realtime-clock. Je past de servertijd aan aan de (hoogste) RTT van je clients, en zo hebben alle spelers de zelfde handicap, zelfs degenen die op een localhost server spelen.

[Creepy]

Op vrijdag 14 juni 2002 16:08 schreef mietje het volgende:

[..]

You've got it Dit heeft overigens wel nadelen in sommige MPOGs: doordat je de complete "worldstate" naar iedere client broadcast, zijn proxy-cheats mogelijk.

<edit>
En het verschil tussen UDP en TCP ontstaat doordat er (oa.) geen ontvangstcontrole in UDP geimplementeerd is. Vandaar dat je je UDP-pakketjes timestampt (of een sequence-number geeft), dan kun je controleren of ze in de juiste volgorde aankomen.
</edit>

Je kan natuurlijk ook de acties van de spelers doorgeven i.p.v. de posities van de balletjes... Zolang de beweging van de balletjes niet random is natuurlijk..

TCP heeft ook sequencing hoor... Het is namelijk nooit 100% zeker dat verschillende IP pakketjes over 1 en dezelfde route gaan..... en als verschillende IP pakketjes die bij elkaar horen over verschillende routes gaan, is het dus goed mogelijk dat op het moment van aankomst, ze in verkeerde volgorde aankomen.

TCP heeft standaard foutcontrole (ACK), UDP niet.