TCP-Server online Spiel
-
Hallo, ich habe eine Frage paar an die Herangehensweise von online Spielen. Es soll eine Art Super Mario mit RPG Elementen sein. Wo es ein MMO typisch Login Menü gibt beim Start des Spiel, um seinen Character weiterzuspielen.
Meine Fragen dazu:
1. Sollen die gesamten Informationen eines Spielers in eine Datei gespeichert werden oder soll ich eher alle Spieler in eine große Datei gespeichert werden? So wie in eine große Exceltabelle, als vergleich?
Ich tendiere zum ersten Gedanken.2. Wann und wie viel Information soll der TCP-Server bekommen, ich befürchte das zu viele Daten den Clienten überfordert. Vor allem bei einer kleinen Anzahl von Spielern.
3. Ich benutze die library WinSock2 dazu ist das der richtige Weg?
-
1. Sollen die gesamten Informationen eines Spielers in eine Datei gespeichert werden oder soll ich eher alle Spieler in eine große Datei gespeichert werden? So wie in eine große Exceltabelle, als vergleich?
Ich tendiere zum ersten Gedanken.Datenbank?
2. Wann und wie viel Information soll der TCP-Server bekommen, ich befürchte das zu viele Daten den Clienten überfordert. Vor allem bei einer kleinen Anzahl von Spielern.
Client mit zu vielen Daten überfordert? Vor allem bei kleiner Anzahl von Spielern?
3. Ich benutze die library WinSock2 dazu ist das der richtige Weg?
Okay, dümmer geht's jetzt echt nicht mehr..
-
jops schrieb:
3. Ich benutze die library WinSock2 dazu ist das der richtige Weg?
Okay, dümmer geht's jetzt echt nicht mehr..
Weil?
-
DrBrokolie schrieb:
1. Sollen die gesamten Informationen eines Spielers in eine Datei gespeichert werden oder soll ich eher alle Spieler in eine große Datei gespeichert werden? So wie in eine große Exceltabelle, als vergleich?
Ich tendiere zum ersten Gedanken.Ich denke eine Datei pro Spieler ist einfacher zu implementieren, zumal man wahrscheinlich spätestens beim Spieler-Logout die Daten wegspeichern, und bei einem Login wieder laden möchte. Das ist umständlicher, wenn man eine Datei für alle Spieler hat - besonders wenn man vermeiden möchte dass jedes mal bei einem Login/Logout eines einzigen Spielers die gesamte Datei gelesen/geschrieben wird (obwohl das möglichweise bei den aufgrund deiner Beschreibug zu erwartenden Datenmengen nicht wirklich relevant sein dürfte).
Eine etwas flexiblere Lösung könnte eine Datenbank sein. Da würde ich bei kleinen Datenmengen erst einmal so etwas wie SQLite empfehlen. Damit hast du euf einen Schlag ein recht mächtiges Dateiformat für Spieler- und sonstige Daten zur Verfügung und musst dich nicht damit herumschlagen, Textdateien zu parsen oder dein eigenes Binärformat zu stricken - nebenbei ist so eine SQLite-Datenbank auch dann noch ziemlich effizient, wenn mal richtig viele Daten zusammenkommen und du kannst die Daten relativ einfach via SQL miteinander verknüpfen.
DrBrokolie schrieb:
2. Wann und wie viel Information soll der TCP-Server bekommen, ich befürchte das zu viele Daten den Clienten überfordert. Vor allem bei einer kleinen Anzahl von Spielern.
Das ist eine sehr allgemeine Frage die man mit so wenig Information nicht wirklich sinnvoll beantworten kann. Dennoch, aus meiner Sicht:
- der "Server" sollte natürlich alle spielrelevanten Daten zur Verfügung haben, da er bei z.B. einem Spieler-Login dem Client alle Daten senden muss, damit dieser sich in den selben Spielzustand versetzen kann in dem andere, bereits eingeloggte Spieler bereits spielen (Synchronisation).
- Ein weiterer Grund weshalb der Server alle Daten benötigt ist eine Plausibilitätsprüfung der vom Client kommenden Datenpakete: alle Datenpakete, die aus dem Netz kommen können potentiell manipuliert sein. Wenn ein Client z.B. eine Spieler-Position meldet, die er aufgrund seiner vorherigen Position unmöglich erreichen kann, dann hat man es mit großer Wahrscheinlichkeit mit einem Cheater-Datenpaket zu tun
- Bei den Clients selbst, kann es durchaus vorteilhaft sein, wenn diese mit so wenig Datenverkehr wie möglich belastet werden. Ein schlankes Protokoll erlaubt es, dass mehr in der Welt "passieren" kann, ohne dass das Spiel für Leute mit einer schwächeren Leitung unspielbar wird. Generell würde ich sagen, dass man nur nicht-deterministische Ereignisse übertragen sollte, also nur das was sich nicht "berechnen" lässt. Das sind im Allgemeinen nur diejenigen Ereignisse bei denen ein Spieler irgendetwas mit seinem Eingabegerät macht (springen, schießen, bewegen, etc.). Wenn man in so einem Spiel z.B. einen Schuss abfeuert, dann muss man nicht für jeden Pixel den das Projektil zurücklegt einen neue Position übertragen - schließlich bewegt sich das Projektil berechenbar - es reicht der Zeitpunkt, zu dem es abgefeuert wurde und dessen Richtung. Wenn Server und Client die Bewegung des Projektils mit dem selben deterministischen Algorithmus berechnen, muss das Endergebnis zwangsläufig dasselbe sein (natürlich nur bis zu dem Zeitpunkt wo etwas nicht-deterministisches dazwischenfunkt - z.B. wenn ein anderes Spieler in den "Schuss springt").
Noch eine Anmerkung: "Zufallsereignisse" von einem Zufallsgenerator sind natürlich auch "berechenbar", da die (Pseudo-)Zufallsgeneratoren die man dafür verwendet deterministisch sind und wenn sie auf Client und Server den selben Algorithmus und "Seed" verwenden, die selben Ergebnisse liefern (sowas müsste man also auch nicht übertragen).DrBrokolie schrieb:
3. Ich benutze die library WinSock2 dazu ist das der richtige Weg?
Ich persönlich finde die Windows-API jedesmal furchtbar, wenn ich damit arbeiten muss und sie hat obendrein den Nachteil, dass sie nicht gerade plattformunabhängig ist. Möglicherweise ist eine portable Alternative (Boost ASIO, SFML Network, oder was es da sonst noch geben mag) die bessere Wahl.
Gruss,
Finnegan
-
Ich wuerde dir gern den Tipp geben, erstmal etwas kleiner zu denken. Du hast von den Grundlagen keine Ahnung und willst gleich mit einem riesigen Projekt einsteigen, sowas geht meist gruendlich schief. Mach doch erstmal ein 2/4 Spieler Spiel fuer LAN, um ein bisschen dazuzulernen.
-
Oder auch erstmal was noch viel einfacheres http://tinodidriksen.com/2003/05/06/but-can-you-make-pong/
