Weltraum Scene Managment und MMORPG Datenbank
-
Hi,
hmm... kommt der nicht von Oct für Acht (weil acht Childs pro Node) + Tree für Baum? Also müssten es zwei Ts sein...
Du hast aber wahrscheinlich trotzdem recht, Google findet für ein T viel mehr Ergebnisse
ChrisM
-
ChrisM schrieb:
Hi,
hmm... kommt der nicht von Oct für Acht (weil acht Childs pro Node) + Tree für Baum? Also müssten es zwei Ts sein...
Du hast aber wahrscheinlich trotzdem recht, Google findet für ein T viel mehr Ergebnisse
ChrisM
Tja, man kann ja Octet auch mit Oc abkürzen...
Ein 6-astiger Baum hört sich toll an: Sextree!
Oder 3: Triptree
..., Triple, Quadruple, Quintuple, Sextuple, Septuple, Octuple, ... - wie geht's weiter!?
-
Ich würde da glaube ich gar keinen Baum benutzen. Wie groß ist ein Schiff im Vergleich zu einem Sektor?
BTW: September, Oktober, wie gehts weiter?
Bye, TGGC
-
Hi,
die Größe eines Schiffes kann eigentlich beliebig sein, d.h. von zehn Metern bis so vielleicht ein km (also genau ein Sektor). Ist das wichtig? Ich speichere ja eigentlich nur die Mittelpunkte.
ChrisM
PS: Es gibt auch einen unären Baum: Die einfache linked list!
-
Dann würde ich die Kantenlänge mal so ungefähr vertausendfachen und jeden Sektor einzeln betrachten. Soll das eigentlich Echtzeit sein und was genau ist in der DB drin?
-
Hi,
ja, aber wenn ich die Sektoren so viel größer mache, dann hab' ich wieder ellenlange Listen für jeden Sektor und der Server wird zu langsam.
Wobei Kollisionsabfrage das kleinste Problem ist, denn da kann man ja bei jedem Fehlschlag speichern, wie lang es mindestens dauert, bis eine Kollision stattfinden könnte.
Soll das eigentlich Echtzeit sein
Klar.
was genau ist in der DB drin?
Vorerst nur die Accountdaten wie Name, Passwort und Position, Lagerraum (Inventar) usw. aller ausgeloggten Spieler. Denn die, die eingeloggt sind, werden natürlich im RAM des Servers gehalten, ich kann ja nicht zehn Datenbankzugriffe pro Sekunde und Spieler oder machen...
ChrisM
-
Achso, aber ellenlange Sektorlisten werden nicht langsam? Und was wirklich aufwendig ist, ist doch grad der Sektorwechsel, grade wenn diese in einem Baum sind. Ein Server kann ohnehin nur eine bestimmte Anzahl Spieler verwalten, egal wie genau du es machst. Also machste ein Sektor so groß, das er von einem Server noch ordentlich bearbeitet werden kann und verteilst die dann (evtl. dynamisch). So würde ich das angehen. Sektorwechsel würde ich gar nur über "Sprungportale" erlauben.
Bye, TGGC
-
Hi,
nein, Sprungportale wollte ich vermeiden. Davon, dass sie im Vergleich zum restlichen Spiel wirklich physikalisch unmöglich sind, ist es auch langweilig, wenn man großen Strecken in wenigen Sekunden zurücklegen kann.
Aber so aufwendig, wie du schreibst, ist der Sektorwechsel gar nicht. Die Objekte werden reference counted gespeichert, d.h. es muss kein Speicher umkopiert werden, sondern nur einige Male im Baum runterrekursiert (geiles Wort) werden, solange, bis es keine weiteren Nodes mehr gibt. Dort wird dann der Smart Pointer eingefügt und im alten Node gelöscht.
ChrisM
-
Du hast ja nach einer besseren Lösung gefragt. Aber wenn dein Spiel sonst "physikalisch möglich" ist, dann wird es wohl ohnehin keiner spielen.
Weder Sektorwechssel noch Kollisionsabfrage sind dein Problem, was denn?
Bye, TGGC
-
Hi,
gar kein Problem, ich wollte nur eure Meinung zu dem Ansatz des dynamischen Octrees hören! Oder ob halt jemand noch was besseres weiß.
ChrisM
PS: Nein, das spiel wird nicht "realistisch", aber ich hasse es ganz einfach, wenn man in wenigen Sekunden ans andere Ende des Universums kommt
