Star Citizen: Interne Machtkämpfe + Cryengine-Probleme = Umstrukturierung

Unreal Engine 4 war 2011 noch nicht in einer ausgereiften Version verfügbar. CryEngine war damals die beste verfügbare top-level Game-Engine. Und sobald die Produktion läuft, ist es schwierig, die Engine zu wechseln, oder gar von Grund auf eine eigene Engine entwickeln zu wollen. Dann muss man auf vielen Gebieten wieder bei Null anfangen, und viele Entwickler können ihren Hut nehmen, weil Spezialisten für eine ganz andere Engine benötigt. Aber CIG hatte Glück und Dutzende ehemalige CryTek-Mitarbeiter waren plötzlich auf dem Arbeitsmarkt verfügbar. Jetzt arbeiten viele Leute, die die CryEngine überhaupt erst entwickelt haben, für CIG. Die CryEngine ist jetzt quasi die "Custom Engine" für Star Citizen. Eine wirklich glückliche Fügung des Schicksals, die das Projekt massiv voran gebracht hat.

Was sagt ihr Cry Engine besser als Unreal Engine 4 für Space Spiele ?

Zum Vergrößern anklicken....

Beide Engines sind gleich gut oder schlecht geeignet für eine Space-Sim, vor allem für ein Spiel wie Star Citizen. Beide Engines haben nicht das für First- und Third-Person kombinierte Animationsmodell, dass Star Citizen benötigt. Beide Engines können nicht ohne Weiteres ganze Sternensysteme darstellen, oder aus dem Stand mit prozedural generierten Terrain umgehen, und in jedem Fall hätte CIG einen eigenen Netcode für das Spiel schreiben müssen. Wenn Unreal Engine 4 ein oder zwei Jahre früher verfügbar gewesen wäre, dann wäre diese Engine wahrscheinlich die bessere Wahl gewesen, allein schon weil die Editor-Tools der Unreal Engine viele Funktionen unterstützen, die für Star Citizen interessant sind. Aber in jedem Fall hätte CIG sehr viel Eigenarbeit leisten müssen.

Und mittlerweile ist es eh egal, denn die erwähnte notwendige Eigenarbeit und Anpassung der Engine nähert sich der Fertigstellung, und CIG hat wie gesagt die CryEngine ohnehin quasi adoptiert, nachdem sie viele der CryEngine-Entwickler anwerben konnten.

Zitat: Und ehrllich gesagt fand ich die Unreal Engine schon immer sehr 'unnatürlich' aussehend ... i

Da musste ich lachen . Was ist denn an Weltall überhaupt natürlich wenn wir beide noch nie dort waren und die wenigsten Menschen kenne sich mit Astrologie aus . Weltraum ist nun mal Bunt und besteht aus Partikeln . Genau das ist das Special Fähigkeit der Unreal Engine 4 Realistische Partikel Darstellung in Millionen Partikeln . Das ist auch nur ein Beispiel zähle sicherlich nicht alles nun auf .
Weltall soll natürlich Aussehen ja wenn du ein Alien bist und viel im Weltall Reisen tust dann vielleicht ^^ .

Buttonsmasher schrieb:

Bin mir da nicht so sicher . Aber warum würde nicht die Unreal Engine 4 genommen? Die hat bessere Grafik als die Cryengine unterstützt Dx12 und noch viele andere dinge . Die Stärke sind besonders Space artige Spiele z.b Unreal Tournament . Natürlich kann man mit der Engine auch einen Borderlans lock verpassen . Doch das zeigt doch wie vielseitige die Unreal Engine ist . Es wurden mehr Spiele mit der Unreal Engine 3 gemacht als viele mit Cry Engine . Dabei waren die Spiele wie Crysis nicht wirklich in Sachen Performance gut . Doch gebe ich zu kenne die Unterschiede nicht .

Was sagt ihr Cry Engine besser als Unreal Engine 4 für Space Spiele ?
Ich denke eher nicht. Doch wenn sie die Cry Engine eh umschreiben mussten weil sie nicht wirklich gepasst hat . Denke ich das die Möglichkeit bei der Unreal 4 Engine besser sind . Da ich ein ca 50 Stunden in der Unreal Engine paar Häuser und Gebiete gebaut habe . Bei der Cry Engine kenne ich mich halt null aus .

