Star Citizen Star Citizen [PreRelease Sammelthread] Teil II

[charmin]

Die Polaris gefällt mir schon sehr gut... Zu doof das das Teil so groß ist.

 

[shoKuu]

Nein, einfach nur Hobby und die Möglichkeit sowas in der Firma zu erstellen.

 

[DOCa Cola]

Ich habe gerade eine sehr schöne Artikelreihe zum erstellen eines effektiven Game Network Protokolls gelesen
http://gafferongames.com/building-a-game-network-protocol/

Ist wirklich sehr lesenswert.

Ganz zum Schluss habe ich dann allerdings gesehen, dass der Typ wohl seit einiger Zeit dabei ist eine OpenSource Bibliothek mit dem Namen libyojimbo zu schreiben und dabei sowohl via Patreon als auch von verschiedenen Corporate Sponsoren unterstützt wird.

Da habe ich natürlich sofort auf GitHub nachgeguckt und was muss ich da lesen, wer Gold Sponsor der Bibliothek ist? Kein Anderer als Cloud Imperium Games.

Ich war schon kurz davor im CIG Forum diese Artikelreihe den Developern zu posten, aber ich denke das kann ich mir ja dann sparen.


EDIT:
Anscheinend wurde der Typ als Contractor über seine extra dafür gegründete Firma angeworben, wie es aussieht: http://thenetworkprotocolcompany.com/

Ja, das ist in der Community schon ziemlich lange bekannt. Unklar ist ob CIG genau diese lib überhaupt nutzen wird. Die Lib ist prinzipiell auch nur dafür da um Daten zwischen Clients auszutauschen. Du schmeißt Daten rein und Sie kommen beim Client an. Und ich denke nicht, dass das das größte Problem ist, dass der Client in Sachen Netzwerk im moment hat. Das Problem ist, dass alle Updates einer gesamten Instanz bei jedem einzelnen Spieler der sich auf dem selben Server befindet ankommt. Zudem werden Objekte höchst ineffizient erstellt. D.h wenn ein großes Schiff spawned (wie die Starfarer) müssen teils mehrere Megabyte(!) an Daten an alle auf dem Server befindliche Spieler verschickt werden. Auch derjenige bekommt diese Daten, obwohl er das Schiff selbst im Spiel niemals zu sehen bekommt, weil er sich an einer völlig anderen Stelle befindet.
Eine Sache wie man soetwas erstmal optimieren kann ist statt wie jetzt, dass jedes einzelnes Objekt aus dem eine Starfarer besteht an jeden Client einzeln Übermittelt wird (mehrere 100-1000 Objekte) sollte einem Client nur noch gesagt werden, dass er z.B eine Starfarer spawnen soll. Der standard Bauplan ist jedem Client bekannt - und dann wird noch noch beschrieben wie sie von diesem Bauplan abweicht. Das ist ein Problem was sich verhältnismäßig einfach (für sich genommen) noch umsetzbar ist.

