Weltraum Scene Managment und MMORPG Datenbank
-
Hi,
ok, danke. Ich werde dann mal morgen nach Sylvester anfangen, die Datenverwaltung zu implementieren.
Nur mit dem Octtree... desto öfter ich darüber nachdenke, desto mehr beschleicht mich der Verdacht, dass meine dynamische Variante eines Octtrees keine gute Idee ist.
ChrisM
-
ChrisM schrieb:
Nur mit dem Octtree... desto öfter ich darüber nachdenke, desto mehr beschleicht mich der Verdacht, dass meine dynamische Variante eines Octtrees keine gute Idee ist.
Hmmm... naja. Da kann ich Dir leider nicht wirklich bei helfen... Hab' selber zu wenig Erfahrung mit Scene-Managment.
Aber auf die alten Hasen rapso und TGGC ist sicher Verlaß...
Viel Erfolg weiterhin für Dein Projekt.
Um ehrlich zu sein, hab' ich ja, als ich Dich das erste Mal davon im Projekte-Forum hab' schwafeln sehen, gedacht, das ist wieder so einer, der ist am Anfang mega-motiviert, aber das Projekt endet rupp-zupp in der Mülltonne...
Naja, da das nun schon eine Weile her ist, und Du hier immer noch ernsthafte Fragen zur Implementierung stellst, hat sich diese düstere Vorahnung von mir doch in ziemliche Zuversicht gewandelt...! Bleib' dran...! :xmas1:
-
Hi,
naja, dann wart' ich mal auf einen Post von den beiden. Das Problem ist ja weniger die Implementierung vom Octtree an sich, sondern nur die Frage, ob Suchoperationen nach Objekten in einer bestimmten Entfernung noch schnell genug bleiben, wenn die Entfernung zu groß wird. Und solche Suchen müssen regelmäßig durchgeführt werden, oder soll der Planet erst 10km vor dem Spieler auftauchen?
ChrisM
PS: Ich hab von Anfang an gewusst, worauf ich mich da einlasse, aber es geht voran...
-
Sorry, aber ich sehe hier keine echte Frage. Und um eine bessere Idee für dein "Scene Managment" zu haben, weiss ich einfach zu wenig über die Anwendung.
Bye, TGGC
-
Hi,
die Frage ist, ob jemand eine bessere Lösung kennt...
Und die Anwendung ist folgendes: Es geht um ein Weltraumspiel, in dem tausende von Objekten (auch kurzlebige wie Schüsse/Torpedos), die u.a. Schüsse, treibende Objekte, natürlich Schiffe, Stationen, Planeten usw. irgendwie auf dem Server verwaltet werden müssen. Kollisionsabfrage muss dabei möglichst schnell möglich sein, ebenso das Bewegen von Objekten (also ohne neue Memoryallokation bei jeder Bewegung -> würde zur Lags führen). Außerdem müssen schnell alle Objekte ermittelt werden können, die in einer bestimmten Entfernung zu einem anderen Objekt (nämlich ein Spieler, der auf neue sichtbare Objekte getestet werden soll) liegen.
Falls es als Information hilft: Intern wird jede Position in eine Sektorangabe (eine Sektorlänge = 1km) und eine Position innerhalb dieses Sektors aufgeteilt.
ChrisM
-
Kleine Anmerkung: Octree mit einem "t".
-
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
