MMO Spieleserver

[Tomarr Sovai]

Hi zusammen.

Ich möchte mich an ein neues, zugegeben sehr ehrgeiziges, Projekt wagen.

Ich möchte ein Spiel programmieren an dem mehrere Spieler gleichzeitig spielen können, also ein sogenanntes MMO.

Jetzt habe ich allerdings ein paar Ideen wie ein Server für so ein Spiel aussehen könnte, scheiter jedoch immer wieder an Kleinigkeiten.

So ist eigentlich die größte Schwierigkeit momentan dafür zu sorgen das jeder eingelogte Client gleich behandelt wird.

Ich dachte nun das ich eine Hauptschleife schreibe die nichts anderes macht als die Anmeldung eines Clients entgegen zu nehmen. Logt sich nun ein Client ein wird für diesen ein extra Thread eröffnet der sich nur um einen einzigen Client jeweils kümmert.

Nun ergeben sich daraus allerdings mehrere Fragen und Probleme.

1. Wieviele Threads kann so ein durchschnittsserver eigentlich ab, oder gibt es eine allgemeine Grenze die zu beachten ist?

2. Wie kann ich jeden Thread dazu bringen das sie einen Server mit eigenem Port aufmacht? Und zwar so das keiner dopelt vergeben ist, weil das geht ja nunmal leider nicht, auch nicht im Try und Error Verfahren, und wenn sich jemand ausloggt muss der Port ja wieder zur Verfügung stehen.

3. Die Kommunikation der Threads untereinander. Es kommt ja oftmals vor, wie es halt in einem Siel so ist, das zwei Spieler gegeneinander kämpfen. Beide Threads müssten dazu die selben Daten erhalten, und das recht sicher. Treffer, Art der Waffe, Bewegungen, Blickrichtung usw. muss ja alles für alle an den Bildschirmen gleich aussehen. Wie bekommt man sowas hin bei einem Multithread Server?

So, das waren erstmal die einfachen Fragen. Ich hoffe ihr könnt mir da weiter helfen, oder ein paar Denkanregungen verschaffen.

Danke schonmal im Voraus.

[Deeem2031]

1. Für jeden Client einen Thread halte ich für übertrieben. Es gibt zwar Programm mit sehr vielen Threads, aber du musst bedenken das alle Threads selber Speicher benötigen und die Verwaltung der Threads nimmt auch ein wenig zeit in Anspruch.

2. Jeder Client soll einen eigenen Port bekommen? Es gibt aber nur 65535... Falls du das wirklich so machen willst wäre Try and Error aber eigentlich am besten - wieso sollte das nicht funktionieren? Du musst ja sowieso kontrollieren ob der Port nicht von einem anderen Programm genutzt wird.

3. "Global" heißt auch dass es noch in Threads verfügbar ist. Wobei es sicher besser wäre nicht direkt auf die Variablen zuzugreifen sondern eine Schnittstelle für die threads bereitzustellen. Das Auslagern der Daten in eine externe Datenbank wäre sicher auch möglich.

[Tomarr Sovai]

Naja, für jeden Client einen Thread hielt ich erstmal für einfacher als immer zu schauen ob ein Thread noch clients aufnehmen kann oder nicht. Und zudem sind dann ja Spieler benachteiligt die sich, sagen wir mal, einen Thread it 30 Leuten teilen gegenüber jemanden der einen Thread für sich hat. Natürlich hätte das alerdings wiederum den Vorteil das man eine Art CoServer bereitstellen könnte der, wenn der Hauptsever voll ist, die Clients annimmt und auf komplett anderer Hardware läuft.

Was die Menge der Ports angeht, ich gehe einfach mal ganz frech davon aus das eh nie mehr als 1000 Spieler gleichzeitig an dem Spiel teilnehmen. Oder vielleicht doch? Hmm, gute Frage.

Ich weiß das Global auch für Threads gilt. Nur über Variablen die Daten auszutauschen kommt mir etwas ungeschickt vor. Von der Logik her erfüllt es auch nicht wirklich den Zweck. Nehemn wir mal als Beispiel eine einfache Variable, die würde ja von jedem Thread dann überschrieben werden. Nehmen wir ein Array wo jeder Thread seinen eigenen Zugriffsbereich hat kommt wieder das alte Problem auf, welche beiden Zellen in dem Array interagieren gerade?

So einfach ist das also gar nicht. Odr ich mach mir einfach zu viele Gedanken dazu, das kann natürlich auch sein.

Aber wie funktioniert das Ganze denn z.B. bei WoW? Da sind ja auch wesentlich mehr Spieler online glaube ich... habs selber noch nie gespielt. Aber eigentlich ist das genau das vom Prinzip her was ich gerade suche. Viele Spieler mit interaktion.

[ZeHa]

Also ich würde einen einzigen Thread machen, der immer nur abhört, ob sich einer neu verbindet usw., und das eigentliche Management würd ich dann im Hauptthread oder einem einzigen anderen Thread machen. Für jeden Client einen eigenen Thread, weiß nicht ob das sein muß.

Und für jeden Client einen eigenen Port brauchst Du auch nicht, zumindest fällt mir dafür jetzt kein Vorteil ein.

[gnasen]

