Netzwerktechnik für Client-"Browsergame"

Guten tag werte Community,

also zu dem was ich ich vorhabe:

Ich will soetwas wie ein Browsergame (ogame, die stämme etc) erstellen - das ganze soll aber nicht über den browser sondern über einen Client laufen - zur einsparung von traffic durch grafiken multaccingprävention etc etc.

Meine Frage ist jetzt aber was würdet ihr mir dafür empfehlen - war bisher in richtung TCP/IP tendiert evtl über UDP oder E-mails (hört sich doof an ich weiß ^^). Mein Ausbilder hat aber nun gemeint die soket TCP/IP technologie sei total veraltet und es gäbe moderneres - meine frage wäre was genau?

Zur erklärung was der server leisten muss:
Bei jedem befehl den der User erteilt wird ein Datenpaket an den server gesendet welcher überprüft ob der user den überhaupt die erlaubnis hat diesen befehl auszuführen. Anschließend wird die entsprechende antwort an den user zurückgeschickt.

So eine nachricht von user zu server würde dann einmal: dessen ID, dessen Passwort die befehlsID (eine 3-4 stellige zahl) und die entsprechenden parameter. Dabei wäre es kein problem wenn das datenpaket einmal 1500 - 2500 ms latenz hätte, die haupschwirigkeit ist das der server 800 bis 1200 solcher befehle pro minute bearbeiten können muss. (Plane das auf einen server TEORETISCH 10-20.000 spieler passen).

Also zu welcher technik würdet ihr mir raten?

MfG
dein.Tod

PS: Ich weiß das ich absulut größenwahnsinnig bin und damit mindestens ein halbes jahr und läger allein für den code brauche und dann noch grafiker etc etc ^^

Ich weiß das ich absulut größenwahnsinnig bin und damit mindestens ein halbes jahr und läger allein für den code brauche und dann noch grafiker etc etc ^^

multipliziere dasmit 3 dann kommst du hin.

nimm dafür WCF und ncihts anderes. so wirst du glücklich.

edit: wenn es allerdingsauch auf linux etc laufensoll, wirst du tcpclient und -server nehmen müssen und alles in mono machen.

Du kannst das auch über webservices lösen und dir den client code wie in WCF generieren lassen, dann sparst du dir die .NET 3.5 abhängigkeit und vielleicht gehts ja auch auf Mono? 🙂

TCP/IP schließt by the way UDP aus. Email ist hier unangebracht. UDP ist schnell, aber du musst dich um alles selbst kümmern, also es ist nicht sichergestellt, dass pakete ankommen, in welcher Reihenfolge sie ankommen usw. TCP schenkt dir das alles. Also: Wenn Hardcore dann TCP, wenn richtig Edgy dann WCF, wenn angenehm und nicht edgy dann webservices. 🙂

@udp/tcp
von udp war hier auch nie die rede. das ist hier auch kein anwendungsfall für udp. man kann auch nciht äpfel und birnen verglecihen.

Wenn Hardcore dann TCP

wenn hardcore dann über serielle schnittstelle... tcp ist bei weitem nciht hardcore und mithilfe von tcplistener und tcpclient ist dasauch innerhlab weniger zeilen implementiert

übrigens arbeitet wcf über webservices......
bei wcf kann man sogar bestimmen welchen weg man geht (soap/tcp/http) (erhm wenn das so wie in remoting ist)

dann sparst du dir die .NET 3.5 abhängigkeit

das ist ein punkt, der zwar stimmt aber auch noch andere überlegungen mit sich bringt. wenn die anwendung hübsch aussehen soll, dan wäre wpf z.b. recht gut geeignet. zudem hättest du dann ncoh die möglichkeit zumindest die oberfläche für einen webclient in silverlight nicht komplett neu implementieren zu müssen.

wenn angenehm und nicht edgy dann webservices

ich sage: wenn angenehm dann wcf ansonsten webservices.

war bisher in richtung TCP/IP tendiert evtl über UDP

