Multiplayer...

[Dirty Oerti]

]Auch eine Serverfarm? Also Physik hab ich folgendermaßen vorgestellt: Server 1 hängt mit eth0 am Inet, und mit eth1 an einem Switch, Server zwei hängt ebenfalls an diesem Switch, und berechnet alles (Physik, Wettersystem, Zeitzonen(wegen nachtmodus etc.(falls die Engine das auch optisch darstellen kann, ich bin nicht der beste in sachen GUI/3D, bin halt ein Konsolenkind )) Und kann dieses über 100MB/s (bzw. 1000MB/s wenn ich einen Gigabitswitch zufassen bekomme) Zu Server 1 senden, der die Netztwerksachen verwaltet.

Das ist ein Scherz, oder? ^^
Wenn du ein Multiplayerspeil mit evlt mehr als 100 Mitspielern in EINEM Spiel hast, dann die Spielphysik zentral auf einem Server zu berechnen ist Wahnsinn.
Erstens wird das dein Server kaum mitmachen.
Zweitens müssen die Ergebnisse, die der Server errechnet hat, ja auch an jeden einzelnen Clienten geschickt werden.
Was die Netzwerkverbindung nochmals heftig belastet.

Ich könnte es ja auch z.b. so machen, das bei Spielstart erstmal eine kleine Singeplayer mit NPCs zur Verfügung steht, während man diese Spielen kann, wird im hintergrund der Rest gedownloadet...

Ein ordentliche Welt mit Modelldaten und Texturen und allem drum und drann kann gerne mal die 500 MB übersteigen. Bei großen Welten mit guter Grafik (=hochauflösende Texturen, viele Vertexe) kommst du auch gerne auf mehr als 1,5 GB (es sollen ja ca 100 Spieler in der Welt Platz finden -> Die Welt muss entsprechend groß sein).
Wenn ich mir das vorm Spielen runterladen müsste, dann würde ich mehrere Stunden mit deinem NPC verbringen, wozu dieser schon enorm gut programmiert und das Spiel enorm spannend sein müsste....

So, mal eine Technische Frage:
Sollte ich die Anfragen der Cliente quasi Batchmäßig in einem anderen Thread verarbeiten, oder direkt?(Dateien ausgenommen, die werden über FTP versendet)

Das musst du dir überlegen. Einige Netzwerkbibliotheken (SDL...) stellen eine Funktion zur Verfügung, die dir bei sowas hilft. Das Problem liegt ja darin, dass das "Warten auf Daten" eine blockierende Funktion ist und damit das ganze Spiel anhalten würde.
Entweder du realisierst es über diese Funktion (Socketsets..) oder du lagerst das Empfangen/Senden von Daten in einzelne Threads aus. Heißt für jeden Spieler ein "Kommunikationsthread".
Dass musst du dir aber auf jedenfall genau durchdenken!

[Jside]

Das musst du dir überlegen. Einige Netzwerkbibliotheken (SDL...) stellen eine Funktion zur Verfügung, die dir bei sowas hilft. Das Problem liegt ja darin, dass das "Warten auf Daten" eine blockierende Funktion ist und damit das ganze Spiel anhalten würde.

Ne, also die Sockets progge ich mit:

#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>

nix mit SDL viel zu verwurschtelt...(mal davon abgesehen, das der Spass beim Portieren auf M$s extrawurscht Winsock beginnt...)

Also ich hab jetzt eine while(TRUE) Schleife, die den Clientcommand aus eth0 einließt, dekodiert, und Ausführt, Dateien werden über ein anderes Programm über einen anderen Port versendet(auf 5000 Läuft der Mainternance Server daemon, auf 5001 - 5010 ein Dateiserver, der für(zurzeit) 10 Leute parallel Downloadienste für Modelle bereitstellt...). Das Serverprogramm braucht im "nix'tu" Modus nur 15kb RAM, sieht doch schonmal gut aus
Der Server auf Port 5000 kann bereits die Positionen zu anderen Clients senden, an dem System für Items(etc) bastle ich zurzeit...

Erstens wird das dein Server kaum mitmachen.
Zweitens müssen die Ergebnisse, die der Server errechnet hat, ja auch an jeden einzelnen Clienten geschickt werden.

Die Menge machts, aber du hast recht, das dann alle Physikdaten wieder zum client müssen hab ich vergessen, ich denke mal Clientseitig Kollision + Schwerkraft dürften reichen, der Server braucht dann höchstens ab und zu mal schnell eine Position zu korrigieren(natürlich im cm bereich)....

Wenn ich mir das vorm Spielen runterladen müsste, dann würde ich mehrere Stunden mit deinem NPC verbringen, wozu dieser schon enorm gut programmiert und das Spiel enorm spannend sein müsste....

Naja habe da so den Gedanken, das die Texturen und Modelle in verschiedenen Auflösungen vorliegen, und der User sich das heraussuchen kann, was seine GraKa verkraftet...

Entweder du realisierst es über diese Funktion (Socketsets..) oder du lagerst das Empfangen/Senden von Daten in einzelne Threads aus. Heißt für jeden Spieler ein "Kommunikationsthread".

Nur, dass CPUs glaubisch nicht mehr als 255 Threads verkraften(hab ich mal irgendwo gelesen)

[Dirty Oerti]

(mal davon abgesehen, das der Spass beim Portieren auf M$s extrawurscht Winsock beginnt...)

Die SDL ist plattformunabhängig

Downloadienste für Modelle

Ich bleib dabei: Lass das lieber bleiben, während dem laufenden Spiel Ressourcen zu verteilen. Du kannst ja im Spiel eine Art "Shop" einrichten, aus dem man sich Modelle lokal herunterladen kann. (Wobei das dazu führt, dass jeder Client genau diese Modelle dann auch haben muss, was, denke ich, im Schwachsinn endet )

Die Menge machts, aber du hast recht, das dann alle Physikdaten wieder zum client müssen hab ich vergessen, ich denke mal Clientseitig Kollision + Schwerkraft dürften reichen, der Server braucht dann höchstens ab und zu mal schnell eine Position zu korrigieren(natürlich im cm bereich)....

Wie schon (iwo) mal erwähnt: Der Server ist dafür zuständig, die Daten zu verteilen.
Die Berechnung, also Physik (Kollision, Schwerkraft, Kräfte, etc), BOTs (Pfadsuchen), Grafik (Modelle animieren), etc müssen die Clients übernehmen.
Das einzige, was der Server evtl tun sollte ist eine "Validierung" durchführen.
Das heißt der Server weiß: Die maximale Geschwindigkeit eines Spielers ist 15 Einheiten/Sec. Wenn sich nun die Position des Spielers drastisch dazu verändert, kann der Server korrigierend eingreifen.
Sozusagen als Schutz davor, dass sich jemand dein Source lädt, die Variable intern ändert und dann das Spiel selbst kompiliert. Allerdings ist das ganze recht komplex, immerhin musst du so Sachen wie einen Sturz oder evtl "Teleportationsmöglichkeiten" oder auch nur schnellere Vehikel oder Untergründe (laufen mit dem Förderband) mit einberechnen.

Naja habe da so den Gedanken, das die Texturen und Modelle in verschiedenen Auflösungen vorliegen, und der User sich das heraussuchen kann, was seine GraKa verkraftet...

Es ging mir ja nicht um die Karte, sondern um die Menge, die ich dann herunterladen müsste, wovon meine Internetverbindung wenig halten würde.
Aber du hast schon Recht: Grafiken in versch. Auflösungen anzubieten ist gut. Allerdings sollte man das lokal aussuchen können.

Nur, dass CPUs glaubisch nicht mehr als 255 Threads verkraften(hab ich mal irgendwo gelesen)

Das wär mir neu
Auf meinem Rechner laufen gerade ca 100 Prozesse, davon haben sicherlich mehrere Threads.
Heißt, ich komm bestimmt an die 255 Threads ran (vorallem wenn ich mehrerer Benutzer anmelde, alle grafisch).
Das halte ich also für ein absolutes Gerücht

Die CPU merkt von den Threads ja außerdem wenig. Um die Threads kümmert sich das Betriebssystem.

[Jside]

Ok, ich hab jetzt erstmal das gesammte Netztwerksubsystem in meinen Source-Ordner "obsolete" geschoben; Ich Implentiere alles Netztwerkzeug zusammen mit den GFX Gegenstücken daher, ich bin gerade an einem Texturmanager, und baue jetzt eine Funktion ein, um eine Fehlende Textur von einem Server zu holen, da es irgendwie keinen Sinn macht einem Server zu sagen, er soll die Coordinaten weiterversenden, ohne das die Clients etwas großartiges damit anfangen können... Außerdem setzte ich das jetzt mit SDL_net um(bis auf den Server, wer will schon einen Windows -Server ? )

Das Programm hat folgenden Ablauf:
SDL Init und Fenster erstellen;
Hauptmenu zeigen
->Optionen(is klar)

Spiel starten:
Texturen laden, wenn nicht vorhanden auf requiredFiles Liste setzen
Modelle laden, wenn nicht vorhanden auf requiredFilesListe setzten
Network Init
Benutztername und MD5 Hash des Passwortes zu Server senden (Port 5000)
->Wenn Server return -1 Registermenu/Loginmenu einblenden
Ansonsten -> Informationen empfangen(Lebenspunkte, Items,etc)
(Ich werde warscheinlich alles auf einer MySQL Datenbank des Servers abspeichern, und die Benutzter speichern jediglich eine nicht direkt Ladbare Binäre struct auf ihren Rechner(falls der Server mal offline gehen sollte, kann man die Informationen via Server Software in eine (eigene)MySQL Datenbank laden)(kann man auch, wenn man einen eigenen Server betreibt))
Wenn Dateien benötigt werden via 5001 Port des Servers nachladen, und Lade Dialog anzeigen
OpenGL Init(und dabei Ladedialog anzeigen)
Im Hintergrundthread im sec/milisec Takt XYZ und Animationstate anderer Spieler abrufen, und Synchronisieren (Port 5002)(Der Server schaut, was im Radius ist)
Im Haupthread bei Interaktionen(Itemtausch etc) z.b. eine ToggleItem struct zum Server senden(und Clientseitig die Itemstruct löschen)(enthält Daten des Absenders, und empfängers) wobei der Server die Einträge der MySQL Datenbank vertauscht/löscht, und das entsprechend neue Item wieder zum Spieler sendet(Port 5003)

Kurtz knapp: Jeder (Netztwerk-)Vorgang bekommt einen eigenen Port, das damit z.b. wenn der Spieler ein Item tauscht nicht als rückgabe die XYZ vorliegen, sondern nur die Daten, die vom entsprechendem Port abgerufen wurden(was wiegesagt immer ein anderer ist)... Außerdem kann so der Server alles besser handlen, als alles-über-einen-Port-Parser-chaos...

Zusammengefasst:
5000: Login/Logout Datenbankabrufe
5001: Dateien
5002: Coordinaten
5003: Items/etc
5004: Trigger(wenn man vor ner Tür steht, die auf geht, muss as ja auch bei jedem Client der Fall sein)
5005: Chat
5006: Bereiche Reservieren(wenn jemand z.b. einen kleinen Platz reserviert(darf natürlich nicht jeder), dürfen da natürlich keine anderen reinlatschen)

Der Vorteil an MySQL ist, das sich der User auch z.b. über me PHP Website Registrieren kann/Sein Profil einsehen ändern kann was ich als sehr exquisite empfinde...

[cloidnerux]

Ähm, was soll das für ein Spiel werden, eher so in richtung World of Warcraft oder 0815 Ego-Shooter/andere?
Weil was du heir betreibst(Datenbank, 7Ports,etc.) ist schon, wie ich finde Overkill. Überlge dir doch erstmal was du Überhaupt zu übertragen hast-> daher was für ein Spiel soll es werden. Wie groß werdend ie einzelen Dateien...
Du stützt dihc momentan auf irgendwas nicht exsistentem. Du hast zwar ein OpenGl fernster, aber ohne inhalt. OpenGl besitzt meines wissen über ekien Funktion ein Modell direkt zu laden, du musst dir alle Funtktionen dazu selber Programmieren und damit meine ich den ganzen kram mit Animation, bones etc.
Dann musst du auch eine Physikengine programmieren und dann ncoh das speil oben drauf und das ist schon ne menge arbeit. Wenn du jezt nämlich mit dem Server anfängst, bekommst du nachher Probleme beim implementieren des Speils, da du das Spiel an den Server anpassen musst und nicht Umgekehrt.

[Jside]

Najagut, mit den Ports sagen wir's mal so: Was ist einfacher? 7 Ports, oder ein Port mit nem fetten Parser. der nebenbei auch doppelt so viele Ressourcen braucht
Oder was ist leichter: Ne MySQL Datenbank, oder ein Dateiparser für Save&Load

Wie ich schon oben gesagt habe, ich habe alles "weggeschmissen" und bastle jetzt eine Engine, die nebenbei bestimmte Netztwerkfunktionen fest Implentiert hat Ich bin Zurzeit bei 2D Funktionen(Gerade bei smoothen Bewegungen von Rechtecken...)...

[Dirty Oerti]

Außerdem setzte ich das jetzt mit SDL_net um(bis auf den Server, wer will schon einen Windows -Server ? )

Ich raffs nicht ^^
Warum sollte SDL_net und Linux nicht zusammen auf einem Server gehen?

Code: Alles auswählen

sudo aptitude install sdl_net

und gut?

[Jside]

Außerdem setzte ich das jetzt mit SDL_net um(bis auf den Server, wer will schon einen Windows -Server ? )

Ich raffs nicht ^^
Warum sollte SDL_net und Linux nicht zusammen auf einem Server gehen?

Code: Alles auswählen

sudo aptitude install sdl_net

und gut?

Ich meinte eigentlich damit "Wer will schon auf einem Server Windows Installieren" ^^

[Dirty Oerti]

Ja, aber wieso willst du es dann NICHT mit sdl_net machen??
sdl_net gibt es, wie gesagt, auch für Linux (und damit auch für Linux Server)

[Syntov]

So noch eine kleine Anmerkung zur sicherheit:

Benutztername und MD5 Hash des Passwortes zu Server senden (Port 5000)
->Wenn Server return -1 Registermenu/Loginmenu einblenden

Das mit dem MD5 hash senden ist eine schlechte idee.
du denkst wenn jemand mitsnifft kann dieser das PW nicht auslesen. aber er bracuht ja das PW gar nicht. Er muss nur den MD5 hash senden.
Falls jemand durch eine Sicherheitslücke die Membertabelle aus der Datenbank downloaden kann hat er alle MD5 hashes und kann sich als einen beliebigen Member ausgeben.
Lösungsvorschlag:
-Das PW wird eingegeben
-PW wird über eine Verschlüsselte Verbindung übertragen
-PW wird in einen sha256 hash umgewandelt und verglichen.