Threads schaufeln, von MultiCore Systemen abgesehen, im Vergleich zu einer Hauptschleife auch keine versteckten Ressourcen frei. Und ganz im Ernst, Threads sind eine böse Sache, vor allem ein Debuggen mit Threads ist fast unmöglich. Irgendwo nen kleiner Fehler und es wird zwangsläufig crashen. Vllt nicht bei dir, aber bei wem anders.

[THEEX]

Du brauchst keine Threads für jeden einzelnen Client und noch weniger eigene Ports. Ich kenne kein einziges Multiplayerspiel, bei dem jeder Client einen eigenen Port nutzt. Du erstellst einfach einen Server, dabei mußt ja schon einen Port angeben und läßt alle Clients am Server eben mit diesem Port verbinden. Da jeder Client eine eigene ID bekommt, kannst Du mit dem Server die Clients unterscheiden.

Solltest Du trotzdem verschiedene Ports nutzen wollen, mußt Du auch verschiedene Server öffnen. Da bestünde die Möglichkeit, daß beim Conncten eines Clients, der Server einen weiteren Server mit neuen Port auf macht und dem Client ein Kommando schickt, daß dieser am Server mit dem neuen Port conncten soll. Für die Ports könntest Du eine Liste anlegen, worin die schon vergebenen Ports enthalten sind, damit kein Port mehrmals verwendet wird. Und wenn neue Server/Clients dazu kommen, wird die Liste erweitert. Aber wie gesagt, das halte ich weniger sinnvoll und verkompliziert das Ganze meiner Meinung nach unnötig!

[Tomarr Sovai]

Meine Bedenken an einem einzigen Thread sind halt nur die...

Es ist ja eine einzige Endlosschleife, die wartet auf neue Clients, Nimmt die Aktionen der Clients entgegen wie Bewegungen, Aktionen, Chaten und so weiter. Gleichzeitig sendet sie entsprechende Aktionen an alle Clients, wie eben halt die Bewegungen der anderen, Umgebungsgegebenheiten wie Häuser, Bäume, deren Ressourcen, Unterhaltungen usw. Das muss doch innerhalb einer einzigen Schleife unheimlich lange dauern und tierisch lagen.

Ich weiß das es bei MMOs sogenannte Zonenserver gibt. Ich weiß halt nur nicht wie diese funktionieren. Aber wie der Name Zonenserver schon sagt kann es ja kein ganz normaler Server sein.

Wird auf jeden Fall noch recht schwierig denke ich. Gibt a noch so viel zu beachten, stehe ja erst am Anfang.

[Kaeru Gaman]

eventuell wäre es nützlich für dich, wenn du erstmal die kommunikationsbasis für ein MOG ausprobierst, also dich auf 8-12 spieler beschränkst.
das wird dir einiges an erfahrung bringen was mögliche protokolle etc. betrifft.
jetzt gleich mit nem >1000 User game loslegen zu wollen halte ich für eine nicht so tolle idee...

beim ersten sprung ins kalte wasser sollte man nicht aus nem flugzeug in den marianengraben springen,
vom beckenrand in den pool tuts auch.

[Tomarr Sovai]

eventuell wäre es nützlich für dich, wenn du erstmal die kommunikationsbasis für ein MOG ausprobierst, also dich auf 8-12 spieler beschränkst.
das wird dir einiges an erfahrung bringen was mögliche protokolle etc. betrifft.
jetzt gleich mit nem >1000 User game loslegen zu wollen halte ich für eine nicht so tolle idee...

beim ersten sprung ins kalte wasser sollte man nicht aus nem flugzeug in den marianengraben springen,
vom beckenrand in den pool tuts auch.

Ja da hast du schon recht. Es soll ja eh ein Open Source Projekt werden, eben halt damit ich nicht alles wissen muss, zudem kann ich als Einzelner ja auch nicht alles schaffen, Programmierung, Grafik Sound usw.

Ich will halt nur erstmal ein paar Grundlagen schaffen worauf die anderen Teilnehmer aufbauen können. Vielleicht reicht es ja wirklich erstmal ein kleines Programm zur Verfügung zu stellen das erstmal kennzeichnet "Das soll der Server werden und das der Client". Alles andere wird ja wahrscheinlich eh zehn mal oder mehr wieder umgekrämpelt. ^^

[ZeHa]

Du weißt aber schon, daß Threads nicht "wirklich" parallel laufen, oder? Das bedeutet, ob Du nun eine einzige Schleife hast mit 1000 Clients, die nacheinander abgearbeitet werden, oder 1000 Threads mit je einem Client, macht - vorausgesetzt, die Bearbeitungszeit für jeden Client ist gleich lang(*) - keinen Unterschied. Im Gegenteil, Du hast sogar weniger Kontrolle drüber, da kein Thread wissen kann, ob die anderen alle schon fertig sind mit Senden. Bei einer großen Schleife kannst Du zumindest Aktionen durchführen, die exakt dann passieren, wenn alle Clients abgearbeitet wurden.

Ich würde, wie gesagt, lediglich einen Hintergrund-Thread haben, der auf neue Clients Ausschau hält und mit denen dann verhandelt. Aber sobald sie "drin" sind, sollten sie ebenfalls in die große Schleife mit aufgenommen werden.

(*) Natürlich darfst Du für einen Client keine Aktionen durchführen, die die Schleife komplett blockieren. Also z.B. auf Antworten seitens des Clients warten und solche Scherze. Aber für dieses Warten hast Du ja Deinen Hintergrund-Thread.