RTV - Object Container Streaming

Nach meinem schönen und aufschlussreichen 4 Wochen USA Roadtrip -bei dem ich hautnah den Start der Delta IV Heavy mitsamt Parker Solar Sonde beobachten durfte- wird es nun Zeit sich wieder mit den wichtigen Dingen im Leben zu befassen: Object Container Streaming (OCS). ^^

Da ich schon öfters in meiner Blogreihe erklärt habe was OCS ist, füge ich hier nur das Wichtigste und Neuste an Informationen zu diesem Thema auf.


  • OCS teilt die Spielwelt in einzelne Container auf (Schiffe, Stationen, Planeten, Objekte), welche dynamisch, ohne Ladebildschirm, oder Laderuckler, Relevanz-basiert in den eigenen RAM geladen, oder entladen werden.
  • OCS wird auch für den Singleplayerteil SQ42 gebraucht.
  • Die Entscheidung, wann ein Container geladen/entladen wird, basiert auf der Größe des Containers relativ zu der Entfernung zum Spieler. -> Eine Hornet wird somit schätzungsweisenach 8 km aus dem RAM entfernt, während Levski erst nach 40km aus der Spielwelt entladen werden darf, da man es aufgrund der Größe weiter sehen kann.
  • Aktuell läd man beim Spielstart ins PU etwa 70000 Entitäten, mit OCS sind es nur noch ca. 9000. (Info aus dem Gamestar Artikel)
  • In aktuellen 3.3 QA Testbuilds führt das anfliegen von Levski noch zu Nachladerucklern, gleichzeitig wird von weitreichender FPS Erhöhung gesprochen, allerdings nicht in Ballungsräumen.
  • Es wird ein Serverbasiertes OCS System geben welches aber nicht mit Release 3.3 kommt.
  • Die Serverlast wird mit 3.3 erheblich ansteigen, da dieser vorerst ohne OCS auskommen muss und somit die gesamte Spielwelt im RAM hat, welche permanent simuliert wird. Es wird somit voraussichtlich keine Erhöhung der Spieleranzahl pro Instanz geben.
  • OCS für den Server bedarf der annähernd allumfassenden Persistenz bevor es ins Spiel kommen kann. D.h.: Ein Objekt welches der Server "vergessen" kann und somit aus seinem RAM verschwindet, bedarf der Speicherung des Objekt Status in einer Datenbank.
    -> Beispiel: Eine Kiste wird in einem Shelter auf einem Mond abgestellt. Bisher liegt die Positionsinformation samt Status der Kiste im RAM des Spielers und Servers. Zukünftig soll das nicht nur aus dem RAM des Spielers gelöscht werden wenn man sich entfernt, sondern auch aus dem RAM des Servers, solange auch kein anderer Spieler in der Nähe der Kiste ist. Wer weis dann aber noch das dort eine Kiste steht und was in ihr ist, wenn alle Spieler und der Server diese nicht mehr im RAM haben? Sie muss also vorher, samt Status und Eigenschaften in eine Datenbank gespeichert werden, welche auf der Festplatte "eines" Servers abgespeichert ist (persistence database service). Der Shelter selbst ist eine unveränderliche Spielinformation welche auch jeder Spieler auf seiner Festplatte hat. Das muss also nicht abgespeichert werden, es sei denn es kommen später Informationen wie Energielevel, Schadenstatus etc. des Shelter dazu.
  • Je nach Leistung eines PCs kann es zum sichtbaren "einpoppen" von Objekten kommen. (Kennt man aus anderen Spielen welche ebenfalls die Spielwelt streamen müssen.)
  • Selbst die Entwickler sind auf Bind Culling angewiesen wenn sie im PU etwas testen müssen, da nicht jeder DEV PC genug RAM hat.
  • Ein Beispiel der Objekt-Container-Ebenen: GrimHex Shop Container -> Grim Hex Container -> Yela Container -> Crusader Container. Es gibt keine Tiefenlimits und es wird zur Zeit auf eine benutzte Maximaltiefe von 7 ineinander gesteckten Objektcontainerebenen geschätzt.
  • OCS wird nach 3.3 stets weiterentwickelt und verbessert.
  • Mit OCS entfalten Intel Optane SSDs und auch normale NVMe SSDs ihr Potenzial im Vergleich zu SSDs die mit SATA angebunden sind, da nun Objekte parallel von der SSD in 4 x 16kb Blöcken pro CPU Kern geladen werden können. HDDs und SATA SSDs profitieren lediglich beim Spielstart von der verringerten Anzahl zu ladender Objekte und können vermehrt zum typischen "einpoppen" von Objekten führen. (laut Sean Tracy im PTU test Chat von vor 5 Monaten)

Quelle: https://youtu.be/E0YYKIjEC0E