Von UDP war eben doch die rede, davon wollte ich ihn abbringen.

wenn hardcore dann über serielle schnittstelle...

Macht irgendwie so gar keinen sinn oder? No comment

übrigens arbeitet wcf über webservices......

Nicht ganz richtig. WCF kann wie Webservices SOAP, damit sind es aber noch lange keine Webservices. Hinter WCF steckt viel mehr als SOAP Technologie. Nur weil SOAP in WCF Standart ist, nutzen sie nicht gleich Webservices. WCF und webservices nutzen und sind zwei völlig unterschiedliche tecnologien

gut, mag sein. leider durfte ich wcf bislang ncoh nciht einsetzen und daher fehlt mir noch wissen in diesem bereich.

also können wir uns auf wcf oder webservices als empfehlung einigen?^^

wobei meine empfehlung dennoch richtung .net 3.5 und wcf tendiert, da das auch andere vorteile mit sich bringt.

andererseits könntest du den server in .net mit webservices realisieren und in .net als auch in z.b. java einen client schreiben oder es zumindest ermöglichen. so könnten auch linuxfreaks mitspielen.

Für sowas nimmt man üblicherweise UDP. WCF bringt zwar von Hause aus keinen UDP-Channel mit, gibt aber einiges im Netz. Schön ist bei UDP die Multi-Cast-Option, sofern die Router mitspielen....

Webservice is the way to go. Da bin ich bei dir. Ob mit WCF oder reine Webservices, muss unter berücksichtigung der o.g. Punkte entschieden werden.

UDP ist hier definitiv der falsche weg, er will kein Ego Shooter oder RPG Programmieren, sondern sowas wie OGame mit dem unterschied das es n Client gibt... Ergo: Webservices / WCF, kein TCP oder UDP!

@svenson

kannst du begründen warum udp?
immerhin ist es doch eher wichtig das eine anweisung des spielers auch wirklich ankommt und zeit ist in diesem fall auch nciht so kritisch. daher frage ich mcih warum du udp empfiehlst.

kannst du begründen warum udp?

Es kommt auf das Spiel an. Rundenbasierte Spiele erfordern zwingend TCP (bzw. ein anderes "zuverlässiges" Protokoll), schon weil jeder Zug beim Server ankommen muss.

"Action"-Games erfordern kurze Antwortzeiten. Hier werden die eigenen Daten zyklisch zum Server übertragen und man empfängt die der anderen. Je häufiger desto besser. TCP macht in diesem Szenario aber keinen Sinn. Angenommen die Leitung stockt, dann kommt TCP zwar irgendwann durch, aber was nützt ein TCP-Paket, welches 2 Sekunden alt ist? Das wird der Server verwerfen müssen, sonst laggt das Game wie die Hölle.

UDP-Multicast hat zudem den Vorteil, dass das den Server von unnötiger CPU-Last und Ressourcen (u.U. Tausende von Sockets) befreit. Das gilt insbesondere für nicht-Massive-Games. Hier kriegt jeder die Daten aller anderen. Bei MMOG hat man das Problem, dass die Bandbreite nicht ausreicht, also man einen Subset der Daten übertragen muss. Bei manchen Spielen würde das bedeuten, ständig die Multicast-Groups zu ändern, und das macht keinen Sinn. Bei klassischen 32/64/128-Spieler Game wäre Multi-Cast jedoch erste Wahl.

Aber beim erneuten Lesen hab ich das gesehen:

Dabei wäre es kein problem wenn das datenpaket einmal 1500 - 2500 ms latenz hätte

Da scheint TCP wohl doch sinnhaft zu sein. Zeitkritisch sind die Pakete offenbar nicht.

