Beste oplossing online web-based game?

Pagina: 1
Acties:

  • TheBlasphemer
  • Registratie: September 2004
  • Laatst online: 13-11-2025
Hey,

Ik ben van plan om voor Informatica samen met een vriend een oud NES spelletje na te maken als massive-multiplayer webbased spel.
Het gaat hier om een actiespel, dus niet turn-based of whatsoever ;)

Als server wou ik zoieso een C++ server schrijven die voor elke client bijhoud welke positie, snelheid, etc hij heeft, en ook collision enzo doet en alles synched. Maarja, ik zit hier in W&G dus daar gaan we het (nog) maar niet over hebben.

Ik heb wel eens eerder zoiets gedaan in flash, maar was toen niet zo goed met flash, en het kwam erop neer dat ik positie van elke speler opsloeg, en af en toe een update van de server kreeg en daar de objecten dan naartoe bewoog. Dit heeft als nadeel dat alles zoieso een seconde ofzo achterloopt, en de bewegingen gaan verre van vloeiend.

Daarom wil ik het nu fundamenteel anders doen: Elke client bevat in feite dezelfde codes ed als de server, en kan ook zonder server prima uitvogelen waar players zich zouden moeten bevinden als de omstandigheden niet veranderen. Zodra de server een update geeft, worden de posities en snelheden ed geupdate, en het kleine beetje dat hij dan verplaatst ten opzichte van de voorspelde positie kan ik nog een beetje interpoleren. Dit heb ik al eens eerder gedaan in MSN games, en dit werkt verbazende goed :)

Echter nu de grote vraag: Waarin ga ik de client coden?

Ik had drie vier ideeen op dit moment:
  • Client zelf wordt JavaScript en DHTML. Voor verbinding naar de server schrijf ik een kleine Java applet die niks anders doet dan alle informatie doorpasen naar Javascript, en informatie van javascript doorstuurt naar de server. Javascript en DHTML heb ik al veel ervaring mee, Java niet zo, maar met documentation moet zoiets simpels best lukken.
  • Client zelf wordt JavaScript en DHTML. Voor verbinding naar de server een Flash "video" vergelijkbaar aan die Java Applet. Dit kan ik zonder veel moeite maken.
  • Client wordt geheel Flash, en ook de verbinding wordt in Flash geregeld. Helaas moet ik dan wel veel leren qua flash, aangezien ik bijv niet zou weten hoe ik de timing van de update kan regelen (bij elke 20ms kan ik javascript met settimeout, en zo'n timing is nodig om de updates gelijk te laten lopen aan de server). Voordeel is dat de graphics er wel mooier op worden.
  • Client wordt in Java. Geen tot weinig ervaring met Java games, behalve wat kleine MIDLets voor mn telefoon
  • Client in ActiveX (of alleen socket-soort in ActiveX), groot nadeel: Geen firefox...
Wat denken jullie wat de beste oplossing is, en zo ja, wat zijn de voordelen en de nadelen van de anderen ?
Of weten jullie een andere oplossing die ik nu over het hoofd zie ?

Alvast bedankt,
TB

[img=http://www.web2messenger.com/smallstatus/w2m/theblasp.png]


  • J27
  • Registratie: Januari 2003
  • Laatst online: 16:54

J27

1 mogelijkheid die je duidelijk over het hoofd lijkt te zien is ajax, oftwel: gewoon javascript gebruiken om de data van de server op te halen (zie google: htmlrequest javascript)

  • TheBlasphemer
  • Registratie: September 2004
  • Laatst online: 13-11-2025
J27 schreef op vrijdag 13 januari 2006 @ 10:38:
1 mogelijkheid die je duidelijk over het hoofd lijkt te zien is ajax, oftwel: gewoon javascript gebruiken om de data van de server op te halen (zie google: htmlrequest javascript)
Hier had ik zelf ook al een beetje over negedacht, maar daar zitten een paar grote nadelen aan:
  • Met AJAX kun je data ophalen, maar als iets moet bijhouden waar elke speler zich precies bevind en moet kijken of er niet gecheat wordt (door muren "warpen") moet er zoieso een server draaien.
  • Voor een "actie"-spel moet je toch minstens 4 updates per seconde hebben op de posities van spelers. met AJAX vier requests per seconde ligt mn webserver bij ongeveer 8 spelers compleet plat ;)
  • AJAX maakt elke keer een nieuwe verbinding om data op te halen, dit kost veel extra tijd. Een bestaande verbinding om data over te verzenden is sneller.
Ik heb ook gekeken naar AJAX met server-push ed, maar dit is zo ingewikkeld (werkt dan weer niet op IE ofzo, en PHP is er niet voor gemaakt enzovoorts), dat dit niet haalbaar is...

[img=http://www.web2messenger.com/smallstatus/w2m/theblasp.png]


  • syllaz
  • Registratie: Mei 2002
  • Laatst online: 09-04 09:26
Waarom moeilijk doen als het makkelijk kan?

Flash + Socketserver (bv. Unity of Flash Comm. server) is alles wat je nodig hebt voor multiplayer games. Geen gezeik met cross-browser scripting en je target +/-95% van het internet. :)

  • TheBlasphemer
  • Registratie: September 2004
  • Laatst online: 13-11-2025
syllaz schreef op vrijdag 13 januari 2006 @ 10:46:
Waarom moeilijk doen als het makkelijk kan?

Flash + Socketserver (bv. Unity of Flash Comm. server) is alles wat je nodig hebt voor multiplayer games. Geen gezeik met cross-browser scripting en je target +/-95% van het internet. :)
Is in feite gewoon de flash-only optie die ik al in mn TS naar voren bracht, alleen gebruik ik dan een C++ server die met de XML Sockets van Flash werkt ipv een standaard server. Standaard servers zijn er (volgens mij) alleen om data van ene client naar andere te brengen, terwijl ik juist een server nodig heb die actief de data checked en daarmee de posities enzo berekend. (dus client verteld welke keys het ingedrukt houdt, server bepaalt wat er dan gebeuren gaat.)