Der heilige Gral in dieser Sache ist nun zweierlei. Einmal eben nur die Daten zu versenden, die für denjenigen Spieler relevant sind und 2. in der Lage zu sein diese Daten hereinzustreamen falls der Spieler dann doch mal irgendwann ein Schiff später zu Gesicht bekommt. In einem so komplexen Spiel wie Egoshootern ist das unheimlich schwierig und fehleranfällig, weil man einerlei eben darauf optimieren muss die Daten möglichst nicht zu versenden und anderweitig entscheiden muss wann die Daten gesendet werden. Man muss dabei nämlich einige Vorraussagen während dem Spiel treffen. Man kann Daten auch nicht erst im allerletzten moment hereinstreamen. Denn sagen wir mal, dass man eine sich nähernde Starfarer erst läd, wenn der Spieler sie sehen kann kommt es gezwungenermaßen zu Laderucklern oder aufpoppen des Schiffs aus dem nichts. D.h das Spiel muss im Vorraus erahnen, dass schon womöglich eine Situation eintritt in die das Schiff von einem Spieler gesehen werden kann. Dabei darf es aber nicht zu großzügig sein, sonst läd man wieder eine Menge Daten, die man nicht benötigt. Man kann da auch nicht eine generelle Lösung für soetwas schreiben, sondern es muss stark auf das Spiel zugeschnitten sein. Die Gefahr von Fehlern ist dabei immer extrem groß. Nicht nur zu im Vorraus zu wissen wann Daten bei einem Spieler sein müssen, sondern, dass auch alles entsprechend syncron dann erscheint, sodass jede zerbrochene Kaffeetasse auf einem Raumschiff und Zustand eines hochgeklappten Klodeckels bei allen Spielern gleich sind. Und nicht nur das, sondern eben eventuell auch der Zustand eines kleinen FPS levels. Es könnte ja sein, dass sich gerade Spieler auf der Starfarer ein Feuergefecht liefern. Dadurch kommen noch einige mehr verkomplizierende Faktoren mit rein. Das sind unheimlich filigrane timing Geschichten. Mir fallen ein dutzend szenarien ein wo falsches Timing dann Probleme bereiten könnte bzw dann für den Spieler bei dem die Raumschiffe/Spieler gerade hereingestreamed werden komisch aussieht.

Ein weiterer Faktor den man nicht vernachlässigen kann ist, dass das ganze ja nicht nur mit einer handvoll Spielern auf einem Server funktionieren soll, sondern eventuell mit hunderten oder tausenden. Ich möchte nicht in der Haut desjenigen stecken, der das gerade programmiert. Ich denke CIG muss da eine Menge schwarzer Magie aufwenden um das genau richtig hinzubekommen. Ich weiß ehrlich gesagt nicht, wie sie ein paar der Aspekte überhaupt lösen wollen ohne Einschränkungen in Kauf zu nehmen.

Wie gesagt, all das ist nicht in dieser Library drin. Die ist nur ein Werkzeug dafür Daten zwischen Spielern auszutauschen. Ich erwarte ehrlich gesagt auch nicht, dass das in 3.0 perfekt funktionieren wird. Bis CIG ihr Networking perfektioniert hat, werden noch Jahre vergehen. Vor allem weil Networking scheinbar erst seit kurzem im Fokus von CIG zu stehen scheint.

 

[Thor76]

Anhang anzeigen 601223

Hier mal ein aktueller Entwurf meines neuen Gehäuses. Folie befindet sich morgen im Plotter und dann experiementiert, ob es einwandfrei auf dem Gehäuse kleben bleibt. Mal sehen in wie weit sich sowas verzieht. Sobald das Gehäuse fertig ist, werde ich mal paar Fotos posten. Custom-Wasserkühlung, SSD Aufkleber werden auch geplottet, neue Kabel gesleevt, usw...

Jetzt weiss ich endlich warum sich meine Frau zu Weihnachten einen Plotter gewünscht hat. Das Ding ist ja doch zu etwas nütze.

sent via mobile device

 

[shoKuu]

Plotter und Fensterfolie in Kombination sind für viele Dinge nützlich!

 

[noxon]

Ja, das ist in der Community schon ziemlich lange bekannt.

Das habe ich wohl auch bemerkt, als ich anschließend danach gegoogelt habe.
War mir jedenfalls neu.

Unklar ist ob CIG genau diese lib überhaupt nutzen wird.

Ich glaube schon, denn merkwürdigerweise werden genau die Dinge, die Gaffer in seinem Blog beschreibt und in seiner Bibliothek implementiert hat, wie zum Beispiel Data Reduction, Object Serialisierung und das Packet Ordering demnächst auch mit dem Patch in 2.6.1 integiert.

Die Lib ist prinzipiell auch nur dafür da um Daten zwischen Clients auszutauschen.

