[AS3] Leent AMF zich goed voor een snelle multiplayer game?

[apNia]

Op het moment schrijf ik een 2D multiplayer game, en ik zoek een manier om de posities van de poppetjes over te sturen. Ik zie dat AMF populair is, maar ik kom het eigenlijk nooit tegen in combinatie met games, altijd om gewoon simpele gegevens binnen te trekken. Het zijn volgens mij gewoon HTTP requests, but I could be wrong.

Is AMF een geschikt formaat om met een aardige tempo gegevens heen en weer te sturen, of leent zich daar een andere applicatie zich beter voor?

[zwippie]

Het AMF formaat is in ieder geval compact in vergelijking met XML en (in iets mindere mate) JSON. Dus dat is een pluspunt.

Ik denk dat je even een paar testjes moet doen, zowel met AMF/XML/JSON als met de verschillende AMF implementaties voor PHP (aangenomen dat je PHP gebruikt).

[Woy]

Je zult denk toch wat specifieker moeten zijn met je vraag. "met een aardig tempo gegevens heen en weer sturen" is natuurlijk nogal subjectief.

De vraag is welke eisen je aan de communicatie stelt. Gaat het altijd over een 100mbit netwerk lopen, of moet het ook over een 9600 baud modem werken. Is het erg als er af en toe pakketjes wegvallen of in een verkeerde volgorde aankomen? Wat is de maximale latency die je mag hebben?

Al die dingen spelen een rol op wat voor manier je de communicatie gaat opzetten.

[Bozozo]

