Star Citizen Star Citizen [PreRelease Sammelthread] Teil II

[ZeT]

Ich hoffe einfach mal das mein Xeon 1231er mit den 16 GB Ram noch lange halten wird. ^^

Werd wohl nur die Graka austauschen (aktuell ne 750TI - wurde vor Jahren mal als "kurzfristige Übergangslösung" gekauft xD). Mal sehen was VEGA bringt. ^^

 

[Nightspider]

Also wenn SC fertig ist, dann wird's echt Zeit für eine der neuen 8-Kern CPUs, so wie es aussieht.
Es ist schön zu sehen, dass sie sich in letzter Zeit sehr darauf konzentrieren viele Dinge zu parallelisieren.

Besonders erfreulich fand ich auch, dass man selbst den IO Scheduler parallelisiert und so mehrere Streams gleichzeitig von der SSD laden kann.

Möglichst viele CPU Kerne + SSD und eine Menge Ram werden für ein optimales SC Erlebnis dann also zur Pflicht werden.

Ich fänds ja auch mal richtig interessant wenn man ein Spiel wie Star Citizen auf zwei SSDs installieren könnte. Wenn 50% der Daten auf SSD 1 und die andere Hälfte auf SSD 2 liegen könnte man die Lesegeschwindigkeiten beider SSDs gleichzeitig nutzen.
Das wird bei Konsolen ja schon seit Ewigkeiten gemacht, wo von DVD/BluRay und HDD gleichzeitig geladen wird.

Es gibt zwar mittlerweile pervers schnelle SSDs mit ~3000MB/s aber viele Leute haben ja noch "langsamere" SSDs im Rechner, vor allem da die M.2 SSDs deutlich teurer sind.

Im Happy Hour Interview: Item 2.0 Discussion Video wurde jetzt auch teilweise über Multithreading gesprochen.

Habs mal versucht rauszuschreiben....

What exactly is Item System 2.0?
So Item 2.0 whenever someone just says item 2.0 its not literally 2.0, its just the "technology" that brings item 2.0,i guess, available and coming up and living. So what that will mean is like, in our existing old stuff that we were releasing for a while we have these very centric gameplay logic blocks in the code and they do they their thing and they work pretty well but when you start wanting use bits and pieces of that for other systems it all falls apart because they're all that one big logic block is all interconnected and you can't just grab something. You grab something you stick it in here... this thing top board might not be set up right... end up coping and pasting...its a mess. So one of the very first things you have to do for 2.0 is we have this thing called component system and instead of having a big block logic defining...you know...a cup or a ship...we now strip away these bits of logic and we incomment them their own component...so you have a component "phsyics"...you have a component for "animation", a component for certain gameplay logic like shields or power plants and now you have all these different components...you can start adding them to...we call the entitys...and they just basically define something new and you dont need a coder to make a new chair, designer like Kurt could just go enter this tool "blab" all these down and has a new chair...."blab" als this down and has a new ship.
So its like trying to...build these more complex systems that allow designer to make these bigger systems...and at the same time...when we have it in those single logic blocks we had another thing with order....so the way that things updated was very deterministic and...adding all these things...we had to do one at the time on the main thread. And if you h ave a hundred of these things...its not a problem...but when you have a big gigantic universe were it might take a few minutes to hours to get to another planet there is a loooad of items and you might have anywhere between 10.000 or more...now they have to go one at the time and you end up slowing down the game because you have so many things to update...so one of the things in the item 2.0 or "entity component infrastructure" is this thing called "batch updates". So now all these individual components we made before can now run parallel at the same time in a frame. So instead doing one at the time we can do a bunch in a row...and another bunch...and another bunch...so our update went from something like >||||||||||||||||< this to something like >|||< this but >---< -> longways >-------------------< now. So the more CPU cores you got, the faster the game is going to run, basically taking full charge of multi core everything. So you have the components, you have the updates, than you have the dataforge which is the thing that design will use, its our own internal data structure, so before when we defined ships or items or anything like that it was all XML driven and the problem with that is anytime we load in a ship we have to open up a file its huge... ...so all these XMLs you have to load it and read it and that is slow. So instead we have this thing with "dataforge" we have everything offline and we export it one binary block and we load that and we can chunk everything that we need and take only the bits that we need fast.
Then...theres a billion other systems that come into....the interaction system...,...literally there is a bunch of stuff...the item 2.0 system itself uses all that technology and does a little bit more where now we have this thing that designades who could control what...than you have the items logic that talk to that...that talk to who kit take, take what...ahm...control on who she get what and who she can observe...//complex//...thats the item infostructure...well anything underneath that is like the entity level substructure whats the item 2.0 uses....theres a lot....i can talk for hours...