Die Clients kommunizieren in SC nicht direkt untereinander. Das geht alles über den Server.
Ein Problem scheint im Moment noch die sehr große Datenmenge zu sein. Ein Update scheint momentan noch in 3 UDP Pakete aufgeteilt werden zu müssen. Das ist sehr problematisch, da nicht nur die Datenmenge sehr groß ist, sondern auch, weil UDP nicht garantiert, dass Pakete in der korrekten Reihenfolge ankommen und auch nciht garantiert, dass ide Pakete überhaupt ankommen.
Solche Pakete wieder korrekt zusammenzusetzen und auszulesen ist dann schon etwas problematisch. Ziel sollte es sein, die Größe der Updates auf unter 1024 Bytes zu drücken, so dass man wieder alles in 1 UDP Paket quetschen kann, so wie das alle anderen Spiele auch machen.
Zudem wollen sie jetzt noch eine leichte Form des Message Ordering einführen, womit dann dem Server besser mitgeteilt werden kann welche Pakete er bei Bedarf nochmal schicken soll und welche er nicht mehr schicken braucht.

Eine Sache wie man soetwas erstmal optimieren kann ist statt wie jetzt, dass jedes einzelnes Objekt aus dem eine Starfarer besteht an jeden Client einzeln Übermittelt wird (mehrere 100-1000 Objekte) sollte einem Client nur noch gesagt werden, dass er z.B eine Starfarer spawnen soll. Der standard Bauplan ist jedem Client bekannt - und dann wird noch noch beschrieben wie sie von diesem Bauplan abweicht. Das ist ein Problem was sich verhältnismäßig einfach (für sich genommen) noch umsetzbar ist.

Jup.
http://gafferongames.com/building-a-game-network-protocol/reading-and-writing-packets/

Mir scheint es sehr, als ob der genau den zustand von SC dort beschreibt.
Zurerst wie es jetzt funktioniert und dann wie es demnächst funktionieren wird.

Denn sagen wir mal, dass man eine sich nähernde Starfarer erst läd, wenn der Spieler sie sehen kann kommt es gezwungenermaßen zu Laderucklern oder aufpoppen des Schiffs aus dem nichts. D.h das Spiel muss im Vorraus erahnen, dass schon womöglich eine Situation eintritt in die das Schiff von einem Spieler gesehen werden kann.

Ich denke das ist kein Problem. Das funktioniert ja auch mit viel größeren Datenmengen, wie kompletten Planeten und Gigabyte großen Landezonen. Das Zonesystem und die kommenden Object Container werden das Streamingproblem glaube ich schon in den Griff kriegen.

Nicht nur zu im Vorraus zu wissen wann Daten bei einem Spieler sein müssen, sondern, dass auch alles entsprechend syncron dann erscheint, sodass jede zerbrochene Kaffeetasse auf einem Raumschiff und Zustand eines hochgeklappten Klodeckels bei allen Spielern gleich sind.

Das wird glaube ich nocht wirklich so gelöst. Die internen Zonen werden nicht gesynct, wenn du das Raumschiff nur von außen siehst. Dann spielt es für dich ja keine Rolle, was intern auf dem Schiff passiert.
Selbst die Turrets müssen ab einem gewissen LOD Level nicht mehr gesynct werden und sowas. Du musst zwar noch wissen in welche Richtung die Schüsse geschossen werden, aber die Ausrichtung der Turrets muss du nicht mehr syncen, weil diese eh nicht mehr erkennbar ist.
Das sind Optimierungen, die sicherlich noch alle kommen werden und letztendlich dafür sorgen werden, dass das Datenvolumen deutlich sinken wird.

Und nicht nur das, sondern eben eventuell auch der Zustand eines kleinen FPS levels. Es könnte ja sein, dass sich gerade Spieler auf der Starfarer ein Feuergefecht liefern.

Davon wirst du von außen glaube ich rein gar nichts mitbekommen. du wirst noch nciht einmal wissen, wer überhaupt an Bord ist, solange das nicht nötig ist.