Zum Vergrößern anklicken....

Dann kennst du die Unreal Engine nicht, sorry!
Fangen wir mal an: DX12 wird von der CE unterstützt!
Die UE4 wäre für das Star Citizen eine viel größere Katastrophe geworden. Das fängt schon dabei an, dass die Engine eine maximale Mapgröße von 8x8 km hat. Die CE kam von Haus aus ohne diese Begrenzung (die CE ist btw. die einzigste Lizenz-Engine mit diesem Feature).
Natürlich wurden mehr spiele mit der UE3/4 gemacht, da diese das bessere Aufwand/Ergebnis Verhältnis bietet - die CE hat dafür das wesentlich höhere technische Potenzial! Thema performance:
Noch nichtmal heute in der aktuellen Version kann die UE4 auch nur annähernd so viel verarbeiten die die CryEngine! Ich bin mir absolut sicher, dass Crysis so in der UE nicht spielbar gewesen wäre! Man kann in die CE eine Menge reinpacken ohne, dass das sofort auf die Perfomance schlägt. In der UE4 bist du als Grafiker immernoch darauf fokusiert den Polycount zu drücken und Texturen so gut es geht zu reduzieren.
Polycounts ist in der CE schon lang kein Thema mehr und auch hochauflösende Texturen schlagen nicht auf die Performance.
Es gibt da eine sehr coole Library für Photogrammetie-Assets: Die Quixel Megascans. Es gibt schon ein Spiel, welches diese Assets verwendet und natürlich auf Basis der CryEngine!
Dazu ist die CryEngine deutlich modularer aufgebaut und daher modifizierbarer als die UE4.

Wie bei jeder Engine muss man sich natürlich erstmal einarbeiten, was eben sehr einfach ging durch die Crytek Leute - Epic wollte Chris Roberts ja nicht unterstützen mit Man-Power...

Eine weitere Sache ist das die Licht/Schatten/Reflektionen in der CryEngine viel besser sind und auch die Shader deutlich besser programmiert sind. Das Post-Processing der UE4 ist dann mMn der Totalausfall, wenn man sich da nicht die Mühe macht und was eigenes einbaut kommt man nie auch nur in die Richtung des Fotorealismus. (Kingdom Come hat sehr gut gezeigt, was die CryEngine da drauf hat!)

Die CryEngine ist imo bei der Darstellung von Gesichtern der UE4 auch deutlich überlegen. (siehe Ryse oder auch die SC Videos). Davon wird insbesondere Squadron 42 stark profitieren.

Lukewarm schrieb:

Unreal Engine 4 war 2011 noch nicht in einer ausgereiften Version verfügbar.



Beide Engines sind gleich gut oder schlecht geeignet für eine Space-Sim, vor allem für ein Spiel wie Star Citizen. Beide Engines haben nicht das für First- und Third-Person kombinierte Animationsmodell, dass Star Citizen benötigt. Beide Engines können nicht ohne Weiteres ganze Sternensysteme darstellen, oder aus dem Stand mit prozedural generierten Terrain umgehen, und in jedem Fall hätte CIG einen eigenen Netcode für das Spiel schreiben müssen. Wenn Unreal Engine 4 ein oder zwei Jahre früher verfügbar gewesen wäre, dann wäre diese Engine wahrscheinlich die bessere Wahl gewesen, allein schon weil die Editor-Tools der Unreal Engine viele Funktionen unterstützen, die für Star Citizen interessant sind.

Zum Vergrößern anklicken....

