Netwerk game: Wie is eerder?

[Koozza]

Ik zit al een tijdje met het idee een game te maken met een netwerk functie erin (LAN/Internet). Nu heb ik alles uitgedacht maar ik loop keer op keer met denken tegen een probleem aan: Wie heeft een zet eerder gedaan?

In de game kunnen 2 spelers op hetzelfde moment een object beinvloeden. Nu is het zo dat wie het eerst komt wie het eerst maalt, en de ander heeft dus pech. Nu is het probleem dat je altijd een ping hebt, en dus niet accuraat kan bepalen wie er eerder was. Hoe kun je dit oplossen?

Ik heb zelf gedacht aan een timestamp meesturen met je zet, maar dan moeten bijde spelers wel de zelfde timestamp hebben, of de timestamps moeten precies evenhard oplopen.

Kan iemand mij hier wat advies over geven?


Thijs

[Fish]

externe tijd gebruiken.

pool.ntp.org ?

[Koozza]

Ja, maar zit je er dan niet mee dat ook dat ophalen tijd kost?

[Fish]

volgens mij staat dat hier ergens
http://www.eecis.udel.edu/~mills/stamp.html

[Soultaker]

Voor het synchroniseren van timestamps is het voldoende als de server authoritieve timestamps meestuurt. De clients hoeven geen absolute tijd te kennen; het gaat er alleen om de relatieve ordening van gebeurtenissen.

Verder kun je nog Googlen op backward reconciliation (dit is bijvoorbeeld interessant) maar voor de meeste dingen geldt toch wie het eerst komt, die het eerst maalt.

[Koozza]

Ik zal bijde pagina's is door gaan lezen en kijken of ik eruit kom. Bedankt voor de hulp alvast

[Ulster Seedling]

Ik vind het een interessante vraag, dus heb ik er even over zitten nadenken. Volgens mij moet het mogelijk zijn om tot een 'winnaar' te komen als je beide spelers een bevestiging laat sturen zodra ze de actie van de tegenspeler hebben ontvangen. Door beide spelers de tijd tussen de verschillende momenten te laten meten, kunnen ze onafhankelijk van de werkelijke tijd tot een kloppende uitslag komen. Het enige is dat ik hier de aanname maak dat de tijd benodigd voor het transport van de data over het netwerk steeds gelijk blijft.

[Koozza]

Ik zat aan een soort gelijk iets te denken. Als je een pakketje stuurt met een timestamp, en je laat de 2e pc reageren weet je dus wat de tussentijd is en als je die deelt door 2 heb je de Delay. Zo zou je dus ook de verschillen kunnen uitrekeken. Maar deze methode gaat ook uit van een ping die gelijk blijft.

[Ventieldopje]

Met twee players is dit leuk maar als je dit met meerdere players gaat doen zou iedereen dezelfde "ping" krijgen als de speler met de traagste internet verbinding. In veel multiplayer spellen (FPS / MMO etc.) is het zo dat wie het eerst komt wie het eerst maalt vandaar dat mensen een zo laag mogelijke ping willen hebben!

[Koozza]

Ventieldopje schreef op maandag 23 juli 2012 @ 01:32:
Met twee players is dit leuk maar als je dit met meerdere players gaat doen zou iedereen dezelfde "ping" krijgen als de speler met de traagste internet verbinding. In veel multiplayer spellen (FPS / MMO etc.) is het zo dat wie het eerst komt wie het eerst maalt vandaar dat mensen een zo laag mogelijke ping willen hebben!

Klopt helemaal, maar voor wat ik nu in gedachte heb is 2 spelers genoeg

[Woy]

Maar dan pas je dus gewoon de client zo aan dat die "ping" pakketjes vertraagd beantwoord worden, zodat het lijkt dat je een langzame verbinding hebt, en dus een voordeel boven de andere speler krijgt

[PrisonerOfPain]

Lees deze artikelen anders even door:

http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php
http://fabiensanglard.net/quake3/network.php

[R4gnax]

PrisonerOfPain schreef op maandag 23 juli 2012 @ 09:30:
Lees deze artikelen anders even door:

http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php
http://fabiensanglard.net/quake3/network.php

Het netwerk model en de architectuur die Quake 3 hanteert steken heel goed in elkaar en zijn een absolute aanrader om door te nemen. Het is inderdaad goed leesvoer.

Sowieso steekt Quake 3 in het algemeen ook echt enorm goed in elkaar. Het is alleen allemaal nog plat C, dus heel veel pseudo-classes met externals en structs waarin mensen snel de weg kwijt neigen te raken. Maar, als je de moeite neemt om de nodige bird's eye views van de code architecture te maken dan ziet die ca. 25MB aan code er ineens heel goed uit.

Heb zelf ooit nog eens samen met mede-GoT gebruiker Grijze Vos een scriptbaar particle system in de client VM geimplementeerd voor een Computer Graphics course aan de universiteit. Later heb ik het nog naar de opensourced engine layer geport ('because we can'), maar eigenlijk nooit meer vrijgegeven. De Q3 modding communities waren tegen die tijd eigenlijk al dood aan het bloeden. Wow, wat voelt dit nostalgisch jongens!

[ Voor 48% gewijzigd door R4gnax op 23-07-2012 21:55 ]

[Ellos]

Dit is ook een zeer aan te raden wiki, de source engine

https://developer.valveso...ce_Multiplayer_Networking
https://developer.valveso...l_Design_and_Optimization

[ Voor 33% gewijzigd door Ellos op 24-07-2012 00:15 ]

[R4gnax]

Ellos schreef op dinsdag 24 juli 2012 @ 00:12:
Dit is ook een zeer aan te raden wiki, de source engine

https://developer.valveso...ce_Multiplayer_Networking
https://developer.valveso...l_Design_and_Optimization

In een oogopslag gezien doen ze daar (bijna) hetzelfde als Quake. Ook niet zo verbazend, aangezien de originele Half-Life op een aangepaste Quake engine draaide.

[Ellos]

Klopt, dat is ook het mooie, overlap van een stuk informatie en de aanvulling op elkaar.

Die technieken zijn sowieso wel bekend bij eigenlijk elke fast paced game studio omdat het 'proven practices' zijn.
Meerdere goeie bronnen is nooit verkeerd.