Wie gesagt, all das ist nicht in dieser Library drin. Die ist nur ein Werkzeug dafür Daten zwischen Spielern auszutauschen. Ich erwarte ehrlich gesagt auch nicht, dass das in 3.0 perfekt funktionieren wird. Bis CIG ihr Networking perfektioniert hat, werden noch Jahre vergehen. Vor allem weil Networking scheinbar erst seit kurzem im Fokus von CIG zu stehen scheint.

Zwischen Networking und einem effizienten Game Netwrkprotocoll und der implementation des Cloud-Backends ist auch ein großer Unterschied.
Beim Einen geht es wirklich nur darum die Daten in möglichst effizienter Form mit dem Backend auszutauschen. Dafür wird diese Bibliothek verantwortlich sein. Der deutlich schwierigere Teil wird die Implementatiierung des Servers auf der AWS sein. dort muss natürlich auch gehörig optimiert und clever entschieden werden welche Daten überhaupt synchronisiert werden müssen.
So wird man hoffentlich auch Daten mit unterschiedlichen Prioritäten verschicken oder aber auch mit unterschiedlichen Updateraten und sonstigen Dingen.

 

[DOCa Cola]

Die Clients kommunizieren in SC nicht direkt untereinander. Das geht alles über den Server.
Ein Problem scheint im Moment noch die sehr große Datenmenge zu sein. Ein Update scheint momentan noch in 3 UDP Pakete aufgeteilt werden zu müssen. Das ist sehr problematisch, da nicht nur die Datenmenge sehr groß ist, sondern auch, weil UDP nicht garantiert, dass Pakete in der korrekten Reihenfolge ankommen und auch nciht garantiert, dass ide Pakete überhaupt ankommen.
Solche Pakete wieder korrekt zusammenzusetzen und auszulesen ist dann schon etwas problematisch. Ziel sollte es sein, die Größe der Updates auf unter 1024 Bytes zu drücken, so dass man wieder alles in 1 UDP Paket quetschen kann, so wie das alle anderen Spiele auch machen.
Zudem wollen sie jetzt noch eine leichte Form des Message Ordering einführen, womit dann dem Server besser mitgeteilt werden kann welche Pakete er bei Bedarf nochmal schicken soll und welche er nicht mehr schicken braucht.

Da denke ich eben, dass sie vielleicht doch nicht (komplett) auf diese Library zurückgreifen, wenn sie jetzt Anfangen ihre eigenen Tweaks reinzumischen. Es wäre ja jetzt sinnfrei noch Entwickelerresourcen auf die Optimierung der alten (low level) network library anzusetzen.
Also klar, ich habe schon gehört, dass teils komplette states in purem XML übertragen werden. Aber das ist ja nur der Inhalt des Datenpaketes. Wie und in welchem Zustand UDP pakete beim Client ankommen ist natürlich viel low leveliger. Ich denke so beknackt die CryEngine Netzwerk Lib sein möge, wird sie das sicherlich aktuell schon ordentlich hinbekommen.

Jup.
http://gafferongames.com/building-a-game-network-protocol/reading-and-writing-packets/

Mir scheint es sehr, als ob der genau den zustand von SC dort beschreibt.
Zurerst wie es jetzt funktioniert und dann wie es demnächst funktionieren wird.

Das beschreibt nur die Daten Serialisierung anhand eines Beispiels für die Lib. Runtergebrochen auf Bytelevel statt komplette json/xml strings whatever sollte auch das minimum sein, wie man seine Netzwerkkommunikation löst. Aktuell ist es ja scheinbar XML. Das das beknackt ist war den Devs bei CIG sicher auch schon vorher klar.
Ich hatte mir den Code von der Lib in dem Bezug schon vor ner Weile angesehen. Die wrappt das ganze halt einfach noch schön, dass man Bytepakete ziemlich Idiotensicher bauen kann. Mit den typischen tricks Bools noch als Bits zu speichern. Ist jetzt mal absolut nichts besonderes das so zu machen, sondern eher die Norm. Vor 10 bis 15 Jahren wäre auch noch niemand auf die Idee gekommen pures XML in eine Netzwerkpaket zu packen.