Nun, die Openworld Features für die UE4 funktionieren auch heute noch nicht gut und das Release Update für diese Feature ist auch schon ne Weile her. Das Problem der UE4 ist, dass es kaum bis garkeine Openworld Spiele auf der Engine gibt und gab, ergo konnten da kaum Erfahrungen gesammelt werden - viele Probleme sind da möglicherweise noch nie relevant geworden.
Die CryEngine hingegen, war schon seit FarCry/Crysis1 auf riesige Maps ausgelegt, weshalb die Engine noch nichtmal ein Limit für die Mapgröße setzt.. die UE schon.
"Beide Engines können nicht ohne Weiteres ganze Sternensysteme darstellen, oder aus dem Stand mit prozedural generierten Terrain umgehen" Erstmal können beide Engines prozedural arbeiten - die CryEngine kann noch viel mehr als das!
Durch den integrierten Objekt Editor in der CE kann man sogar Objekte in der Engine tatsächlich erschaffen ohne vorher ein 3D Model-Programm verwenden zu müssen.
Die (prozedurale) Generierung von Objekten und Terrain funktioniert in der CryEngine sogar in Realtime!!!
Ich hab ich lange mit beiden Engines auseinandergesetzt und muss die CryEngine der UE4 bei weitem vorziehen.
Die CE 3 war vielleicht damals ein Problem-Kind, aber heute und vor allem seit dem sie Lizensierbar ist, liegt die CE der UE weit vorraus.
Vor allem die CryEngine V ist mega und ich würde sogar sagen, dass sie der UE4 eine Generation vorraus ist.
Besonders das Thema "Beleuchtung":
"Dynamic Real time Global Illumination" ist ein Feature, was (noch!?) in der UE4 als experimentelles Feature vorhanden ist - wenn man sich jetzt vor Augen führt, dass schon Crysis 1 im Jahr 2007 diese Lichtrendertechnik verwendet hat.
Gibt ein paar derartige Beispiele! Hauptsächlich im Bereich Lighting, Shadowing und Partikel.

Buttonsmasher schrieb:

Was ist denn an Weltall überhaupt natürlich wenn wir beide noch nie dort waren und die wenigsten Menschen kenne sich mit Astrologie aus . Weltraum ist nun mal Bunt und besteht aus Partikeln.

Zum Vergrößern anklicken....

Witzig! Anderen entgegnest du, dass niemand hier wissen kann, was im Weltraum natürlich ist, aber du weißt ganz genau, dass der Weltraum voller Farben und Partikeln ist. Was nicht einmal stimmt. Der Weltraum ist ziemlich trist, zumindest was die Farbvielfalt angeht, und er ist auch ziemlich leer.

Aber davon mal ist die ganze Diskussion ohnehin überflüssig geworden. Die Unreal Engine war niemals eine Option, einfach weil sie in der gewünschten Form zum Zeitpunkt der Entscheidung nicht verfügbar gewesen ist. Und mittlerweile hat CIG ein eigenes CryEngine-Entwicklungsteam aufgebaut mit Leuten, die die Engine überhaupt erst entwickelt haben. Das ist eine Expertise, die CIG niemals für die Unreal Engine hätte anheuern können.

@CryPosthuman
Ich gebe zu, dass ich nur widergebe, was ich in einschlägigen Entwicklungsforen gelesen habe (fernab von allen Diskussion rund um existierende Videospiele). Eines dieses Details war, dass es die CryEngine wohl nicht mögen soll, wenn man sie mit prozeduralen Meshes füttert. Wenn das aber so gar nicht stimmt - vielleicht ging es in der erwähnte Diskussion um eine sehr spezifische Anwendung dieser Technik - dann nehme ich das gerne so hin. Dass die Yerli-Brüder immer schon sehr an Prozeduralen Technologien interessiert waren, ist mir hingegen bekannt.

Edit: Ein Thema in den Anfangstagen war auch, dass CryEngine angeblich gar nicht in der Lage sei, große Maps darzustellen, und auf 8x8 km³ beschränkt zu sein. Das war freilich niemals ein Problem für CIG, wohl es einige Techniken gibt, die dieses Problem umgehen. Laut Ben Lesnick wollte CIG anfangs wohl mit "Infinite Mapping" arbeiten (vielleicht kannst du erklären, wie diese Technik funktioniert), aber weil dieser Ansatz in einem MMO-KOntext einige unangenehme Workarounds erforderte, hat man sich letztendlich entschieden, den zeitaufwändigen aber sauberen Weg zu gehen und die Engine auf einen Koordinatenraum umzustellen, in dem stellare Distanzen nativ dargestellt werden können.

