Modifizierbarkeit von CiM2

Offenbar ist man sich bei Colossal Order wohl so langsam im Klaren darüber, das man sich mit der Wahl der Engine reichlich verzettelt hat. Immerhin klingt das ganze schonmal sehr einsichtig:

co_martsu:

Zitat

We changed the game engine from CIM1 to CIM2 and I didn't realize how unmoddable CIM2 turned out to be. I can assure you that Colossal Order has always allowed modding and will in the future. I believe that a stong modding ommunity only makes a game better. We'll definitely try to take modding into consideration better in the future, though some engine limitations can't be fixed I guess.

Quelle

Ich frage mich was sie mit dem Satz meint: "We'll definitely try to take modding into consideration better in the future." Heisst das, es besteht Hoffnung, dass CIM2 wenigstens "etwas" mehr fürs Modding geöffnet wird? Oder ist das ein versteckter Hinweis auf Pläne für Teil 3?

Die werden sich hoffentlich hüten für einen dritten Teil diese bescheidene Engine zu nutzen ...

Ich finde auch, dass die Engine hier schlechter dargestellt wird als sie ist. Es liegt im Endeffekt am Entwickler, welche Features der Engine benutzt werden und ob Routinen als Skript oder Hardcoded integriert werden.
Wenn man das Spiel von Anfang an auf Modding ausgelegt, ist dies auch mit Unity umsetzbar. Das hat anton95 ja gerade noch mal erwähnt und auch ich habe in einem früheren Post auf KSP verwiesen.
So wie CiM2 jetzt aktuell aufgebaut ist, ist der Umstieg auf Moddingfreundlichkeit natürlich ein weiter Weg, den die Entwickler (verständlicherweise) nicht unbedingt gehen wollen.
Beim nächsten neuen Projekt kann man ohne Probleme auch wieder Unity nutzen, die Entwickler müssen nur von Anfang an möglichst viele Teile des Spiels offener gestalten (Fahrzeuge in Ordnerstrukturen (oder offenen Formaten) ablegen oder zumindest die Möglichkeit geben externe Objekte zu laden/ Routinen als Skripte abzuspeichern).

Ich glaube einfach bei CiM2 hat CO sich zu sehr auf Unity verlassen. Zum Beispiel: Die Dateistrukturen sind komplett von Unity übernommen, die Maps und Savefiles erscheinen einem teilweise wie unkomprimierte Speicherkopien... (Wenn man beachtet, wie viel man alleine durch zippen an Platz sparen könnte). Auch das ist verständlich, wenn man bedenkt, dass CO mit wenig Ressourcen (sowohl Geld als auch Mitarbeiter) ein Spiel auf die Beine gestellt hat... Aber in dieser Hinsicht ist es natürlich schade für uns als Community.

KSP benutzt scheinbar einen eigenen Objekt Loader. Unity Runtime kann erst mal leider gar nichts, außer das Mesh per Hand zu importieren.
Wobei es ja genügenden externe Ressource zu kaufen die dies ermöglichen. Einfach nach Unity3D und objimorter suchen, wobei da wieder das Problem mit Animationen gibt.
Collada scheint leider nicht als fertiges Paket geben.

Theoretisch könnte man das DataStoreBundle auch aus einer Text Datei oder xml Datei laden im Spiel via Code.

Das mit den Maps sind keine Speicherdumps. (TTD macht das zum Beispiel), sondern gehen auch durch einen eigenen Code(Serializer), ich würde da aber eine Tonne an Zusatz Info einbauen, das würde dann auch Fehler direkt aufzeigen.

Für einen reinen Import via Unity3D zu einen Bundle habe ich schon ein paar Ideen. Dafür müsste ich aber erst mal ein Bundle komplett auf das wesentliche herunter reduzieren. Dazu hab ich aber gerade keine Lust. Da das mit einer Tram wohl als Anfangsprojekt zu schwer ist, werde ich mich wohl noch mal mit einem "Landmark" Objekt versuchen.

Es gibt theoretisch noch eine andere Möglichkeit. Man schreibt einen C# DLL die direkt mit Unity und CIM2 kommuniziert, dafür müsste man aber CIM2 an vielen stellen Patchen damit die Funktioneb der DLL aufgerufen werden. Aber dazu hab ich erst recht keine Lust, warum sollte ich dafür mehrere Wochen Arbeit investiere?
Und mit jeder Spiel Version gibt es wieder Probleme.