[img=http://www.web2messenger.com/smallstatus/w2m/theblasp.png]


  • syllaz
  • Registratie: Mei 2002
  • Laatst online: 09-04 09:26
Ik denk toch dat Unity hetgeen is wat je zoekt. Je kunt als student een gratis license krijgen als je een goed concept hebt. Meer info: http://www.moock.org/unity/u2server/

Hier nog wat voorbeelden wat je er mee kan:
http://64.49.222.225/unity/showcase/

Het voordeel is dat je je op de inhoud en werking v/d game kan concentreren ipv de communicatie van/naar de server opnieuw uit te vinden. ;)

  • Blue-eagle
  • Registratie: September 2000
  • Niet online
Volledig flash lijkt me minder "hackable", als je javascript met images gebruikt kan men redelijk simpel die plaatjes vervangen door andere plaatjes en op die manier misschien al een voordeel opdoen (beeldvullende explosie -> transparante GIF) en het is ook moeilijker om je eigen scripts toe te voegen.

En natuurlijk.. flash is mooier, vectoren kun je goed schalen waardoor je niet per sè vast zit aan een bepaald scherm formaat, animaties zullen kleiner (kunnen) zijn dan allerlei animated GIFjes..

  • André
  • Registratie: Maart 2002
  • Laatst online: 09:54

André

Analytics dude

Ik heb bij een bedrijf gewerkt waar dit dagelijks werk was, en onze programmeurs gaven op dit gebied de voorkeur aan Macromedia Shockwave. Je kunt daarmee zelfs openGL gebruiken voor je graphics.

Oh ja: als je ook highscores gaat bijhouden zul je alle verkeer moeten encrypten, ook de code van je spel zelf zal ge-encrypt moeten worden.

[ Voor 27% gewijzigd door André op 13-01-2006 11:14 ]


  • TheBlasphemer
  • Registratie: September 2004
  • Laatst online: 13-11-2025