Lukewarm schrieb:

@CryPosthuman
Ich gebe zu, dass ich nur widergebe, was ich in einschlägigen Entwicklungsforen gelesen habe (fernab von allen Diskussion rund um existierende Videospiele). Eines dieses Details war, dass es die CryEngine wohl nicht mögen soll, wenn man sie mit prozeduralen Meshes füttert. Wenn das aber so gar nicht stimmt - vielleicht ging es in der erwähnte Diskussion um eine sehr spezifische Anwendung dieser Technik - dann nehme ich das gerne so hin. Dass die Yerli-Brüder immer schon sehr an Prozeduralen Technologien interessiert waren, ist mir hingegen bekannt.

Edit: Ein Thema in den Anfangstagen war auch, dass CryEngine angeblich gar nicht in der Lage sei, große Maps darzustellen, und auf 8x8 km³ beschränkt zu sein. Das war freilich niemals ein Problem für CIG, wohl es einige Techniken gibt, die dieses Problem umgehen. Laut Ben Lesnick wollte CIG anfangs wohl mit "Infinite Mapping" arbeiten (vielleicht kannst du erklären, wie diese Technik funktioniert), aber weil dieser Ansatz in einem MMO-KOntext einige unangenehme Workarounds erforderte, hat man sich letztendlich entschieden, den zeitaufwändigen aber sauberen Weg zu gehen und die Engine auf einen Koordinatenraum umzustellen, in dem stellare Distanzen nativ dargestellt werden können.

Zum Vergrößern anklicken....

Jep, wenn du da in dem Thema mal etwas rumgoogles, findet man häufig Problembehandlungen/Workarounds für die CryEngine 3! Ergo, zum Start der SC Entwicklung. Kann vielleicht sogar sein, dass Crytek im Zuge der Star Citizen Entwicklung und der Engine Weiterentwicklung die Engine in der Hinsicht verbessert hat. Also ich weiß, dass die Map beschränkung in der CryEngine (ohne Nummer, also 4) nichtmehr bestand - dem nach in der 5er auch nicht.
Ebenso mit der prozeduralen Sache. Man findet noch viel Probleme zu dem Thema aus CryEngine 3 Zeiten.

Was viel interessanter ist, wo ständig auf der UE4 rumgeritten wird - die Frostbyte wäre wohl die bessere Alternative gewesen. Die soll, was ich so gehört habe (kenne über eine Ecke einen DICE Entiwckler) sehr große Ähnlichkeit zu CryEngine haben. In technischer/Workflow Hinsicht natürlich - das Rendering und Optik etc. ist was anderes.
Vielleicht wäre Chris Robert ja sogar an eine Lizenz dafür gekommen. Der sollte ja noch Leute kennen, die Leute kennen die bei EA arbeiten..

Ich habe in der Zwischenzeit ein wenig herum gegoogelt und bin auf den Begriff "Level Streaming" gestoßen. Das ist wohl das übliche Verfahren, um aus vergleichsweise kleinen Maps große Welten zu bauen, und das soll wohl eine der großen Stärken der CryEngine sein, was vielleicht auch ein Grund gewesen ist, warum sich Chris Roberts für die CryEngine entschieden. Wenn ich das Verfahren richtig verstehe, wird der Spieler einfach von einer Map in die nächste "gestreamt", wenn er das Ende der Map erreicht. Der Clou (in CryEngine) ist, dass der die nächste Map schon geladen und sichtbar ist, ehe man die Map betritt. Dieser Ansatz funktioniert wohl auch sehr gut für Single-Player-Spiele (benutzt nicht auch Kerbal Space Program eine ähnliche Technik?). Schwierig wird es offenbar in Multiplayer-Spielen, wenn mehrere Spieler auf verschiedenen Seiten einer Map-Grenze unterwegs wird (klingt für mich als Laie auch einleuchtend).

Stimmt das soweit?