Also ich wette bei richtig großen space battles mit richtig großen Schiffen werden CPUs mit arschvielen CPU Kernen richtig glänzen.

 

[shoKuu]

Wenn das wirklich so sein sollte wird es wohl doch ein i9

 

[Silencium]

Und dank netcode dann dennoch mit 30 FPS 😬
Es tut mir wirklich leid, aber Item System 2.0 lässt mich irgendwie kalt.
Ferner müssen jetzt alle Schiffe schon wieder angepackt werden. Jaja ein iterativer Prozess und doch verbrennt das irre Geld 😬
Gucke gerade dir HappyHour und die Community Manager hasse ich beide - fällt mir immer wider auf. Die gesamte Community-Crew is echt ein dämlich öder Haufen -.-

 

[Nightspider]

Naja, Sean Tracy hat ja schon vor bald einem Jahr gesagt das Star Citizen wohl bis zu 32 CPU Threads nutzen wird. Die Frage ist wie stark man von den Kernen 10-16 wirklich profitiert und ob nicht doch ein 6 oder 8 Kerner mit extrem hohen Takt schneller ist.

BF1 nutzt ja auch extrem gut 8 Kerne aber ein hochgezüchteter QuadCore ist genauso schnell bzw. manchmal schneller.

Und dank netcode dann dennoch mit 30 FPS 😬
Es tut mir wirklich leid, aber Item System 2.0 lässt mich irgendwie kalt.

Tja und ohne Item System 2.0 brauchst du auch keinen neuen Netcode weils dann auch nicht schneller laufen würde.
Das hängt ja auch zusammen und greift ineinander.

Nur mit einem neuen Netcode könntest du das auch nicht stämmen wenn du nicht die CPU Auslastung massiv verbesserst, alles effizienter machst, Dinge zusammenfässt und unwichtige Dinge ausblendest (LoD).

 

[Zehkul]

Und dank netcode dann dennoch mit 30 FPS 😬

Es gibt nicht „den Netcode“, und Netcode an sich hat auch nichts mit FPS zu tun.
Was Leute mit Netcode meinen, hat eigentlich recht wenig mit Netcode zu tun, auch wenn es auch darüber gelöst werden könnte: Es ist das Problem, dass eine Menge Entities verarbeitet werden, die nicht einmal mit einem einzelnen Pixel am Schirm sichtbar sind und das auch mit mehreren Minuten Quantum Travel noch nicht wären. Die Optimierung, diese Objekte nicht mehr ins normale Frame Rendering einzubeziehen, kann auf Network Ebene erfolgen (der Server sendet einfach nichts mehr), genauso gut kann aber auch der Client einfach einen großen Teil der Daten ignorieren, die er bekommt. Je nach Datenstruktur kostet das ziemlich genau null Rechenkraft, man müsste also schon schön blöd sein, dort Performance zu verlieren.
Idealerweise macht man vermutlich beides – den Client alles ignorieren zu lassen funktioniert ganz offensichtlich nur sehr schlecht, da das massiv Bandbreite verschwendet (hat mit FPS aber auch wenig zu tun), und den Server, der deutlich weniger und auch nur verzögerte Information über die lokale Renderingsituation hat, über was im Wesentlichen die Sichtweite ist entscheiden zu lassen, erscheint mir auch nicht die allerbeste Idee zu sein.