Ich denke das ist kein Problem. Das funktioniert ja auch mit viel größeren Datenmengen, wie kompletten Planeten und Gigabyte großen Landezonen. Das Zonesystem und die kommenden Object Container werden das Streamingproblem glaube ich schon in den Griff kriegen.

Wird definitiv spannend, wie problemlos das funktioniert, wenn du wirklich dynamische Umgebungen hast. D.h Umgebungen die sich vielleicht noch während du gerade das erste State update erhältst schon wieder geändert haben. Das man das in den Griff bekommen kann bin ich mir sicher, aber das sind einige viele Faktoren die da zusammenkommen.

Das wird glaube ich nocht wirklich so gelöst. Die internen Zonen werden nicht gesynct, wenn du das Raumschiff nur von außen siehst. Dann spielt es für dich ja keine Rolle, was intern auf dem Schiff passiert.
Selbst die Turrets müssen ab einem gewissen LOD Level nicht mehr gesynct werden und sowas. Du musst zwar noch wissen in welche Richtung die Schüsse geschossen werden, aber die Ausrichtung der Turrets muss du nicht mehr syncen, weil diese eh nicht mehr erkennbar ist.
Das sind Optimierungen, die sicherlich noch alle kommen werden und letztendlich dafür sorgen werden, dass das Datenvolumen deutlich sinken wird.

Davon wirst du von außen glaube ich rein gar nichts mitbekommen. du wirst noch nciht einmal wissen, wer überhaupt an Bord ist, solange das nicht nötig ist.

Ja, und das ist genau das was ich meine. Das ist leicht gesagt, aber alles andere als trivial. Was machst du, wenn z.B jemand an einem Fenster steht. Siehst du den dann von aussen, oder siehst du da nix. Werden jetzt alle Spieler auf dem Schiff mit deinem Client gesynct, oder wird es vielleicht nur eine partielle Zone, bei der dann einzelne Spieler wieder gesynct werden?
Da kann man sich noch viele tolle Szenarien ausdenken bei dem solche Optimierungsideen zerbrechen. Vor allem weil man ja immer predicten muss, was ein Spieler als nächstes tun könnte. Sonst poppen auf deinem Bildschirm plötzlich irgendwelche Objekte direkt vor deiner Nase auf.
Als Beispiel: Wenn du eine Tür öffnest und sich dahinter ein Schiff befindet, dass noch nicht gesynct wurde. Jetzt musst du als Entwickler entscheiden ob der Server den State schon vorher an den Spieler schickt. Sonst hast du ein aufpoppen, wenn du die Tür öffnest oder kannst beobachten wie sich das Schiff langsam vor deiner Nase aufbaut, weil diverse Objekte oder Texturen für das Schiff auch noch nicht geladen waren. Wenn du jetzt aber sagst, dann streamed der Client das Schiff rein, wenn er sich schon der Tür nähert, wäre das aufpoppen vermieden, wenn man die Türe öffnet. Dann ist es aber Resourcenverschwendung, wenn der Spieler an der Tür einfach vorbeigeht und sie niemals öffnet.
Das ist echt hart richtig hinzubekommen.

Zwischen Networking und einem effizienten Game Netwrkprotocoll und der implementation des Cloud-Backends ist auch ein großer Unterschied.
Beim Einen geht es wirklich nur darum die Daten in möglichst effizienter Form mit dem Backend auszutauschen. Dafür wird diese Bibliothek verantwortlich sein. Der deutlich schwierigere Teil wird die Implementatiierung des Servers auf der AWS sein. dort muss natürlich auch gehörig optimiert und clever entschieden werden welche Daten überhaupt synchronisiert werden müssen.
So wird man hoffentlich auch Daten mit unterschiedlichen Prioritäten verschicken oder aber auch mit unterschiedlichen Updateraten und sonstigen Dingen.