Das Problem für CIG war nun wohl, dass sie es sehr genau nehmen und die Position von Objekten millimetergenau erfassen möchten und müssen. Mit derartig feinen Größenskalen fallen aber auch die Maps sehr klein aus, so dass Sternensysteme aus unzähligen kleinen Maps zusammen gesetzt werden müssten. Und an jeder Map-Grenze hätte CIG vor dem Problem gestanden, die Position bewegter Objekte zwischen den Maps übertragen zu müssen. Das ist CIG auf Dauer wohl zu blöd geworden, wohl auch mit Blick auf Raumkämpfe, in denen schnelle hunderte Objekte auf dem Bildschirm und zwischen den Maps (oder Layers) herum schwirren. Also hat man sich entschieden, den verfügbaren Zahlenraum auf 64 bit zu erweitern, so das ganze Sternensysteme mit einer Präzision von einem Millimeter in den verfügbaren Zahlenraum bzw. auf eine Map passen.

JohnCarpenter schrieb:

Ich finde es etwas befremdlich, dass sich Roberts bei einem Crowdfounding finanziertem Projekt diese dezental verteilten Studios leistet. Sowas kennt man, wenn überhaupt, doch nur von den ganz Großen der Branche. Und selbst da werden dann i.d.R. verschiedene Spiele an verschiedenen Standorten entwickelt. Es scheint zwar so, dass CIG auch Vorteile daraus zieht, in dem er die Teilaufgaben dort hin verlagert, wo er die passenden Leute hat; es bleibt aber eine "Luxuskonstellation".

Zum Vergrößern anklicken....

Nur mal als Anmerkung für alle.

Chris Roberts musste CIG von Null an aufbauen, das vergessen hier auch gerne viele. Er startete also nicht mit einem eingespielten Team von 300 Mitarbeitern, er musste sich erst mal Mitarbeiter besorgen oder die Arbeit ausgliedern, wie z.B. bei Star Marine. Auch musste er erst mal selbst lernen Manager zu werden, denn diese Arbeit die er jetzt macht hat er ja auch noch nie in diesem Ausmaß gemacht.

Das die Entwicklung daher lange dauert, gute Mitarbeiter und gute externe Studios finden ist sicher nicht einfach, besonders nicht vor der Haustür, sollte klar sein. Und das Chris Roberts in diesen auch für ihm recht unbekannten Gefilden Fehler macht, sollte auch jedem klar sein. Wäre Star Citizen nicht sein "Baby" würde er sich sicher nicht diesem Stress aussetzen. Ich möchte nicht wissen wie viele gestandene Manager schon längst das Handtuch geworfen hätten bei diesem Druck.

Also ich möchte mit ihm nicht tauschen und 99,9% von denen hier die immer nur Meckern auch nicht.

Man sollte einfach mal schauen was CIG und die Externen schon geleistet haben. Bei der CitizenCon wurde das gezeigt was man seit letzten Dezember selbst testen konnte. Aber es wurde vorher behauptet das es nicht möglich sein wird, sondern nur eine einfache überarbeitete Demo ist. Dieses Jahr haben wir was feines auf der Gamescom gesehen und auch das werden sie schaffen. Scheinbar glaubt das sogar langsam Derek Smart, auch wenn er jetzt durch den Artikel wieder mehr angreift. Vorher war er verdammt ruhig und hat andere Spiele schlecht gemacht.

Ich warte jetzt seit 4 Jahren und habe schon viel Geld rein gesteckt, denn ich glaube das so ein Spiel nur Chris Roberts verwirklichen kann. Und was ich jetzt schon sehe ist etwas, das ich mir damals nicht mal ansatzweise vorstellen konnte. Wenn es nur Teilweise so wird wie er es geplant hat, dann wird es die Best Damn Space Sim Ever.

Lukewarm schrieb:

Stimmt das soweit?

Zum Vergrößern anklicken....

Hatten wir hier schonmal ausführlich besprochen (auf der nächsten Seite gehts weiter).

Lukewarm schrieb:

