spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo alle miteinander,

seit längerem schon denke ich über den Entwurf von Onlinespielen nach, da dieses Gebiet mehr oder weniger aber für mich 'Neuland' ist hätte ich ein paar theoretische Fragen die man mir hier hoffentlich beantworten kann.

Und zwar habe ich an die generelle Server-Software-Architektur nachgedacht;
Um ein Spiel möglichst vielen Spielern gleichzeitig zugänglich zu machen, ohne dabei sehr Kostspielige Root-Server mit mehreren Clustern zu benötigen, dachte ich daran mit einem UDP Protokoll zu arbeiten, mit ausnahme von 'Kritischen' Interaktionen dann TCP.
Jetzt ist die Frage allerdings ob dieses so von mir erdachte Konzept überhaupt funktionieren 'kann'?

Folgendes habe ich mir ungefähr Vorgestellt:

Client meldet sich erstmalig per TCP beim Server
Server 'registriert' die Anmeldung mit allen Notwendigen Daten (reicht IP/Port?) und schliesst die TCP verbindung wieder.
Per Intervall oder Schleife werden nun alle Serverseitigen berechnungen 'VOM SERVER' per UDP zum Client geschickt.
Worauf der Client, wenn sonst keine Interaktion erfolgt, eine Art 'Ping' schickt.
Ausnahmen (Spieler vs Spieler Handel zB.) werden vom Client per TCP zum Server, berechnen/verarbeitet, und zurück geschickt.
Verbindungsdaten werden Serverseitig nach ablauf einer gewissen Zeit (oder erneuter anmeldung) 'entfernt'

Die Frage eigentlich ist. Kann der Server ohne permanente Verbindung (TCP) einfach per UDP daten zu einem PC schicken schicken?
Welche Daten benötige ich konkret?...

Das wären mal so meine groben Gedanken...
Da so keine permanente Verbindung vorhanden ist, sollte das die theoretisch mögliche Anzahl gleichzeitiger Nutzer von ansonsten per TCP (65535?) weitgehend erhöhen?

Gruss,
EP

Zitat

Woher hast du die Info über das TCP Limit (weil das ist für mich neu)?

Du hast recht, hab mich da (mitunter aus Mangel an Erfahrung) falsch ausgedrückt. Ich meinte natürlich die Limitierung von Gleichzeitig verbundenen TCP Sockets (so sollte es richtig heissen, oder?)

Zitat

Nachdem was ich so mitbekam sind gemischte Ansätze nie sonderlich erfolgreich gewesen.

Selbiges habe ich zwar auch gelesen, jedoch nicht wirklich verstanden.

Grundsätzlich ist es so das die Daten (grösstenteils) Serverseitig Verarbeitet werden und dann das 'Ergebnis' wieder zum Client gesendet wird. Meiner Idee nach sind es grösstenteils Daten die keine 100%ige 'empfangsquote' benötigen (ich nenn das einfach mal so ) wie zB. Monster HP wärend eines Kampfes, oder Positionsdatenabgleich... also was ich damit meine, wenn per UDP da mal ein paket zwischendrin nicht empfangen wird geht damit die Welt nicht unter. Anders aber wiederum sieht es eben bei 'kritischen' Sachen aus. Handel/Quests und ähnliches, daher dachte ich bei solchen sachen dann an TCP da dieses 'sicherer' ist.

2. Gedanke (kam mir vorhin nach meinem Post hier)
Grundsätzlich könnte man ähnlich vorgehen wie oben beschrieben
TCP: Client schickt TCP anfrage, Server nimmt an, Client schickt Aktuelle Daten, Server verarbeitet, Server schickt Ergebnis an Client, Server trennt verbindung.

Abgesehen davon das es sehr wahrscheinlich viel einfacher umzusetzen sein wird, dürfte das der allgemeinen Performance aber nicht gerade zu gute kommen??

Zitat von »BlueCobold«

TCP baut man aber nicht ständig auf und ab, daher ist das auch für Spiele kein Problem und je nach Typ des Spiels und der Wichtigkeit der Daten auch absolut Gang und Gebe.

In der Regel wird das wohl so gehandhabt, einmal verbunden sollte es eine ausreichende Performance sowie Sicherheit der Übertragung gewährleisten.

Problem bei der Sache sehe ich hierbei allerdings mit der Geschichte der 'Wieviele Sockets/Threads/Verbindungen' kann ich gleichzeitig handlen...

Wo wir bei meiner grundlegenden Frage sind, was kann ich tun um eine theoretische 'Echtzeit-Massen-Multispieler-Server-Architektur' ohne die hardwareseitigen Ressourcen aufzubauen?

Es geht mir hierbei in erster linie erst einmal um das theoretisch grundlegende Verstaendnis einen sehr guten 'Mittelweg' zu finden, nach möglichkeiten nicht erst dann wenn (falls) es zu spaet ist und die nutzerzahlen 'explodieren' (Im schlimmsten Fall sorgen eben viele gleichzeitige Nutzer zu grösseren 'Verzögerungen' (Lags) welche ansonsten aber nicht limitiert sein 'sollte')

Ich denke am einfachsten ist wirklich ein TCP Protokoll (mit gehaltener verbindung), wobei die Anzahl gleichzeitiger nutzung dann aber Hard- und OSS abhängig bis zu einem gewissen Punkt eingeschränkt sein wird...

Reines UDP scheint mir gerade bei 'kritischen' Sachen nicht ganz ohne in der Programmierung (hier muessten dann recht viele Sicherheitsvorkehrungen getroffen werden?!)

Ich hab im laufe der Wochen zwar immer wieder mal viel gelesen, nur ist dieses Thema doch recht komplex und wie so oft gibt es auch hier nicht 'DIE LÖSUNG' sondern scheinbar endlos viele Möglichkeiten derartiges umzusetzen...

Deine Nachricht enthält folgende zensierte Wörter: res(s)ourcen (sehr komisch )