Daher kommt bei mir auch erneut die Frage auf in wieweit die Lib für CIG interessant ist. Die ziehen ja eine ganz andere Netzwerkinfrastruktur hoch auf einer viel höheren Skala die Teils den Scope der Library sprengt. Vielleicht nutzt CIG Teile vom Code oder einen Fork.

 

[Zehkul]

Ja, und das ist genau das was ich meine. Das ist leicht gesagt, aber alles andere als trivial. Was machst du, wenn z.B jemand an einem Fenster steht. Siehst du den dann von aussen, oder siehst du da nix. Werden jetzt alle Spieler auf dem Schiff mit deinem Client gesynct, oder wird es vielleicht nur eine partielle Zone, bei der dann einzelne Spieler wieder gesynct werden?

Das schöne an der Star Citizen Lösung ist, dass dieser Job vereinigt ist über mehrere Disziplinen hinweg. Sowohl Rendering als auch Networking nutzen da einfach das Zone System, welches die Räume schon alle in der nötigen Hierarchie angeordnet hat.
Ich erinnere mich auch recht dumpf an irgendeinen Rewrite aus Frankfurt, in dem Sehfenstern in eine andere Zone (?) eine weitere Dimension spendiert wurde, finde aber leider gerade nichts dazu …

Wenn du jetzt aber sagst, dann streamed der Client das Schiff rein, wenn er sich schon der Tür nähert, wäre das aufpoppen vermieden, wenn man die Türe öffnet. Dann ist es aber Resourcenverschwendung, wenn der Spieler an der Tür einfach vorbeigeht und sie niemals öffnet.

Nein, ist es nicht. Weil der Spieler sie öffnen könnte. Ein Spiel muss an jedem Punkt möglichst fehlerfrei auf Spielereingaben reagieren, und klar heißt das, dass eine Menge Arbeit und Ressourcen in Dinge gehen, die nicht direkt am Schirm sichtbar sind sondern nur sichtbar sein könnten. Muss aber so sein, sonst hat man schnell ein Spiel, das crasht, sobald du mehr als 2 Items im Inventar hast und wo nur eines, das beliebteste von 20 Schiffen brauchbare Performance liefert.

Sind Physik Meshes plötzlich Speicherverschwendung, nur weil der Spieler es ja auch einfach lassen könnte, in Objekte zu rennen?

Daher kommt bei mir auch erneut die Frage auf in wieweit die Lib für CIG interessant ist. Die ziehen ja eine ganz andere Netzwerkinfrastruktur hoch auf einer viel höheren Skala die Teils den Scope der Library sprengt. Vielleicht nutzt CIG Teile vom Code oder einen Fork.

CIG ist der Hauptsponsor der Lib. Du kannst davon ausgehen, dass die Roadmap der Library (nächstes Feature: sending large messages across the unreliable-unordered channel, hmm) genauestens auf die Bedürfnisse von CIG abgestimmt ist. Klar brauchen sie mehr als nur diese Library, aber das dürfte komplett auf dieser Library aufbauen. Die gesendeten Pakete werden ja nicht großartig anders dadurch, dass man von einem instanzierten Shooter zu einem MMO geht. Die Arbeit, die diesen Schritt möglich macht, sitzt an einer komplett anderen Stelle, nämlich bei der Kommunikation zwischen den Serven. Hat mit Libyojimbo nix zu tun …

Und auch wenn die Pakete sich verändern, sollte das ziemlich problemlos ohne Fork funktionieren, wenn das Framework für Custom Pakete wie beschrieben funktioniert. (Ein Feature, das die Lib von Anfang an hatte)

 

[noxon]

Ja, und das ist genau das was ich meine. Das ist leicht gesagt, aber alles andere als trivial. Was machst du, wenn z.B jemand an einem Fenster steht. Siehst du den dann von aussen, oder siehst du da nix. Werden jetzt alle Spieler auf dem Schiff mit deinem Client gesynct, oder wird es vielleicht nur eine partielle Zone, bei der dann einzelne Spieler wieder gesynct werden?