Object Container sind auf alle Fälle ein erster großer Schritt in diese Richtung, und haben nichts mit Netcode zu tun, sind aber verdammt wichtig. Ohne kann Star Citizen nie auf Sonnensystem-Größe funktionieren. Was es ist? Sichtweite für Objekte (Entities), nur in etwas fortgeschrittener. Anstatt nur ab einer gewissen Distanz Information abzuschneiden, wird das auch anhand von Topologie entschieden.
Network Bind Culling vom Schedule wirkt dürfte dabei genau die Optimierung sein, die an der Stelle die Bandbreite spart, wo ich sie als verschwendet aufgelistet habe. Hat nicht viel mit FPS zu tun, solange die Client Sichtweite nicht davon abhängt. (Was ich nicht glaube)
Gerade in der aktuellen Star Citizen Alpha, die noch gar nicht besonders viele Object Container enthalten könnte, selbst wenn sie denn fertig wären, ist Items 2.0 sehr wichtig und ein großer Faktor für Performance. Kann ja nicht sein, dass eine einzelne Starfarer der Server schon lahm legt. Da hilft es auch nicht viel, wenn dank Object Container Leute in der Station nicht so viel davon mitbekommen, denn die Haupt-Action wird meist bei den Schiffen draußen stattfinden.


Wenn das Objekt-Updating wirklich bis hin zu Objektebene Parallelisiert ist, sind wirklich nur die Sterne die Grenzen bei großen Schlachten. Aggressive LoDs retten die GPU vor Überhitzung (in einer großen Schlacht klebt auch keiner mit der Nase an einer Wand um detaillierte Meshes zu bewundern) und die 32 Kern CPU regelt für die Schiffe.
LoGH Reenactment here I come …

 

[Jesterfox]

Ich fänds ja auch mal richtig interessant wenn man ein Spiel wie Star Citizen auf zwei SSDs installieren könnte. Wenn 50% der Daten auf SSD 1 und die andere Hälfte auf SSD 2 liegen könnte man die Lesegeschwindigkeiten beider SSDs gleichzeitig nutzen.

Nennt ich RAID0 und geht schon heute ;-) Ok, eine von der Software optimierte Verteilung der Daten wäre vermutlich noch besser, aber der Aufwand lohnt sich einfach nicht für die paar Leute die das dann tatsächlich nutzen würden.

 

[Nightspider]

Raid 0 hat auch Nachteile was Bootzeiten und Datensicherheit betrifft.

 

[Silencium]

RAID 1 0 und zwar mit 4 x 960 pro ;-)

Zum netcode-gebrabbel:
Damit aktuell die Daten auch nur ansatzweise synchron an die Clients gebracht werden kann, wird die FPS von Server am Client forciert.
Der Netcode ist schon deutlich trennbar, auch wenn die Technologie der Object-Container ein Zahnrad ist, welches eng mit dem NC verzahnt sein dürfte. Es geht beim NC um weitaus mehr als nur Packagesize/Bandwidth der Leitungen. Wie geht man mit Package errors/losses um, wie geht man mit Queues um, mit unterschiedlichen Pings, wann eröffne ich Instanzen, was braucht der Client aus der MegaMap, wie oft müssen solche Daten geupdated werden etc pp.

Ich möchte hinzufügen: selbst bin ich nicht am Projekt beteiligt, das was ich schreibe ist das was ich gelesen und in Videos gehört habe.

Es wird in meinen Augen noch min. bis 2018, wenn nicht 2019 brauchen, bis auch die Instanzierung funktioniert und selbst dann halte ich die Ziele für zu ambitioniert. 7000 in einer Schlacht ;-) ist in meinen Augen wunschdenken von Chris. Ich lasse mich gern überraschen, aber versuche mit einer gesunden und nötigen Skepsis zu verweilen.

Die größte Sorge macht mir die Trostlösigkeit im Verse. Planeten hin oder her, wenn auf 99,5% davon Nix los ist, dann ... nun ja, ich warte ab. Da sehe ich aber schon das Standardproblem schlechthin auf CIG zukommen.

 