Graphics hoeven niet ZO gepimped :P
Tis immers een re-make van een NES-spel ;)
En wat jij zei over cheaten gaat ook niet echt op, immers wordt alles op de server gedaan, en als je dan wil cheaten zul je moeten inhacken op mn server 8)

[img=http://www.web2messenger.com/smallstatus/w2m/theblasp.png]


  • Peter
  • Registratie: Januari 2005
  • Laatst online: 12-04 23:19
Hmm, leuk idee, ik ben iets dergelijks van plan maar dan met executables :)

  • TheBlasphemer
  • Registratie: September 2004
  • Laatst online: 13-11-2025
.Peter schreef op vrijdag 13 januari 2006 @ 12:59:
Hmm, leuk idee, ik ben iets dergelijks van plan maar dan met executables :)
Ik had zoiets al eerder gedaan beetje als testprojectje, mede omdat ik nog niet zo goed was in C++ Graphics. Was al een flinke tijd geleden, en was het allang vergeten totdat een vriend ernaar vroeg, het leek hem ideal om zoiets te maken met een ander spel ;)

[img=http://www.web2messenger.com/smallstatus/w2m/theblasp.png]


Verwijderd

Ik ben zelf ook met een interactief webbased multiplayer game, zelf gebruik ik een niet heel erg nette maar wel zeer compatible manier.

-Frontend is volledig Javascript/dhtml
-Verbinding gebeurt met Ajax en voor snelle reactietijden een aparte pagina die blijft laden en data naar de browser pushed.

Nadelen aan javascript vind ik vooral dat je heel erg voor performance en compatibiliteit moet oppassen. voordeel aan de andere kant is dat als je het goed doet, het overal werkt, en ook netjes performed :)

Backend is op dit moment php, maar daar heb ik een beetje spijt van (omdat ik requestbased moet werken en dus geen dingen in het geheugen kan houden.)

http://www.pixelcity.net/dev/

Verwijderd

Ik ga dit topic een beetje volgen, ben bezig met dhtml versie van een bepaald spelletje.
Verwijderd schreef op dinsdag 17 januari 2006 @ 01:14:
Backend is op dit moment php, maar daar heb ik een beetje spijt van (omdat ik requestbased moet werken en dus geen dingen in het geheugen kan houden.)
Dan werk je met een verkeerd systeem waardoor je die data niet goed kan volgen tussen de requests van 1 user. Als je een goed database en/of sessiesysteem zou ontwikkelen dan heb je daar geen last van. Verder kan je ook cronjobs laten draaien en je kan bv ook via PHP-CLI werken.

  • Murphy
  • Registratie: November 2000
  • Laatst online: 23-03 16:20

Murphy

(2B||!2B)?

Flash heeft als nadeel dat het op een gegeven moment t - r- r - a - a- g -g wordt. Als je aan de ene kant grafisch aan de processor trekt en aan de andere kant om de 20 ms. (kan in Flash ook met setInterval :) ) variabelen send en load, heb je een dikke kans dat Flash stikt.

Shockwave is idd (nog wel) een beter alternatief!

Verwijderd

Verwijderd schreef op dinsdag 17 januari 2006 @ 03:13:
Dan werk je met een verkeerd systeem waardoor je die data niet goed kan volgen tussen de requests van 1 user. Als je een goed database en/of sessiesysteem zou ontwikkelen dan heb je daar geen last van. Verder kan je ook cronjobs laten draaien en je kan bv ook via PHP-CLI werken.
Dat klopt idd. De truuk zit hem in het efficient regelen van communicatie tussen de verschillende child processen aan de serverkant. Verder denk ik dat voor de schaalbaarheid aan de client kant Javascript wel een hele goede optie is, met als groot voordeel dat je bijvoorbeeld "on the fly" classes en objecten kunt uploaden naar de client en kunt instantieren. Zo kun je in een uitgebreid spel een on demand structuur krijgen waardoor alles lichtgewicht blijft.
Pagina: 1