Open World (Multiplayer - Mega Server) + Persistent (Speichern/Streaming usw.)

Wie gesagt, das wird ohne UID nicht gehen. Du wirst es in dieser Menge, nur mit einer Datenbank lösen können, schon alleine, weil die Datenbank, auch entsprechende Algorithmen enthält, um größere Datenmengen schnell zu durchsuchen. Dazu muss sie natürlich richtig aufgebaut sein, sprich sortiert nach UID.

Ganz einfach, weil eine Datenbank eine einheitliche UID zur Identifizierung darin gespeicherter Daten benötigt. Das hat gar nichts mit der ID in Unreal zu tun.

In einer Datenbank hast du ja verschiedene Tabellen.

Du hast einmal eine Tabelle, in der die Spieler erfasst werden, mit Name, ID, Inventory ID und so weiter. Dann teilst du jedem Spoieler eine Inventory ID zu, anhand der ID kann jeder Spieler dann auf sein Inventory zugreifen. Und jeder Gegenstand hat halt eine ID, die dann im Inventory des Spielers erfasst wird.

Das hat aber alles etwas mit der Datenbank zu tun, NICHT mit irgendwelchen IDs von Unreal oder so.

Am Ende hast du quasi nur eine Inventory, dass deinem Spieler zugewiesen ist und welches nur IDs von Gegenständen beinhaltet. Wenn du das dann gut strukturiert hast, dann geht das Suchen auch extrem schnell und du hast die Daten, falls benötigt, sehr schnell zur Verfügung.

Am besten ist, du kaufst dir mal eins der berühmten sehr dicken und teuren Bücher, über Datenbanken und SQL etc. So ein Buch kann dir das Ganze wesentlich genauer beschreiben und erklären. Die sind nicht grundlos extrem dick, mit so um die 800 Seiten. So viel kann ich hier ja gar nicht tippen.

Ich glaube, du verstehst es noch immer nicht. Die UIDs in einer Datenbank haben nichts mit den Objekten in Unreal zu tun. Die UIDs sind notwendig in einer Datenbank, um die verschiedenen Tabellen sinnvoll zu verknüpfen. Das hat nichts mit den Objekten zu tun und jede Tabelle in der Datenbank benötigt ihre eigene UID.

Na ich glaube, man kann das noch etwas einfacher beschreiben, als es Sleepy gerade versucht.

Das ganze Konzept nennt man relationale Datenbank. Das nennt sich so, weil die Daten in verschiedenen Tabellen relational zueinander verknüpft und gespeichert werden. Eine gute Datenbank besteht immer aus mehreren Tabellen, welche die Daten in sinnvolle Kombinationen zusammenfassen.

Versuchen wir es mal anhand dieses Forums zu beschreiben, ohne jetzt zu wissen, wie die Datenbankstruktur, oder die einzelnen Tabellen, wirklich aufgebaut sind, aber es geht ja auch nur um die Funktionsweise.

Also, als Erstes gibt es natürlich eine Usertabelle. Du musst dich hier ja anmelden. Da steht zum Beispiel folgendes drin:

Dann hast du vielleicht noch eine Tabelle mit weiteren Informationen, die du hier im Forum einstellen kannst, wie zum Beispiel eine Signatur, Interessen usw.

Könnte dann so aussehen:

So. Nun weiß aber keiner, auch die Datenbank nicht, zu wem jetzt welche Signatur gehört. Dazu kommt dann eine neue Spalte in die Benutzertabelle.

Nun ist die Signatur mit den Daten des Benutzers verknüpft und wenn du dann auf einen Link klickst, mit dem du auf die detaillierten Userdaten und Signatur kommst, dann wird ein Link aufgerufen, in dem die UID der Signatur abgerufen und angezeigt wird.

Ähnlich ist es dann auch mit den Beiträgen, die Tabelle könnte etwa so aussehen:

Anhand der ID wird hier der Name des Erstellers eingeblendet, ohne dass diese Daten doppelt gespeichert werden müssen. Es wird einfach in der entsprechenden Tabelle nach der ID gesucht und entsprechende Daten bei der Ausgabe eingefügt. Und anhand dieser UID bei den Beiträgen, kannst du dann auch wieder Antworten mit diesem Beitrag verknüpfen, ohne dass dieser doppelt gespeichert werden muss. Es wird einfach die entsprechende ID verknüpft.

Was sehr wichtig ist, dass die UID halt auch sortiert ist, also mindestens einer der "sortet Keys" ist. Weil sonst dauert die Suche wieder sehr lange. Denn die Datenbanken benutzen einen einfachen, aber effektiven Suchalghorytmus.

Nehmen wir mal an, du hättest 3000 Einträge, die du durchsuchen musst. Und du suchst Eintrag Nummer 2000 oder so.
Die Datenbank springt jetzt zur Hälfte und schaut, wo sie ist. Aha, 1500. Also, vordere Hälfte unwichtig, obere Hälfte noch einmal halbieren. Damit landet sie dann bei 2250. OK, zu hoch, also obere Hälfte unwichtig, halbieren nach unten. Er landet dann bei 1900. Also wieder nach oben halbieren und er landet bei 2075. Je nach Datenbank wird er dann ab einer gewissen Nähe linear suchen. Aber, er braucht in diesem Fall um 3000 Datensätze zu durchsuchen 5 Suchdurchläufe. Und viel mehr wird er auch bei 10.000 Datensätzen nicht benötigen. Je mehr Datensätze es sind, um so mehr kommt der Vorteil dieses Suchalghorytmus hervor.

Jetzt fragst du dich sicher, wieso springt er nicht gleich zur 2.000? Ganz einfach. Es kann ja auch gelöschte Beiträge geben.

Kannst ja mal mit 100.000 oder gar 1.000.000 Datensätzen durchspielen. Du wirst merken, dass er sehr wenige Suchdurchläufe benötigt, um sein Ziel zu finden.

Ich verstehe nicht so ganz, was du jetzt willst. In der Datenbank kannst du doch die Werte eines Gegenstandes beliebig verändern, neue Werte setzen usw. Und die werden dann halt auch so in der Datenbank gespeichert. In einem Spiel hat ein Gegenstand ja nie reale physikalische Eigenschaften, das ist alles simuliert.

Du kannst theoretisch eine Datenbank machen mit Eigenschaften von Steinen. Wenn du einem Kieselstein dann ein Gewicht von 15 Tonnen in der Datenbank eingibst, dann ist das zwar etwas unrealistisch, für die Engine aber kein Problem.

Du musst diese Werte nicht direkt in dem Gegenstand speichern, du musst die Werte nur bei Bedarf aus der Datenbank auslesen.

Ganz einfach. Indem du die Datenbank nicht auf die Seite schiebst und die UID des Schwertes mit der UID des anderen Inventars verknüpfst und aus dem ersten Inventar löscht.

Bzw. du brauchst es noch nicht mal löschen, du änderst einfach nur die UID des Inventars und gut ist.

Es gibt für die Engine SQL-Plugins. Die Abfragen und Manipulationen der Datenbank gehen dann über SQL-Befehle. Also Select usw.

Aber, ich kann dir nur empfehlen, wenn du das so machst, mache das recht frühzeitig in deinem Spiel. Baue es so auf, dass du die Strukturen der DB leicht ändern kannst, falls du etwas übersehen hast und vor allem kauf dir ein gutes Buch über SQL. Es ist recht schwierig, rund 600 - 800 Seiten hier im Forum zu erklären. Und die Bücher haben nicht nur durch das Vorwort so viele Seiten.

Um deine vorherige Frage zu beantworten, ich persönlich benutze für mein Inventarsystem eine Struktur. Allerdings, bezieht sich mein Inventorysystem auch nicht auf x-Millionen möglicher Gegenstände.