[Zehkul]

Zum netcode-gebrabbel:
Damit aktuell die Daten auch nur ansatzweise synchron an die Clients gebracht werden kann, wird die FPS von Server am Client forciert.

Nein. So funktioniert das einfach nicht. Die FPS werden in vielen Fällen Ähnlichkeiten aufweisen, weil in dieser Sorte Server/Client Architektur sowohl Server als auch Client dieselben Dinge berechnen (derzeit sogar komplett ohne Culling irgendeiner Information, also berechnen Server und Client exakt das gleiche!) und um Bandbreite zu sparen nur Deltas und gelegentliche Checks hin- und hergesendet werden, aber nichts wird forciert, nicht in die eine Richtung, nicht in die andere.
Dass „deine“ Theorie Unfug ist, kannst du ganz leicht ausprobieren, indem du mit einem guten PC auf einen leeren Server springst. Du wirst eine FPS Zahl über 30 bemerken, während die Server auf 30 gelockt sind. Anführungsstriche deshalb, weil ich weiß, dass diese Fehlinformation schon sehr lange umgeht und der originale Autor nur sehr schwer zu finden sein wird.

Es geht beim NC um weitaus mehr als nur Packagesize/Bandwidth der Leitungen. Wie geht man mit Package errors/losses um, wie geht man mit Queues um, mit unterschiedlichen Pings, wann eröffne ich Instanzen, was braucht der Client aus der MegaMap, wie oft müssen solche Daten geupdated werden etc pp.

Und nichts davon hat Einfluss auf die Render-FPS. Gut, eine leere Instanz hat natürlich weniger Dinge, die passieren, ergo werden FPS auch höher sein, aber das ist trivial.
Welche Daten der Client fürs Rendering braucht, muss er selbst entscheiden können, das wäre eine große Menge nutzlos gesendeter Information und damit verschwendeter Bandbreite, und mit schlechtem Ping auch eine merkbare und unnötige Verzögerung des Spielgeschehens.

Es wird in meinen Augen noch min. bis 2018, wenn nicht 2019 brauchen, bis auch die Instanzierung funktioniert und selbst dann halte ich die Ziele für zu ambitioniert. 7000 in einer Schlacht ;-) ist in meinen Augen wunschdenken von Chris. Ich lasse mich gern überraschen, aber versuche mit einer gesunden und nötigen Skepsis zu verweilen.

Eine Zahl wie 7000 wurde nie erwähnt, das hast rein du dir ausgedacht. Erwähnt wurden Schlachten um die 100 Schiffe, und jenseits davon ist es IMO auch eher eine Balance-Frage als eine Tech-Frage. 7000 Schiffe auf dem selben Fleck zu stapeln, kann schon topologisch nicht funktionieren, und ist mit Sicherheit auch nicht das spannendste Gameplay, selbst wenn es funktioniert. Gameplaydesign muss dafür sorgen, dass große Schlachten sich über ausreichend große Areale erstrecken, dann funktioniert es auch mit dem Rendern.

 

[shoKuu]

Letztendlich braucht man auch keine nicht mal ansatzweise so viele Schiffe und ... 4-5 größere Schiffe (Bengal, Idris, Polaris) auf jeder Seite + einige kleinen Fighter und Bomber und dann sollte man bei maximal 50-60 Schiffe schon ordentliches und taktische Großschlachten führen können.
Viel Wichtiger wird es dabei die ganzen Spieler in unterschiedlichen Schiffsinstanzen zu bekommen. Man kann ja letztendlich auf viele Spieler Bewegungen auf unterschiedlichen Schiffen verzichten.

 

[Zehkul]

Das wäre genau der Trick mit räumlich sehr weit ausgedehnten Schlachten. Am einen Ende der Schlacht siehst du nichts vom anderen Ende, das ist ideal nicht nur fürs Rendern sondern auch für Netcode und Instanzen. Damit hat man eine Menge kleine Brocken, die nebeneinander aufgereiht eine schöne große Schlacht ergeben, die man auch kontinuierlich abfliegen und bewundern kann. Nur kann niemand jedes Schiff auf einmal sehen, was sowohl Clients als auch Server und vermutlich auch die Bandbreite in die Knie zwingen würde.

