Archief - Netwerk game "syncen" ?

Hey,

ik heb dit weekend wat zitten experimenteren met net2 en SDL_Net. Nu ik wou eens probreren een netwerk gamepje te maken. Het spel in kwestie zou een tron cloon worden. Nu de single player versie is niet echt een probleem, maar ik heb wel wat probleempjes met de multiplayer versie.

Nu om te communiceren tussen de server en de clients stuur ik gewoon een code door met daaraan eventuele data aangehecht. om enkele voorbeeldjes te geven:
Code 1 met data player nr is een nieuwe speler aanmaken, Code 2 met player nr is Player moved left etc.

Wat ik momenteel doe is het volgende :
Server start en wacht op connecties
client connecteerd -> Server stuurd code van nieuwe player naar alle clients
Nieuwe speler wordt aangemaakt op de client.
Er wordt op enter geduwd in de server app -> Code start game wordt gestuurd naar alle clients en de clients kunnen hun speler bewegen.
speler op client 1 duwd bvb links -> code move left wordt gestuurd naar server en de server past de data aan in zijn kopie van het speelveld.
en zo gaat het voort.

Nu om alles te testen laat ik de server grafish alles weergeven wat op het speelbord (playfield) staat. maar hier volgt mijn probleem : De client staat steeds voor op de server. Maw de positie op het speelbord bij de client komt niet overeen met wat de server van gegevens heeft. Dit heeft tot effect dat wanneer ik bijvoorbeeld vlak tegen een zijmuur naar beneden duw, dat de player op de client juist getoond wordt maar op de server zit hij 1 vakje achter.

Nu vraag ik me af welke manieren er zijn om alles in "sync" te houden. Zodat dat wat de server "ziet" ook wel degelijk hetgeen is wat de clients zien.

Ik vermoed dat ik een soort van systeempje moet uitdokteren waarin de server op bepaalde momenten gaat controleren wat de positie is bij de client en als dit niet overeen komt dit gaat aanpassen.

Nu ik stuur ook geen posities door van client naar de server om de reden dat er dan gemakkelijk gecheat kan worden, door gewoon die waarden voor ze doorgestuurd worden in het geheugen te wijzigen. (vandaar die turn left/right/up/down messages)

ik heb er al aangedacht om bijvoorbeeld na elke move die een client doet een berichtje te sturen naar de server dat de client gemoved heeft, de server zou dan wachten tot hij dit berichtje gekregen heeft van alle clients met een eventuele tijdslimiet en dan een code terugsturen naar de clients om te zeggen dat ze de volgende move kunnen doen. Maar ik weet niet goed welk effect dit gaat hebben op het spel zelf. (Wat bijvoorbeeld als iemand met een 56k modemke speelt, dan gaan alle andere moete wachten tot deze speler het berichtje verszonden heeft)

iemand enig idee hoe je nu juist het spel in sync kan houden en of bovenvermeld idee een goede aanpak is of zijn er nog andere manieren ?

waarom wil je dat?

De logische manier voor games lijkt mij nog steeds om asynchroon te werken.

ja het versturen en ontvangen van de data zelf is asynchroon (en dus niet blocking), gebeurd in een aparte thread. Maar wat ik bedoel met syncen is dat alle data zowel op server als op de clients hetzelfde is op elke moment en dus niet als iemand met bvb 56 k verbinding speelt met mensen die een kabel verbinding hebben dat de mensen met de kabel verbinding de gegevens van de persoon met de 56k verbinding te laat zien of niet op de juist plek door desyncing problemen (data op de server komt niet overeen met data op de client dmv lag ed.)

joyrider zei:

ja het versturen en ontvangen van de data zelf is asynchroon (en dus niet blocking), gebeurd in een aparte thread. Maar wat ik bedoel met syncen is dat alle data zowel op server als op de clients hetzelfde is op elke moment en dus niet als iemand met bvb 56 k verbinding speelt met mensen die een kabel verbinding hebben dat de mensen met de kabel verbinding de gegevens van de persoon met de 56k verbinding te laat zien of niet op de juist plek door desyncing problemen (data op de server komt niet overeen met data op de client dmv lag ed.)

Klik om te vergroten...

dat is onmogelijk . als er een 56K idioot op u spel zit gaat het gewoon onmogelijk traag gaan. Ge gaat altijd van die dingen hebben. Het ding is wel dat je kan zeggen 'de server is altijd correct'. Dus welk beeld de clients op hun scherm hebben doet er geen zak toe. Een 56K'er zal dan heel moeilijk kunnen spelen, een breedbander met een RTT van 5ms ofzo gaat perfect kunnen spelen.

dat is afaik hoe meeste games het doen (simplified).

hmm ok, valt niveel aan te doen dus. Ik heb toch dat systeempje gemaakt van dat bericht sturen naar de clients dat ze hun volgende move mogen doen en dat de server dan wacht tot hij van iedereen (alle clients) een antwoord heeft gekregen dat ze wel degelijk bewogen hebben. Dan stuurd de server weer hetzelfde bericht naar alle clients dat ze volgende move mogen doen. Alle clients kunnen geen move doen tenzij ze dit bericht van de server gekregen hebben.

