Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

11

14.09.2008, 14:59

Ich rede hier nicht von Blizzard.
Dort hat eh kein Schwein Zugriff auf DBs.

Ich rede von Privatservern.
Und dort ist alles textbasiert.
Rechtschreibfehler sind beabsichtigt...
Wer welche findet darf sie behalten.

Kommt zur Dunklen Seite der Macht wir haben Kaugummis und Kekse

12

14.09.2008, 15:00

Die Language Packs sind für Menü und Interface.

EDIT:

BACK TO TOPIC!!!

Was schlagt ihr vor??
Rechtschreibfehler sind beabsichtigt...
Wer welche findet darf sie behalten.

Kommt zur Dunklen Seite der Macht wir haben Kaugummis und Kekse

Anonymous

unregistriert

13

14.09.2008, 15:04

geisi1909
Momente mal, ich muss anderthalb Gigabyte (!!!) runterladen wenn ich neben meiner deutschen Version ein LanguagePack für Englisch installiere und das nur für das Menü und Interface? Dann frag ich mich, wieso in den MPQs haufenweise Questtexte enthalten sind und Quests erst mit neuen Patches dazu kommen?

Und in Ethereal hab ich noch nie gesehen das in einem Bytestream Texte enthalten sind (Außer von Chat), nur Positions-, VoiceChat- und Aktionsdaten.

edit: Ich schlage vor du machst es wie Blizzard: Questtexte, Items und co nur per Patches ausliefern und in einer Datenbank (wenn man sowas überhaupt braucht) nur das sichern, was für ein Weiterspielen benötigt wird, wenn man es beendet. Alles andere kommt einer DoS-Attacke schon nahe.

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

14

14.09.2008, 18:10

Also. Wir nutzen auch das DB<->Server<->Client Prinzip. Es ermöglicht das konsistent halten der Daten, Änderungen sind schnell durchgeführt und das anfängliche laden braucht nicht lange. In der DB steht dann auch drinne, wo die entsprechenden Mediadateien auf dem Client zu finden sind. Sprich wenn sich nur etwa die Werte eines Objekts ändert, muss man nur die DB verändern und den Server neustarten. Wenn sich aber z.b. die Beschreibung, das Modell o.ä. ändert wird nur das Media-Paket es Objekts geändert und neu hochgeladen (muss dann halt gepatcht werden).

Ich sehe kein Problem daran eine DB als Sicherungsmechanismus mitlaufen zu lassen, denn während des eigentlichen Spielablaufs wird auf die DB nur sehr selten zugegriffen (Spielerdaten laden). Der Client greift ja nie direkt auf die DB zu. Einzig mit PHP-Skripts muss man ggf. aufpassen. Jedoch kann man sich gegen z.b. MySQL-injects sehr einfach mit preparedstatements absichern.
Allerdings hat MySQL eine sehr seltsame Lizenspolitik. Ggf.ist Postgre die bessere Wahl (nutzen allerdings selbst auch MySQL, da wir den Umstieg nicht als dringend ansehen).
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Sicaine

unregistriert

15

14.09.2008, 20:44

@geisi1909 deine Entwickler haben wohl keine Ahnung und so wie du sprichst eigentlich auch nicht.

Ich mein wenn man son Projekt angeht sollte man sich schon im Vorfeld ueber ein Mehrschichtiges Speichermodel gedanken gemacht haben. Eine Datenbank z.B. ist nicht langsam. Datenbanken werden entwickelt um auf viele Daten schnell und effizient zuzugreifen.

Wenn man jetzt nicht gerade genug Ressourcen hat, sich ein Speichersystem selbst zu bauen was genau das macht was man braucht, muss man nun mal ein paar minimale Performanceeinbusen einrechnen.

Dass man aber nicht staendig fuer jeden Scheis auf die DB zugreift, sollte sowieso klar sein. Mit Tools like MemCache laedt man am Start Ressourcefiles, die sich nicht staendig aendern im Vornherein in den Ram. Dass z.B. Itemtrades in heutiger Zeit nur mit Transactions gemacht werden sollten, sollte klar sein. Das kostet halt etwas aber ist nun mal notwendig um zu gewaehrleisten, dass bestimmte _problemchen_ von Damals nicht mehr moeglich sind wie z.B. Itemdupes.

Man muss sich halt Gedanken darueber machen wie weit die Datensicherheit und Datenintegritaet geht und dass das kostet.

Auf der Clientseite hingegen reicht locker sqlite bzw. da ist es auch weniger Aufwand sich Gedanken ueber passende Fileformate zu machen und Indexfile die man komplett in den Ram laedt. Da sind eher die Schwierigkeiten sich Mechanismen fuer einen Speichermanager zu ueberlegen der die I/O sauber haendelt im Sinne von sortiert, mit Prioritaet und Streaming.

Steven77

Alter Hase

Beiträge: 515

Wohnort: Münster - Gievenbeach

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

16

15.09.2008, 12:59

Ich würds auch so machen, wie es hier bereits mehrmals vorgeschlagen wurde:

Alle "statischen" Spielelemente liegen direkt beim Client, die dann ggf. per Patch aktualisiert werden. Die können dann ja ruhig derbst kodiert sein, um die Sicherheit zu gewährleisten. Beim Entwickeln könnt ihr dann ja ruhig ne MySQL-DB oder XML verwenden. Dann schreibt ihr euch einen kleinen Konverter, der die "Rohdaten" entsprechend in die für die Clients vorgesehenen Dateien kodiert. Zack!

Zusätzlich (oder zur Not alternativ) kann man per CRC o. ä. feststellen, ob die Daten verbotenerweise Client-seitig geändert wurden.
Kommen Sie nie mit einem Schwert zu einer Schießerei.

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

17

15.09.2008, 13:35

Statische Daten sind auch nicht für die Datenbank gedacht. In einem MMORPG würden da eher serverseitige Daten wie Charakterstatistiken, Items, Inventories, etc der Spieler reingehören. Dort auf einen Datenbankserver zu verzichten halte ich für keine gute Idee. Immerhin sind sie darauf ausgelegt möglichst effizient auf große Datensätze zuzugreifen. Des weiteren kann man so auch über mehrere Server hinweg auf die Datenbank zugreifen ohne sich selbst um die synchronisierung zu kümmern.

Sicher ist es performanter die Daten der eingeloggten Spieler im Hauptspeicher zu halten.. aber man sollte daran denken, dass
a) der Speicher begrenzt ist
b) was mit den Daten passiert wenn der Server abstürzt.

Werbeanzeige