Dafür müssen aber nicht nur Tech, sondern wie gesagt auch Gameplay und Balance stimmen.

 

[ZeT]

Ich sehe vorallem in den diversen Schiffsklassen hohes Potential. Dank Permadeath und Penaltys bei Verstoß gegen das Gesetz seh ich Massenschlachten primär zwischen Piraten- und Security Orgs. Das könnte aber dann ziemlich lustig werden, außerhalb des UEE Raums hauen sich dann die großen Orgs aufs Maul.

Da würd ich dann mit der Eclipse hinfliegen und als stiller Beobachter dem Schauspiel folgen. *g*

 

[KenshiHH]

Ich muss sagen ich bin ein wenig geschockt umso mehr ich vom Item 2.0 mitbekomme, das was 2.0 ist hätte von vorn herein geplant sein müssen, auch was deren Componenten System ist, das gibt es schon seit Ewigkeiten in der Spieleentwicklung "Entity–component–system".

Wirkt nen wenig wie "fangen wir erst mal an, planen können wir später"

Freu mich tierisch auf SC, aber da wirkt es als hätten die in der anfangs Planung völlig verkackt.

 

[Zehkul]

Ich muss sagen ich bin ein wenig geschockt umso mehr ich vom Item 2.0 mitbekomme, das was 2.0 ist hätte von vorn herein geplant sein müssen, auch was deren Componenten System ist, das gibt es schon seit Ewigkeiten in der Spieleentwicklung "Entity–component–system".

Gibt es ganz offenbar nicht seit Ewigkeiten, da CryEngine das nicht hatte. "Modernizing Entity System" steht derzeit auf der Roadmap für 5.4, glaube aber nicht, dass das auch nur annähernd so komplex ist. Ist nämlich für die meisten Spiele einfach nicht notwendig und damit nur unnützer Ballast, der Bugs produziert.

 

[KenshiHH]

Nur wil es ein Plug n Play feature in der Engine ist, ist es keine ausrede dafür es nicht zu haben, dafür hat man ja zugriff auf den SourceCode.
Die haben es einfach vermasselt am start mit der planung

 

[ZeT]

Die Frage ist, wann man sich entschlossen hat dieses Feature einzubauen und seit wann sie daran schon arbeiten. Sicher nicht am Anfang der Entwicklung.

 

[Zehkul]

Was? Es ist eben kein Feature in der Engine. In meines Wissens nach keiner Engine.
Die Arbeiten am Item System 2.0 laufen auch schon seit Jahren, damit wurde so ziemlich sofort begonnen, als der Umfang von Star Citizen klar wurde. Natürlich nicht, als es noch ein Wing Commander Remake mit ein paar Multiplayer Matches war, aber darauf lassen sich eine Menge Verzögerungen in Star Citizen zurückführen.

 

[KenshiHH]

Kann ich mir nicht vorstellen das die da schon soooo lange dran arbeiten, man macht sich doch keine doppelte arbeit und muss ALLE items umschreiben von den funktonen her.
Alles extra doppelt machen nur damit man krampfhaft was vorzeigen kann wäre doch die absolute ressourcen verschwendung.

Was nun am ende wirklich der fall ist, werden wir eh nie erfahren.
Ich find es halt dennoch ne komische entwicklung

 

[Zehkul]

Was nun am ende wirklich der fall ist, werden wir eh nie erfahren.

Doch, haben wir sogar schon lange, weil schon seit langem in AtVs, studio report etc vom Item System 2.0 geredet wird, du hast es nur nicht mitbekommen. Ende 2015/Anfang 2016 war es auf alle Fälle sogar schon unter dem finalen Namen im Report, gelistet unter „solid progress“.

Was hätten sie denn deiner Meinung nach machen sollen? 2 Jahre keine Schiffe entwickeln?