Das selbe Problem hast du aber auch bei der Grafik. Ich denke, dass sie das bereits gelöst haben, zumindest in der Theorie.
Zones, die für andere Spieler verdeckt sind müssen nicht gesynct werden, doch sobald halt ein Fenster, eine Tür oder ein Loch zur Zone geöffnet wird musst die Synchroisierung stattfinden.

Ich könnte mir auch gut vorstellen, dass das bereits unter das Bind Culling fällt, was CIG im Production Schedule aufgeführt hat.

Wenn du jetzt aber sagst, dann streamed der Client das Schiff rein, wenn er sich schon der Tür nähert, wäre das aufpoppen vermieden, wenn man die Türe öffnet. Dann ist es aber Resourcenverschwendung, wenn der Spieler an der Tür einfach vorbeigeht und sie niemals öffnet. Das ist echt hart richtig hinzubekommen.

Definitiv, aber ich glaube dafür sollen ja diese Object Container eingeführt werden, soweit ich das verstanden habe. Das soll ja beim streamen von Daten enorm helfen und man muss diese ja auch nciht nur auf Grafik- und Geometriedaten beschränken. Das gleiche kannst du für die Physik und den Netcode nutzen.

Daher kommt bei mir auch erneut die Frage auf in wieweit die Lib für CIG interessant ist. Die ziehen ja eine ganz andere Netzwerkinfrastruktur hoch auf einer viel höheren Skala die Teils den Scope der Library sprengt. Vielleicht nutzt CIG Teile vom Code oder einen Fork.

Ich habe eigentlich den Eindruck, als ob die Bibliothek speziell für SC entwickelt wurde.
Ich stelle mir das so vor: CIG hat sich an den Typen gerichtet und gefragt, ob er nicht den Netcode für SC optimieren könne und der hat gesagt: "OK, aber nur, wenn ich den Code anschließend auch als OpenSource veröffenltichen kann".
CIG hat dem zugestimmt und anschließend hat der Typ seine 1-Mann Firma gegründet, die passenderweise ein paar hundert Meter weiter neben dem CIG Office ihren Sitz hat.

Außerdem hat CR mal das in einem 10ftc gesagt:

"So the Engineering team on the overall project, across all the studios, have a good portion of it being what we call “ring fenced”. And so rather than spending a lot of time iterating, fixing issues or bugs on 2.4 or 2.4.1 or 2.5, we’ve been working towards getting everything in place for when we bring out the bigger system and procedural planets."

Der arbeitet also anscheinend im direktem Auftrag von CIG und erstellt die Bibliothek so, wie CIg sie benötigt.
Da wäre es ja dumm, wenn sie sie nicht verwenden würden.

 

[GUN2504]

http://www.gamestar.de/news/vermischtes/3307948/die_neue_gamestar_ab_1801_im_handel.html

Ich glaub die kauf ich mir seit langem mal wieder

 

[charmin]

Danke für den Link, wird auf jeden Fall auch gekauft!

 

[Zehkul]

Ich stelle mir das so vor: CIG hat sich an den Typen gerichtet und gefragt, ob er nicht den Netcode für SC optimieren könne und der hat gesagt: "OK, aber nur, wenn ich den Code anschließend auch als OpenSource veröffenltichen kann".

Ist auch ein guter Deal. Scheinbar sind Network Programmierer konstante Mangelware, gute umso mehr, und so kauft man sich direkt einen der erfahrensten und besten ein. Als Crowd Funding Projekt sollte Star Citizen auch weniger Bedenken haben, dass eigene Technologien der Öffentlichkeit zugänglich gemacht werden, und dass der Typ quasi gegenüber der Straße sitzt, ist natürlich herrlich.

Ben Parry hat übrigens erwähnt, dass sie an einem minimalistischen Picture in Picture arbeiten würden, damit die Engine eben gerade nicht wegen des kleinen Sichtfensters auf einen anderen Charakter plötzlich anfängt, das Schiff reinzustreamen, auf dem der sitzt. Das Streamen von Zoneobjekten hinter Türen und Fenstern funktioniert also ganz offensichtlich schon, eher zu gut als zu schlecht. Je nach dem, ob CIG Photobombing überhaupt erlauben möchte (ich fänds schade wenn nicht ), würde das dann denke ich auch wieder dem Networking zugute kommen.