Er empfiehlt wohl UDP, weil in der Spieleentwicklung meistens auf UDP mit eigenem Layer zurückgegriffen wird. So gibt es RakNet als Beispiel, das eine UDP Library mit Abstraktions Schicht zur Verfügung stellt, die sicherstellt, dass Pakete ankommen, in der man sicherstellen kann wie Pakete ankommen ( geordnet / ungeordnet ) usw.
Der Vorteil von UDP ist ganz klar die geschwindigkeit und der geringe Protokoll overhead in Hinsicht auf Datenvolumen und Kommunikation. Allerdings ist das in diesem fall meines Erachtens nicht nötig, da die UDP Libraries dazu eingesetzt werden große Mengen an Vektoren / Quaterniale in kurzer Zeit zwischen Server und Client zu synchronisieren um möglichst exakt synchronisierte Positionen und Richtungs Vektoren auf Client / Server seite zu haben. Da das hier wegfällt, braucht er sich den Stress nicht machen.

Wenn er sich doch dazu entscheiden sollte, gibt es einen guten UDP Layer für .NET bei Google Code. Ich kann mich nur nicht mehr so genau an den Namen erinnern. Die Library ist auf Performance ausgelegt, kann aber wie RakNet unter Nativen Applikationen sicherstellen, dass Pakete ankommen und wie. Ich halte UDP aber für Overkill in diesem Projekt.

@svenson

ich weiß was udp ist und wie es funktioniert sowie vorteile und nachteile.....möglichkeiten. das ist mir alles bekannt. ich möchte aber eine begründung haben warum du in diesem fall udp empiehlst und keine allgemeine aussage.

immerhin möchte er einen ogame-clon machen der über clients gespielt wird. ogame ist kein zeitkritisches spiel wie ein ego-shooter oder ein echtzeit-strategiespiel. ogame hat zwar keine runden aber auf 1-2 sekunden verzögerung kommt es auch nciht an. wichtig ist hier meiner meinung nach, das das packet überhaupt ankommt und verarbeitet wird.

ich möchte aber eine begründung haben warum du in diesem fall udp empiehlst und keine allgemeine aussage.

Ich kenne ogame gar nicht. Aber ich habe meine Aussage ja eh schon revidiert, wenn das gilt:

wichtig ist hier meiner meinung nach, das das packet überhaupt ankommt und verarbeitet wird.

Ob ankommen oder nicht ankommen kann hier mal vernachlässigt werden, UDP fällt raus. Wichtig ist, dass er mit wenig aufwand durch einsatz von .Net Technologien schnell und erfolgreich an sein Ziel kommt.

Da sag ich Webservice, ob nun der traditionelle oder WCF: egal! Nur eins: Webservice FTW!

Der Vorteil: Wenn das spiel wirklich so viele Spieler bekommen sollte kann der IIS Loadbalancing machen, das bekommt er also geschenkt. TCP ist damit auch raus.

wow find ich gut das ihr euch so für mich interessiert^^

erstmal zu linux - ich mag zwar kein linux aber linux nutzer ausschließen - bei einem massenonlinespiel wäre warscheinlich nicht sonderlich klug - desswegen müsste ich entweder eine linux kompitable technologie verwenden oder den client in java schreiben - wie unten genannt (allerdings sind meine javakenntnisse bisher sehr beschränkt).

Das ganze UDP usw. war nur so eine idee von mir ich hatte mir bisher nur angefangen mir technologien anzuschauen.

@Krieger: Das mit dem ogame klon will ich überhört haben^^

werde mir WCF anschaun - fände es aber gut wenn ihr mir eine konkrete empfehlung aussprechen könntet - denn wie euch sicherlich allen klar ist ist der netzcode bei dieser art von spielt die wichtigste Komponente (neben dem Spielkonzept)

@Krieger: Das mit dem ogame klon will ich überhört haben^^

*hust* das war ich ^^ hust hust hust

erstmal zu linux - ich mag zwar kein linux aber linux nutzer ausschließen - bei einem massenonline spiel wäre warscheinlich nicht sonderlich klug - desswegen müsste ich entweder eine linux kompitable technologie verwenden oder den client in java schreiben - wie unten genannt

in dem fall nimm nur webservices. programmier einen client in c# und wenn die community groß genug ist, dann schreibt sie von selbst einen java-client.