AMF is volgens mij (snel gewiki'd) gewoon een AS versie van JSON, ofwel een zeer efficiente vorm van boodschappen tussen server en flashclient doorgeven. Hoe je de verbinding legt is een tweede, en ik denk (ben allesbehalve een expert though) dat http connecties te inefficient zijn als je heel vaak posities wilt doorgeven (meerdere malen per seconde). Dan zou ik eerder kijken naar een directe verbinding met de server via sockets.

[apNia]

Woy >> Zoals Bozozo zegt wil ik inderdaad meerdere keren per seconde posities oversturen. Het idee is dat het gewoon een webgame wordt, en meer dan een x,y coordinaat zal het niet worden. Eventueel met wat incidentele messages voor de acties die er plaatsvinden.

Meer dan 4 spelers per game staat er momenteel ook niet op het programma, dus dat lijkt me goed haalbaar. Het enige is dat ik niet weet of alles wat AMF nou doet HTTP requests zijn, die niet altijd even snel zijn. Dus als ik meerdere keren per seconde de server moet vragen naar posities, en heel veel mensen doen dat tegelijk, krijg je dan geen slecht lopende games dankzij de wachtrijen.

In feite moet de game gewoon gangbaar speelbaar zijn met een breedbandverbinding, daar komt het op neer. Maar is AMF wel ALLEEN afhankelijk van de verbinding van de gebruiker? Want als (!) het HTTP protocol gebruikt wordt, krijg je volgens mij gewoon wachtrijen, hoe snel je verbinding ook is. En volgens mij is dat in ieder geval met AMFPHP het geval.

[McVirusS]

Ik zou zeker ook eens naar socketservers kijken. Dan heb je in ieder geval een open verbinding. Bijvoorbeeld Smart Fox Server.

[apNia]

McVirusS schreef op maandag 11 mei 2009 @ 16:29:
Ik zou zeker ook eens naar socketservers kijken. Dan heb je in ieder geval een open verbinding. Bijvoorbeeld Smart Fox Server.

Dat ziet er goed uit, maar voor AS3 support moet ik betalen

[jorisros]

Je kan ook red5 nemen (daar baseert de red box van Smart Fox Server zich op) en ik zou dan geen amf gebruiken omdat je dan steeds een verbinding moet maken. Maar ik zou gebruik maken van iets als shared objects.

[Sihaya]

apNia schreef op maandag 11 mei 2009 @ 16:35:
[...]

Dat ziet er goed uit, maar voor AS3 support moet ik betalen

Voor zover ik weet ondersteunt red5 RTMP via een directe socketverbinding, dus zonder http requests. Dit is volgens mij een efficient binary protocol, dus aansluitend bij de real time eis. Een mogelijk nadeel daarvan kan trouwens wel de compatibliteit met firewalls aan de client zijde zijn.

[ Voor 18% gewijzigd door Sihaya op 11-05-2009 21:40 . Reden: iemand met dezelfde tip ]

[Woy]

Sihaya schreef op maandag 11 mei 2009 @ 21:37:
[...]
Voor zover ik weet ondersteunt red5 RTMP via een directe socketverbinding, dus zonder http requests. Dit is volgens mij een efficient binary protocol, dus aansluitend bij de real time eis. Een mogelijk nadeel daarvan kan trouwens wel de compatibliteit met firewalls aan de client zijde zijn.

Een binary protocol, of ieder geval zo compact mogenlijk is wel aan te raden. Aangezien er hier blijkbaar niet zo heel veel data over de lijn hoeft, en er ontwikkeld word voor breedband verbindingen is de nood misschien wat minder. Maar als snelheid een van je belangrijkste factoren is dan wil je zo min mogenlijk overhead hebben die niets belangrijks toevoegt.

Vroeger ( misschien nog wel ) werden netwerk games bijvoorbeeld ook vaak op UDP gemaakt. Dan heb je minder overhead dan bij TCP/IP. Je moet daar wel betrouwbaarheid voor inleveren, maar bij veel spellen is latency belangrijker dan betrouwbaarheid ( tot op bepaald nivo natuurlijk ).

Maar de grote vraag blijft dus wat je eisen aan het protocol zijn. Waarom wil je een bestaand formaat gebruiken? Je kan natuurlijk redelijk eenvoudig zelf een formaat defineren.

[apNia]

Thanks voor de reacties
red5 lijkt me een goede oplossing voor het oversturen van weinig data op hoog tempo (snelheid heeft de prioriteit inderdaad).

Woy >> Gezien alles nu alsnog over TCP/IP gaat, heb je dan niet die betrouwbaarheid alsnog toch? Er is alleen wat overhead door het protocol, maar volgens mij kan ik daar niet echt omheen. En vraag is ook of ik dat wil... Neem aan dat games als Quake Live nu ook gewoon iets dergelijks gebruiken

Een bestaand formaat kies ik omdat in mijn geval mijn netwerk kennis niet al te best is. Hier op het werk hebben we een hoop gedoe gehad met policy's bij Flash files en weet ik wat. AMF lijkt me zo'n beoefende methode dat het een beetje 'de weg van de minste weerstand' leek. Maar het lijkt zich beter te lenen voor lobby's en dat soort dingen, maar niet zozeer het snel heen-en-weer sturen van data.

[Woy]

apNia schreef op dinsdag 12 mei 2009 @ 11:43:
Woy >> Gezien alles nu alsnog over TCP/IP gaat, heb je dan niet die betrouwbaarheid alsnog toch? Er is alleen wat overhead door het protocol, maar volgens mij kan ik daar niet echt omheen. En vraag is ook of ik dat wil... Neem aan dat games als Quake Live nu ook gewoon iets dergelijks gebruiken

TCP bied inderdaad garanties over het correct aankomen van data. UDP bied dat echter niet. Ik zou niet weten wat Quake Live precies gebruikt, maar ik denk inderdaad dat het gewoon over TCP/IP gaat.

Ik zeg ook niet dat je perse een eigen formaat moet specificeren, alleen dat een Human-readable protocol wel overhead heeft, die je niet perse nodig heeft. Dan is het dus zaak om te kijken of die overhead geen belemering vormt voor jouw doeleinden.

Ga bijvoorbeeld eens uitrekenen wat de bandbreedte gaat zijn als je het op die manier aanpakt. Als je bijvoorbeeld elke seconde 5 keer een x/y positie door wilt sturen en je doet dat met de volgende XML

XML:

<Position>
    <X>5</X>
    <Y>6</Y>
</Position>

Dan kan je gewoon uitrekenen hoeveel data dat is. Daarbij moet je natuurlijk wel rekening houden welke transport laag je gebruikt. Want bij HTTP moet je natuurlijk die overhead ook meerekenen. ( TCP/IP heeft natuurlijk ook ovehead, maar die heb je ook als je HTTP gebruikt aangezien dat weer boven op TCP/IP draait )

Als uit die berekening blijkt dat je in de problemen komt met je bandbreedte zou je kunnen beslissen om een simpel binair protocol op te stellen. Zoals je hierboven bij het XML voorbeeld ziet is de daadwerkelijke data immers maar een klein deel van het totale bericht.

Maar nogmaals, het is grotendeels afhankelijk van de eisen en wensen die je aan je communicatie stelt.

[apNia]

Nou het gaat om een bomberman clone, dus snelheid staat voorop. Het is een speltype dat het zich niet kan permitteren al te veel lag te hebben. Ik kan er natuurlijk iets van path prediction inbouwen, maar ik denk dat het sturen over sockets gewoon buiten een server om kan, en zo een server niet al te erg belast. Staat weer tegenover dat je, zoals Sihaya zei, firewall issues krijgt.

Maar ik denk dat ik nu al heel wat meer informatie heb over het onderwerp en de mogelijke opties, bedankt jongens