Die meisten Veränderungen wird es aber in einem Rutsch geben, CIGs Philosophie ist nicht, an alten Systemen herumzuoptimieren, sondern sie im Zweifelsfall von Grund auf neu zu schreiben. Gibt schöneren Code, dauert aber auch länger und man bemerkt erst dann, dass CIG überhaupt etwas getan hat, wenn Monate bis Jahre später der Code dann zum ersten Mal aktiviert wird.

 

[shoKuu]

https://drive.google.com/file/d/0Bz4I-Cj7BemrS2ZqOEZORklxT2c/edit

 

[Terrschi]

Hallo Commander,

mal eine blöde Frage: Die verlinkte CB-Flotte auf der 1. Seite, handelt es sich hierbei um eine Star-Citizen Corporation, die auch ingame besteht oder sind nur die Schiffe der CB-User aufgelistet? Falls ersteres würde ich gerne beitreten

Grüße,

Flo

@trane87
Danke!

 

[DerkleineGrisu]

: Die verlinkte CB-Flotte auf der 1. Seite, handelt es sich hierbei um eine Star-Citizen Corporation, die auch ingame besteht oder sind nur die Schiffe der CB-User aufgelistet? Falls ersteres würde ich gerne beitreten

Sind denke ich nur die Schiffe der Leute hier, wobei das auch nicht mehr stimmen dürfte da die
letzte Bearbeitung im Jahr 2015 war.

Gibt ja genug Orgs wie z.b. Freie Piloten, CRASH, Neutral Security Agency, Interstellar, Phoenix usw. die entweder rein Deutschsprechende oder Internationale sind.

 

[Roi-Danton]

https://drive.google.com/file/d/0Bz4I-Cj7BemrS2ZqOEZORklxT2c/edit

Ha, eine gute Vorlage für die Diskussion mit Kindern - auch Raumfahrer müssen regelmäßig putzen:

Staub und Schimmel sind in Raumstationen mit ihrem feuchten, warmen Klima ein großes Problem.
Jeden Samstag ist deshalb auf der ISS Hausputz angesagt.
Wegen der Schwerelosigkeit gibt es keine Wassereimer auf der Station, dafür aber Staubsauger.
Die Reinigung des Wohnbereichs mit Feuchttüchern dauert etwa fünf Stunden.

mal eine blöde Frage: Die verlinkte CB-Flotte auf der 1. Seite, handelt es sich hierbei um eine Star-Citizen Corporation, die auch ingame besteht oder sind nur die Schiffe der CB-User aufgelistet?

https://robertsspaceindustries.com/orgs/CBF

NarzissOne anschreiben, allerdings ist er (hier im Thread) bzgl Schreiben inaktiv. Ich glaube, er hat(?) oder will zumindest die Leitung an Sinclair übertragen. Jedoch sollte die Orgstruktur überarbeitet werden vor dem PU. Mit nur einem mit Rechten bei so einer großen Org ist sie für Stagnation anfällig.

 

[Terrschi]

Super, danke dir Roi-Danton
Ich werde es mal probieren!

 

[shoKuu]

Sobald die Performance besser wird und man wirklich "Handel" betreiben kann mit AC 3.0 ist der Sandbox Spaß eröffnet. So viele indirekte Rollen entstehen mit dem Handel! Einfach nur Klasse. Ich bin gespannt wie sich das ganze nachher spielt. Ich denke auch mit S&R wird man seinen Spaß haben können, da man nun Beacons erstellen kann.

 

[GUN2504]

https://drive.google.com/file/d/0Bz4I-Cj7BemrS2ZqOEZORklxT2c/edit

Trane, Danke!

Der Artikel ist wirklich gut geschrieben!

 

[shoKuu]

http://imgur.com/a/0UcDf