Sorry Krieger

*Anfang mit einarbeitung*

kein ding, viel spass dabei 🙂

@svenson
ogame hat zwar keine runden aber auf 1-2 sekunden verzögerung kommt es auch nciht an.

Meiner Erfahrung nach kommt es u.U. bei Ogame oder Die Stämme gerade auf 1-2 Sekunden an. Wenn sich dein.Tod aber sicher ist, dass das bei ihm keine Priorität hat is es ja egal. Denke nur du solltest dir sicher sein das es kein Problem wird später!

naja auf eine sekunde präzision kam man bei ogame fast nie.

tatsache ist, das man hier keine 100-300ms reaktionszeit, wie in ego-shootern z.b., benötigt wird.

wichtig ist hier, das wenn der user einen befehl gibt, das er auch ankommt. denn es wäre weitaus schlimmer, wenn der user auf z.b. angriff klick und sich dabei ein relativ präzises timing ausgearbeitet hat und dann merkt, das sein befehl garnicht angekommen ist und damit seine komplette angriffsstrategie über den haufen schmeißt.

außerdem kann man z.b. am client eine sendezeit in packet mit anbringen und der server kann dann zurückrechnen (natürlich nur innerhalb einer plausiblen zeitspanne). somit kann man den user eine echtzeitverarbeitung suggerieren.

aber das ist anwendungsarchitektur und soll hier kein thema sein.

tatsache ist: udp ist und bleibt ungeeignet. vermutlich ist soap hier das beste, da die interoperabilität hier am einfachsten ist im bezug auf java/.net/andere.....

bei einer aktiven und großen community kommen dann recht schnell sehr gute clients in anderen sprachen zustande (meist delphi,java oder .net)

Sollte das passieren, ist darauf zu achten, dass wie in MMO`s der Server einen plausibilitätscheck der vom client übermittelten werte macht und zusätzlich muss darauf geachtet werden, dass der Client ausschließlich die Präsentationsschicht der Applikation darstellt. Berechnungen sind, ab dem Zeitpunkt in dem User Clients entwicklen dürfen, ein Nogo im Client.

jupp. full ack.

das einzige was clients da machen dürfen sind statistische berechnungen oder irgendwelche hilfsanzeigen, die es dem user leichter machen irgendwelche entscheidungen zu fällen aber keine berechnungen, die den spielablauf direkt beeinflussen (kampfberechnung, produktions-fortschritte usw...)

der server muss der master bleiben.

also mit den 1500-2500 ms war gemeint das dies passieren kann - allerdings nicht die regel ist - soetwas kann zu stoßzeiten vorkommen. Aber ich denke da die community wohl kaum in den ersten monaten 10.000 mitglieder erreichen wird und ich sollte es doch mal soweit kommen warscheinlich das geld haben werde um einen entsprechenden server zu kaufen ^^.

von dem her ist denk ich mal sollten regulärenlatenzen bei ca. 600-1000 ms liegen

also bin zwar bisher noch nicht groß zum einarbeiten gekommen - hatte anfangs ein bisschen bedenken weil soap ja alleine schon für ein bool wegen den methadaten eine mehrere hundert bytes große nachricht benötigt.
Allerdings wenn man bedenkt das wenn ich 800 befehle pro minute vom server aus ausschicke ich so nur eine gesamtuploadlsast (bei sagen wir mal 400 byte pro nachricht) von 320 kb habe, zwar kommen hier wohl noch ca 50 byte pro nachricht für befehlsid usw dazu aber von der datenpacketgröße muss ich mir keine gedanken machen oder?

Könnte es evtl probleme wegen der Datenpacketgröße oder der erstellung oder decodierung von den XML-Dokumenten kommen?

Edit: Bin grade auf REST (http://de.wikipedia.org/wiki/Representational_State_Transfer)gestoßen - hört sich in meine ohren sehr sehr interessant an - was haltet ihr davon?
Edit2: Ok die idee mit REST ist doch nicht so toll^^