Das Problem für CIG war nun wohl, dass sie es sehr genau nehmen und die Position von Objekten millimetergenau erfassen möchten und müssen. Mit derartig feinen Größenskalen fallen aber auch die Maps sehr klein aus, so dass Sternensysteme aus unzähligen kleinen Maps zusammen gesetzt werden müssten. Und an jeder Map-Grenze hätte CIG vor dem Problem gestanden, die Position bewegter Objekte zwischen den Maps übertragen zu müssen. Das ist CIG auf Dauer wohl zu blöd geworden, wohl auch mit Blick auf Raumkämpfe, in denen schnelle hunderte Objekte auf dem Bildschirm und zwischen den Maps (oder Layers) herum schwirren. Also hat man sich entschieden, den verfügbaren Zahlenraum auf 64 bit zu erweitern, so das ganze Sternensysteme mit einer Präzision von einem Millimeter in den verfügbaren Zahlenraum bzw. auf eine Map passen.

Zum Vergrößern anklicken....

2 Millimeter (32bit) ist natürlich viel zu ungenau^^

Für Planeten mit mehreren 1000 Km Durchmesser, einer Geschwindigkeit von etlichen Km/s und einer unebenen Oberfläche ist diese Genauigkeit überflüssig und Spieler gesteuerte Schiffe können schon aufgrund von Latenzen nicht Millimeter genau synchronisiert werden.

Das aktualisieren bewegter Objekte stellt kein Problem dar, es ist eine der großen Stärken des 3x3 Systems. Und selbst wenn es ein Problem wäre würde das verdoppeln der Auflösung das Problem nicht lösen sondern eher vergrößern.

LSD-Goat schrieb:

(...)
2 Millimeter (32bit) ist natürlich viel zu ungenau^^

Für Planeten mit mehreren 1000 Km Durchmesser, einer Geschwindigkeit von etlichen Km/s und einer unebenen Oberfläche ist diese Genauigkeit überflüssig und Spieler gesteuerte Schiffe können schon aufgrund von Latenzen nicht Millimeter genau synchronisiert werden.

Das aktualisieren bewegter Objekte stellt kein Problem dar, es ist eine der großen Stärken des 3x3 Systems. Und selbst wenn es ein Problem wäre würde das verdoppeln der Auflösung das Problem nicht lösen sondern eher vergrößern.

Zum Vergrößern anklicken....

Doch genau diese 2 millimeter sind ein Problem ... konnte man schön auch in den ersten Arena Commander Versionen beobachten. Je weiter weg vom Ursprung des Weltkoordinatensystems war desto mehr rundungsfehler schlichen sich bei der Positionierung ein, was dazu führte das A) das schiff zitterte durch fehlerhafte Positionierung, B) das HUD wackelte und C) Texturflackern auftrat weil mal die eine Texture dann die Andere Textur als 'oberste' Textur berechnet wurde.

32Bit ist solange kein Problem solange du dich auf 12x12km beschränkst, wenn du aber hunderttausende mal hunderttausende Kilometer mit 32 Bit versuchst dar zu stellen hast du tierische Rundungsfehler.

LSD-Goat schrieb:

2 Millimeter (32bit) ist natürlich viel zu ungenau^^ .

Zum Vergrößern anklicken....

Die Größe des verfügbaren Zahlenraumes steigt exponentiell mit der Umstellung auf 64 bit. Der Unterschied zwischen 32 und 64 bit ist nicht "doppelt so groß"! Die mögliche Ausdehnung der Maps in Star Citizen hat sich von einigen Quadratkilometern auf Astronomische Einheiten vergrößert (wenn ich mich recht entsinne mindestens die halbe Größe des Sonnensystems). Diese Umstellung war offenbar auch wichtig für die Art und Weise, wie das Spiel Datenströme strukturiert und priorisiert, was widerum von entscheidenden Bedeutung für die Effizienz des Netcodes ist. Von diesem Thema verstehe ich aber noch weniger als von den Herausforderungen, Large World Maps in gängen Game-Engines zu realisieren, also möchte ich dazu nicht viel sagen.

LSD-Goat schrieb:

2 Millimeter (32bit) ist natürlich viel zu ungenau^^

Zum Vergrößern anklicken....

Sorry, kann mir folgendes nicht verkneifen. Das es sich bei 64bit nicht einfach verdoppelt ist dir schon klar? Du glaubst doch auch nicht das man durch ein i5-3470 Quad-Core Processor 3.2 GHz auf einmal 12.8 GHz hat.