[Qt4] Tetris multiplayer

[Verwijderd]

Hallo iedereen,

Ik ben een bezig met een demo applicatie van qt over het netwerk te laten werken. Nu zit ik met het volgende probleem. Ik stuur alleen over het netwerk de commando's over hoe de blokjes zich moeten gedragen.(links,rechts,draaien..) De berekeningen zelf laat ik over aan elke computer opzich. Het probleem is nu dat het blokje een paar milliseconden later beweegt dan op de lokale computer waardoor de blokjes anders kunnen komen te liggen onderaan. Nu ben ik aan het twijfelen om de berekeningen allemaal op 1 computer te laten doen of de client een bericht terug te laten sturen wanneer de speler op de server een volgende zet mag doen.

Wat techniek wordt over het algemeen toegepast?

[ Voor 4% gewijzigd door Verwijderd op 01-05-2012 15:59 ]

[CH4OS]

Ik zou zoiets turn-based maken, zonder dat de tegenspeler ziet wáár de steen komt te liggen of heen gaat.

[MLM]

Over het algemeen in >realtime< multiplayer games doen alle clients een lokale simulatie, en alle veranderingen die van belang zijn voor andere spelers (zoals wat de client doet) worden naar de server gestuurd.

De server doet zijn eigen simulatie (aan de hand van alle informatie van clients). De server stuurt de resultaten terug naar de clients.

De client verifieert zijn eigen simulatie aan de hand van de feedback van de server. Als er een "verschil" is tussen de client en de server, dan heeft de server "gelijk" en moet de client zijn eigen status aanpassen om te synchroniseren met de server,

Voor >turnbased< games kan je het simpeler opzetten, aangezien er altijd maar 1 client tegelijk speelt kan elke client gewoon aan het eind van de beurt je state synchroniseren met de server (en/of iedereen), en dan is de volgende aan de beurt

Los van bovenstaand, het is zelden een goed idee om "input toetsen" te verzenden over het netwerk.
Het is al een stuk beter om "entity state" (ie, positie en rotatie van het blokje) periodiek te verzenden.

Afhankelijk van hoe robuust/seamless je applicatie wilt laten werken, en onder welke omstandigheden (ie, moet het alleen op LAN werken? over het internet terwijl je broertje je pijp voltrekt met torrents tegen je maat in china?) zijn er nog complexere oplossingen

[ Voor 38% gewijzigd door MLM op 01-05-2012 16:20 ]

[leuk_he]

Wat MLM zegt... maar even een stapje terug.

-Het moet real-time aanvoelen. Dus een toets indrukken moet een visuele reactie hebben, niet moeten wachten dus op een server "gevoel". Dat pleit ervoor zoveel mogelijk op de client te doen

ECHTER

Het moet ook beschermd zijn tegen cheaten. Op een cleint/netwerk kan vanalles gemanipulieerd worden, tetris.exe kun je niet vertrouwen. Dus de server moet alles narekenen. En daarom kom je dus op de sync oplossing van MLM

Het wordt nog een stukje moeilijker als je ook wil beschermen tegen express aangebachte lag op het netwerk. Stel je voor dat tetris in een moeilijk stuk zit, dan zou je het spel kunnen vertragen door het netwerkverkeer te vertragen.

nou kun je stellen dat het maar een demo app is, maar de anti cheat technologie moet je uiteraard ook demo'en

[ Voor 17% gewijzigd door leuk_he op 01-05-2012 16:11 ]

[CodeCaster]

Verwijderd schreef op dinsdag 01 mei 2012 @ 15:58:
Het probleem is nu dat het blokje een paar milliseconden later beweegt dan op de lokale computer waardoor de blokjes anders kunnen komen te liggen onderaan.

Ik ken Tetris alleen als éénspelerspel, waarbij je één blokje bestuurt. Er zijn ook wel mulitplayervarianten, maar de enige toegevoegde luxe daarbij is dat je het speelvelden van de tegenstander(s) in realtime naast het jouwe ziet. Dus wellicht kun je je sync-issues, of jouw implementatie van Tetris, nog iets specifieker toelichten?

De multiplayerspelmodellen die ik ken, gaan in ieder geval uit van één bron van waarheid, eventueel per perspectief. De meest eenvoudige manier is het opsturen van commando's naar de server, waarna de server de volgende staat berekent en die terugstuurt naar alle clients (inclusief degene die de staat veranderde). Dit leidt uiteraard tot lag-issues: het duurt even voor de eigen statusverandering zichtbaar is voor de speler, doordat deze een roundtrip moet maken naar de server.

Om dat probleem op te lossen kun je gaan voor dezelfde oplossing, maar daarbij de invoer van de speler eerst voor waar aan te nemen: je client verandert de staat van het spel op basis van zijn invoer, waarna de invoer ter controle (en om de andere clients te kunnen updaten) nog naar de server wordt verstuurd.

Uit bovenstaande oplossing komt nog steeds een synchronisatie-issue: wat als een of meer van de andere spelers ondertussen ook hun staat hebben gewijzigd? Je kunt bijvoorbeeld een update forceren voordat je de client de nieuwe invoer laat versturen, en de invoer aan de hand van de nieuwe data al dan niet ongeldig maken. Dat zal ook niet altijd werken: ook deze update kan al verouderd zijn voordat jouw invoer daarna bij de server arriveert.

Om dit af te vangen kun je motion prediction toepassen zoals in shooters gebeurt. Als je bijvoorbeeld naar Battlefield 3 kijkt, kun je zien dat spelers klagen dat ze, terwijl ze op hun scherm beschutting hebben gezocht, toch nog geraakt kunnen worden. Dit komt doordat de server de data van iedere client (tot op zekere hoogte) als waarheid aanneemt, dus als genoemde speler op het scherm van de schutter nog wel in beeld was, dan wordt 'ie alsnog geraakt (i.e. het perspectief dat ik eerder noemde). Dit lijkt me voor Tetris echter geen optie, omdat er dan bijvoorbeeld lijnen verdwijnen die er eerder nog lagen, als twee spelers dat tegelijk proberen...

Lang verhaal kort: je hint in je OP al naar het turn-based zijn van het spel, en ik denk dat je de multiplayercode daar ook afhankelijk van moet laten zijn, maar dat hangt dus helemaal af van jouw implementatie van het spel.

[ Voor 10% gewijzigd door CodeCaster op 01-05-2012 16:48 ]

[Verwijderd]

Bedankt voor de uitgebreide toelichten. Mijn implementatie is eigenlijk dat ieder om de beurt aan zet komt op één en hetzelfde bord. Om aan beurt te komen moet je dan een quizvraag juist beantwoorden. Zoals op blokken in Belgie.

Ik ga het nog een rustig bekijken en ga dan uitmaken wat de beste oplossing is.

Nogmaals bedankt!

[wackmaniac]

In dat geval zou ik toch zeggen dat het verschil van een paar milliseconden niet zoveel uitmaakt; de gebruikers zien elkaar scherm niet, dus die weten niet eens dat er een paar milliseconden verschil is. Je zou nog iets minder verkeer kunnen versturen door alleen iets te sturen als het blokje daadwerkelijk wordt verplaatst door de gebruiker (zo heb ik dat in een multiplayer tetris ooit gedaan); "blokje naar x,y" of "blokje naar 90 graden" etc, de rest kan de client wel simuleren.