Dit systeemke werkt vrij goed heb het net getest met een vriend die ook telenet heeft over internet. Maar ge zag het spel wel af en toe "hick uppen". doordat hij te lang moest wachten op een andere speler. Het leek dan alsof het spel stotterde of gewoon effe pauzeerde. (maar feitelijk wachte de server gewoon op een antwoord van de andere speler dat hij gemoved heeft).
Met dit systeempje loopt alles wel zoals het hoort namelijk wat de server en de clients zien is identiek hetzelfde, nadeel is echter wel dat je moet wachten op de persoon met de traagste connectie. Maar ik ken geen ander systeempje om ervoor te zorgen dat de server en client gegevens hetzelfde zijn.

En je gebruikt het udp protocol?
Het udp protocol is veel sneller in het versturen van data dan tcp (dus je krijgt je client/server situatie sneller synchroon...). Natuurlijk is er dan geen zekerheid van "komt het paketje aan?" dus maak je spel-protocol zo dat je spel niet raar begint te doen als hij een pakketje niet heeft ontvangen.

En stap best af van uw wacht opallen synchronisatie systeem.

Netwerk code is een heel domein op zich hoor. Als je gewoon wat wil bijleren, doe zo voort; als je een deftig werkend game wilt, gebruik een bestaande library ( à la zoidcom, ken er niet zoveel van maar die valt nog mee schijnt)

Je hebt er natuurlijk het moeilijkste game uitgepakt om netwerk code voor te schrijven , en ik zal het direct verduidelijken.
In een netwerk zit je altijd met een delay, op een LAN valt het nog redelijk mee, maar internet is echt lastig. Maw, als je gewoon packetjes stuurt en daarmee update, zal je client steeds achterlopen op je server en andersom. Wat doen netwerk games nu om dit op te lossen... wel... ze cheaten een beetje via een techniek die "death reckoning" noemt. Snel uitgelegd werkt dit als volgt: server stuurt dat hij op positie 1.0 zit, wanneer client dit aankrijgt is er al wat tijd verstreken, en client gaat voorspellen dat hij al op positie 1.1 zit, en toont dit zo aan de speler. Meer info hier:
Gamasutra - Features - "Dead Reckoning: Latency Hiding for Networked Games" [09.19.00]
Dead reckoning - Wikipedia, the free encyclopedia
Client-side prediction - Wikipedia, the free encyclopedia
En natuurlijk op gamdev.net vind je verschillende artikels:
GameDev.net -- Multiplayer and Networking

Om terug te komen waarom je een slechte keuze hebt gemaakt qua spel: Bij racegames kan je redelijk voorspellen waar de auto's gaan terrecht komen. Bij First Person Shooters is dit moeilijker, maar als kogels missen valt het niet zo hard op. Probleem bij lightcycle games is dat de gameplay zelf op reactiesnelheid is gebaseerd, en ik vrees dat het hard gaat opvallen wie nu eerst die bocht had gemaakt.
Dit is volgens mij ook de reden waarom er bij GLTron wel een LAN versie is, maar geen internet.

Veel success met het developen, je zal er veel mee bijleren !

@Litheon:

Ik had idd eerst TCP gebruikt, maar heb nu alles omgezet naar udp. Ik ga een dezer dagen (wsl morgen) wat dingen veranderen om die wacht op allen synchronisatie te vermijden. Is het ook zo dat wanneer je bvb 2 udp packetjes achter elkaar verstuurd je niet zeker weet of die 2 pakketjes ook in dezelfde volgorde aankomen op de clients / server met udp ? Is dit bij tcp ip wel het geval ?


@KeaTs

Ja tis de eerste keer dat ik zoiets probreer en wil dus wat bijleren, heb een vrij goeie library gevonden die nog een extra layer boven sdl_net vormt, net2 mss al van gehoord? Tis zeer simpel in gebruik (gebruikt sdl_userevents), en gebruikt worker threads voor het ontvangen en verzenden van data (sdl_net is blocking normaal)

@kwitters:

Hmm death reckoning, zal ik eens moeten bekijken, dat is idd zoiets waar ik naar op zoek was. Nu ik dacht dat tron feitelijk een vrij simpel spel geweest zou zijn om er een netwerk versie van te maken. Daar er enkel en alleen maar user input is die bepaald wat er gebeurd met de speler(s) zelf en dus niet dingen zoals bvb een bom die random geplaatst geweest is. Afin ja kga er toch probreren aan voor te werken. En wat info opzoeken over death reckoning.

Ik moet wel nog (nu dat ik udp gebruik) een systeempje zien uit te vissen om te weten dat een packetje verloren gegaan is door mss telkens een confirmatie terug te sturen op elk soort pakket dat ontvangen is geweest door de client / server

en om van mijn wacht op allen systeem af te stappen : mss moet ik het omgekeerd doen laat de clients wachten op een response van de server maw als client X pijltje omhoog induwd, stuur bericht door naar server, maar pas dit niet direct aan op de client en wacht tot de server een confirmatie bericht gestuurd heeft dat hij deze boodschap ontvangen heeft en voer dan pas de correctie door op de client. Ik zie hier wel al enkele graten in als er zware lag is of het pakketje gaat verloren dan zal het lijken alsof men helemaal niet naar boven heeft geduwd of men gaat altijd een vertraging zien in het sturen.

afin ja ben maar wat aan het probreren

btw netwerk games testen als je helemaal alleen bent is een hel ! moet hier van het ene venster naar het andere switchen en dan nog eens opletten dak ni tegen een muurtje vlieg met men slangetje

TCP zorgt ervoor dat alles in de juiste volgorde aankomt, maar ik bedoelde gewoon van stel je bent quake 3 aan het spelen en je trekt even uw netwerkkabel er uit en er in, en je kan gewoon voort spelen.

Maar ik zou idd de interessante links van kwitters bekijken.