Technische Aufteilung

Nachricht

Komponenten/Entitäten des Grundstückssystems

Shard

Stellt eine komplette Grundstücks-Map des Citybuilds dar. Alle Karten auf denen Grundstücke angelegt werden können sollen/Gebiete vermietet werden sollen, müssen eine Shard sein. Entsprechend ist Alles (inklusive der Hauptwelt mit Spawn) eine Shard. Jedem Minecraft-Server (Docker-Container) wird genau eine Shard zugewiesen (besitzt aber die technische Möglichkeit mehrere Welten zu unterstützen, beispielsweise für die Mikro-Games auf den Shards). Technisch findet zwischen der Haupt-Shard (Spawn) und den normalen Shards (Grundstückswelten) keine Unterscheidung statt. Jegliche Techniken des Spawns können genauso auch auf den Shards genutzt werden und vorkommen. Dem Docker-Container wird lediglich gesagt, welche Shard er laden soll, das Prozedere zum Laden ist dann bei allen Shards gleich. Es werden bestimmte Stages durchlaufen und die Karte wird Ebene für Ebene für die Nutzung vorbereitet. Es wird also immer nur auf einer Kopie der Karte gespielt.

EstateCompound

Stellt einen logischen (und nicht zwangsläufig regionalen) Zusammenschluss mehrerer Häuser dar. EstateCompounds verstehen sich als eine Art "Nachbarschaft". Es handelt sich also um eine - ingame erkennbare - Grundstücksgruppe, die optisch in Relation zu einander steht. Jede Shard beherbergt mindestens einen EstateCompound. Der Standard-EstateCompound (falls keiner zugewiesen wird), der in jeder Shard enthalten ist, ist per EstateCompound.NONE zu erreichen, und stellt einen technischen Placeholder dar. Bei EstateCompound.NONE wird sämtliche zusätzliche Caching-Logik umgangen und dieser spezielle Platzhalter hat immer die Dimensionen der kompletten Shard. Die Compounds werden für die Errechnung von Grundstückspreisen, Offline-Kalkulationen und co. genutzt. Außerdem werden erweiterte Features wie Tunnel-Gänge und Gemeinschaftsplätze nur bei Grundstücken innerhalb des selben Compounds möglich sein.


EstateCompounds beherbergen Estates sowie CommunityEstates. Letztere sind Dinge wie Gemeinschaftsplätze, Beete, Brücken, etc., die nicht einem Grundstücksbesitzer zugeschrieben werden können, sondern dem gesamten Compound gehören. In Compounds werden also zwei separate Listen geführt: "estates und communityEstates".

Estate

Stellt ein einzelnes Grundstück innerhalb eines EstateCompounds (oder EstateCompound.NONE) dar. Ein Grundstück besteht aus vielen EstateComponents und gruppiert diese logisch zu einer Einheit. Für Spieler ist dies die kleinste separierbare Einheit, alle Ebenen hierunter sind lediglich technischer Natur. Grundstücke können lediglich als Ganzes vermietet werden. An die Grundstücke werden Informationen wie gekaufte Farmfelder, Besitzer, Rahmen, etc. gebunden.

EstateComponent

Stellt eine einzelne Fläche innerhalb eines Estates dar. Die meisten (alle rechteckigen) Grundstücke bestehen hierbei nur aus einer EstateComponent. Theoretisch kann ein einzelnes Grundstück aber aus vielen einzelnen Komponenten bestehen, die auch nicht zusammenhängen müssen. EstateComponents dürfen sich lediglich innerhalb eines Estates überschneiden, nicht aber zwischen verschiedenen Estates. Sollte es hier zu einem Fehler kommen, muss ein Unit-Test fehlschlagen, der hier die Überlappungen überwacht.


Die Überlegung bezüglich der "Grundstückserweiterungen" ( Aristos ) könnte so ebenfalls mit Leichtigkeit umgesetzt werden, indem EstateComponents "Predicate<EstateActor>" zugewiesen bekommen, also beim Initialisieren/Re-initialisieren alle Components geparsed werden, und ihre Prädikate validiert werden. So wären dann einige Components optional und könnten an Bedingungen (wie den Kauf) geknüpft werden. Aber selbst abstraktere Dinge wie "Wenn Dienstag ist, ist diese Komponente enthalten" wären als Einzeiler so darstellbar. Komponenten die immer enthalten sind erhalten (zur Performance-Schonung und Lesbarkeit) x -> true als ihr Prädikat.


Die EstateComponents nutzen intern die Selections die auch Beispielsweise für JCEditor und die Eroberungszone auf dem PvP genutzt werden. Dadurch haben wir eine einzelne Stelle an der wir die Auflösung optimieren können, und müssen die geometrischen Formen nur einmal implementieren. So können auch Polygone, Kugeln, Kegel und co. verwendet werden.

Block

Ist das Standard-Bukkit-Block-Objekt. Lassen sich direkt über eine EstateComponent beziehen, besitzen bei uns aber für die meisten Aktionen eher eine untergeordnete Rolle. Blöcke werden weder bei der Auflösung, noch bei der Interaktion explizit angesprochen und sind nur für die Interaktion mit der Welt interessant. Bei Auflösung, Manipulation und Monitoring wird dagegen auf Vektoren, Koordinaten-Tupel und Matrizen zurückgegriffen.

Grundstücksauflösung

Die Grundstücke werden wie in einem Binärbaum aufgelöst. Die Äste die dabei nicht zutreffen können, werden nicht weiter beachtet und "abgeschnitten". Die Caching-Daten sind dabei transient und werden dynamisch beim Hochfahren des Servers generiert. Dadurch verzögert sich der Start geringfügig, aber die Auflösung funktioniert anschließend unheimlich viel schneller. Alle Zonen sind dabei Rechteckig, außer den EstateComponents, die dann tatsächlich auch unförmige Strukturen unterstützen.


Durch diese Vorselektion erreichen wir in etwa eine Durchlaufzeit von O(log n) und sind auch gut auf riesige Shards mit Unmengen an Grundstücken eingestellt.

Kommentare 0