Umfrage: Codename: Modern Combat für Open Clonk

Projekte CMC
101

> So kann man beispielsweise spielzielspezifische Objekte wie Flaggenposten oder verbündete Spieler schon vor der eigentlichen Sichtung im Raum finden und dorthin navigieren.


Dafuer kann man doch auch fix rauszoomen und hat dann keine nervige Minimap in der Ecke? Wenn man nicht alles sehen koennen soll: Objekte koennen angeben, dass sie oberhalb des Fog of War gezeichnet werden sollen. Dann koennen diese wichtigen Punkte einfach immer angezeigt werden und man zoomt raus (d.h. dreht am Mausrad) um sie zu sehen.

> Die Auflösung der einzelnen Clienten ist dabei überflüssig, jeder sieht gleich weit.


In OC gibt man immer die Sichtweite an. Es wird dann je nach Aufloesung skaliert.
102

>Auch müssten diese Anfragen in einer hohen Frequenz dauerhaft wiederholt werden, da die Minimap sonst stark verzögert und so nutzlos wäre.


Ich meine mich daran zu erinnern, dass die Minimap in CoD etwa auch nur etwa jede Sekunde aktualisiert und trotzdem einen recht großen Vorteil bringt.
103

Nah das klingt doch mal vielversprechend, viel Erfolg mit der Idee =)

104

Für Rage-Verhältnisse ist eine Sekunde bereits eine hohe Frequenz. Das haben unsere Entwicklungen so ergeben, weshalb alle Konzepte letztenendlich leider fallengelassen wurden.

105

>>Objekte koennen angeben, dass sie oberhalb des Fog of War gezeichnet werden sollen.


Das wird von uns in Rage bereits verwendet.

Zoomen wäre eine Alternative, entspricht aber nicht dem schnellen Gameplay wo man schnell in einem hitzigen Gefecht kurz auf eine Minimap blicken kann statt manuell heraus- und hereinzoomen zu müssen, das würde sich so eher für ruhige Momente eignen.
106

Baut es aus Zappers tollen Partikeln!

107

Ist das hier eigentlich noch im Portfolio oder wurde die Idee inzwischen verworfen?

108

Ist, beeinflusst durch mehrere Faktoren, nicht über das Planungsstadium hinausgekommen.

109

Verworfen wurde es nicht offiziell, allerdings kann man es als eingefroren ansehen, da mir schlicht eine Besatzung an Scriptern fehlt um hier noch etwas sinnvolles zu reißen.
Das meiste müsste für ein OC Projekt neu erschaffen werden, und ich habe leider nicht genug Zeit um Open Clonk-spezifisches Wissen anzueignen um das alles alleine zu stämmen.

110

Zusätzlich zu dem, was Michael sagt, möchte ich auch noch folgendes anmerken:
CMC war vor R1.0 gute 3 Jahre in Entwicklung (mit Freezes etc, ja, aber trotzdem). Sagen wir einmal, ein OC-Port käme in guten 10 Monaten zustande: Wäre er dann überhaupt noch spielbar? Der Punkt an OC (und das, was es so schön macht), ist, dass sich fortwährend die Systeme verändern. Wir kennen alle, wie manche Änderungen kurzzeitig Knüppeln unspielbar gemacht haben. CMC hat aber weitaus mehr Code, auch ohne CR-Hacks. Und ich bin mir sicher, dass nicht viele Scripter freiwillig 5 Objekte neucoden, nur weil ein OC-Dev ein Interface umgecodet hat. (Trotz public - private - Dingens) Ohne stabile Basissysteme würde es ziemlich schwer werden, ein so komplexes Pack wie CMC zu portieren, und selbst wenn sich ein paar aufopfern würden, würde die Spielerzahl gering bleiben.

111

Najo, für NET2/CR gab es auch große Objektpakete, obwohl sich ständig Sachen verändert haben. CR als stabiles Ziel gibt es eigentlich erst, seit nicht mehr daran entwickelt wird. Das ist natürlich alles schon lange her, daher vergisst man das leicht…

Im Gegensatz zu dem Objektpaketen ist die Engine-Skript-API relativ stabil, da werden nur selten Sachen entfernt. Eine mögliche Lösung wäre also, nicht direkt von Objects.ocd abzuhängen, sondern benötigte Sachen von dort zu kopieren, um sie bei Bedarf kontrolliert aktualisieren zu können.

Es gibt auch aktuell einfach nicht die Motivation, besonders auf Kompatibilität zu achten. Fast aller OC-Inhalt lebt nun mal direkt im OC-Repository.

>und selbst wenn sich ein paar aufopfern würden, würde die Spielerzahl gering bleiben


Es sollte natürlich nicht um das Portieren als Selbstzweck gehen. Wenn dadurch kein besseres Spiel entstehen kann, lohnt es sich nicht.

112

>Im Gegensatz zu dem Objektpaketen ist die Engine-Skript-API relativ stabil, da werden nur selten Sachen entfernt. Eine mögliche Lösung wäre also, nicht direkt von Objects.ocd abzuhängen, sondern benötigte Sachen von dort zu kopieren, um sie bei Bedarf kontrolliert aktualisieren zu können.


Sorry, aber dieser Satz ergibt keinen Sinn. CMC soll also teilweise seine eigene Objects.ocd verwenden? Wie stellst du dir da bitte Kompatibilität mit anderen Packs vor?

>Es gibt auch aktuell einfach nicht die Motivation, besonders auf Kompatibilität zu achten. Fast aller OC-Inhalt lebt nun mal direkt im OC-Repository.


Es fördert aber auch nicht gerade die Motivation, zu entwickeln. Wie gesagt, ich will nicht *während* der Entwicklung* kaputtgegangene Sachen fixen. So gut wie der gesamte Third-Party-Content von OC ist mit 8.0 nicht spielbar, nicht mal 7.0 Szenarien. Klar ist es langweilig und schwer, die Kompatibilität zu bewahren. Aber - frech gesagt - erwartet keinen Content, wenn das keinen interessiert.
113

Das Problem mit Open Clonk ist das es mit neuen Funktionen um sich schmeißt und keine solide Basis besitzt auf der Entwickler vertrauen und ansetzen können.
Auch die Annahme, das diese doch viel bessere Engine alleine reicht, um einen Umstieg zu rechtfertigen, ist ein Trugschluss, den wo sollen betreffenden Entwickler bitte Zeit und Arbeitskraft herbekommen um die teils über Jahre herangewachsenen Pakete auf Open Clonk zu portieren.
Und das für größtenteils nicht ein mal große Änderungen. Nur weil Open Clonk in 3D gerendert wird und tolle Lichteffekte bietet, ist das noch lange kein Grund zum Umstieg und ein damit verbundenes Wegschmeißen von Clonk Rage-Paketen.
Und die wirklich wichtigen Änderungen wie eine deutlich bessere Möglichkeit der Steuerung des Spiels sind wiederum Dinge die man sicher auch in der ein oder anderen Form in Clonk Rage hätte integrieren können, was Open Clonk aus Entwicklersicht einen faden Beigeschmack gibt.

Je mehr Änderungen Open Clonk einführt, desto schwerer wird die Portierung von vorhandenen bekannten Paketen die Clonk als solches identifizieren. Und wenn es kein Content für ein neues Spiel gibt, dann gibt es auch keine Community.

Die Community wäre das andere Problem. Open Clonk wird trotz sterbender Clonk Rage Community noch immer deutlich weniger gespielt - wer soll da Interesse bekommen für diese Plattform zu entwickeln.
Auch ist der Zeitpunkt für den Release von Open Clonk ein schlechter gewesen und könnte Clonk als Ganzes den Kopf kosten - man hätte mehr für den Support von Clonk Rage tun sollen um die vorhandene Community zu erhalten und neue Spieler zu erreichen bevor man den großen Schritt wagt, eine komplett neue Version von Clonk zu starten. Über ein Steam-Angebot, mehr Youtube-Präsenz, mehr Wettbewerbe oder komplexere und dauerhafte Statistikführung für Wiederspielwert als nur die seit Jahren gleiche Liga die nichts weiter an Progression bietet als eine einzelne Zahl in einer Tabelle.

Dafür ist es jetzt aber wahrscheinlich leider schon zu spät =/

114

>CMC soll also teilweise seine eigene Objects.ocd verwenden? Wie stellst du dir da bitte Kompatibilität mit anderen Packs vor?


Ja. Welche anderen Packs? Soweit ich das verstehe, ist CMC ziemlich eigenständig und würde praktisch nichts vom eigentlichen Spielinhalt aus Objects.ocd verwenden.

Um "Mixup"-Szenarien  zu ermöglichen, könnten etwa alle IDs mit einem Präfix versehen werden.

Du stellst das so dar, als wäre das eine völlig abwegige Idee. Genau so funktioniert aber praktische alle Software unter Windows: die Win32-API als stabile Plattform und selbst mitgebrachte Bibliotheken.

>So gut wie der gesamte Third-Party-Content von OC ist mit 8.0 nicht spielbar, nicht mal 7.0 Szenarien.


Aller Third-Party-Content für 7.0 ist auch noch mit 7.0 spielbar. 7.0 ist seit etwa zwei Jahren ein stabiles Ziel. Der Schritt von 7.0 nach 8.0 ist eher mit dem Schritt von CE nach CR vergleichbar als mit irgendwelchen CR-Updates. Da gingen auch viele Sachen kaputt.

Da muss man sich eben entscheiden: Ist die Stabilität wichtig, oder braucht es bleeding-edge Features aus der aktuellen Entwicklerversion? Knüppeln und ähnliche Szenarien haben sich für letzteres entschieden und bekommen Sachen direkt in die Engine oder in Objects.ocd eingebaut, müssen sich aber umgekehrt auch auf Änderungen dort einstellen.

>Klar ist es langweilig und schwer, die Kompatibilität zu bewahren. Aber - frech gesagt - erwartet keinen Content, wenn das keinen interessiert.


Du hast selbst auch schon Änderungen eingebracht, die alle existierenden Szenarien kaputtgemacht haben. Es ist ziemlich einfach, etwas zu OC beizutragen. Wäre es dir lieber gewesen, wenn deine Änderungen im Namen der Kompatibilität zu Tode diskutiert worden wären?
115

>Ja. Welche anderen Packs? Soweit ich das verstehe, ist CMC ziemlich eigenständig und würde praktisch nichts vom eigentlichen Spielinhalt aus Objects.ocd verwenden.


Sobald CMC seine eigenen Definitionen von Objects.ocd Funktionen mitschleppt, wird es sehr schwer, die Kompatibilität mit zukünftigen Packs zu bewahren. Vielleicht bin es nur ich, aber ich habe einfach keine Lust mehr auf irgendwelche Hacks, damit 2 Packs miteinander funktionieren.

>Du stellst das so dar, als wäre das eine völlig abwegige Idee. Genau so funktioniert aber praktische alle Software unter Windows: die Win32-API als stabile Plattform und selbst mitgebrachte Bibliotheken.


Dafür habe ich auch pro Programm jedes Mal dieselbe Bibliothek mitgeschleppt, etwa Ogre oder Qt. Das ist so in etwa, wie wenn jedes Pack unter OC seine eigene Objects.ocd mitschleppt - nur, dass du extrem selten, wenn überhaupt, zwei Programme ineinander kompilieren muss - zwei Packs gleichzeitig zu aktivieren, ist aber keine Seltenheit. (Clepler 38b z.B.)

>Aller Third-Party-Content für 7.0 ist auch noch mit 7.0 spielbar. 7.0 ist seit etwa zwei Jahren ein stabiles Ziel. Der Schritt von 7.0 nach 8.0 ist eher mit dem Schritt von CE nach CR vergleichbar als mit irgendwelchen CR-Updates. Da gingen auch viele Sachen kaputt.


Was bringt es mir als Entwickler, für eine Version zu entwickeln, wenn ich genau weiß, dass das Pack in der nächsten Version kaputt ist? Gar nichts. Ähnlich wie die Western-Bugfixes: Keiner hat einfach mal verschiedene Versionen desselben Spiels aufm Rechner.

>Da muss man sich eben entscheiden: Ist die Stabilität wichtig, oder braucht es bleeding-edge Features aus der aktuellen Entwicklerversion? Knüppeln und ähnliche Szenarien haben sich für letzteres entschieden und bekommen Sachen direkt in die Engine oder in Objects.ocd eingebaut, müssen sich aber umgekehrt auch auf Änderungen dort einstellen.


Es ist nicht schlecht, wie Knüppeln zu entwickeln. Ich sage auch nicht, dass der Snapshot mit 7.0 kompatibel sein muss. Nur finde ich, dass man zumindest versuchen sollte, dass beim 8.0 Release nicht alles kaputt ist.

>Du hast selbst auch schon Änderungen eingebracht, die alle existierenden Szenarien kaputtgemacht haben. Es ist ziemlich einfach, etwas zu OC beizutragen. Wäre es dir lieber gewesen, wenn deine Änderungen im Namen der Kompatibilität zu Tode diskutiert worden wären?


Im Nachhinein hätte ich es besser gefunden, wenn die Änderungen in einem seperaten Branch getestet worden wären und, wenn alles funktioniert, vor dem Merge nach master geschaut wird, wie man die Kompatibilität bewahren kann.
116

>ich habe einfach keine Lust mehr auf irgendwelche Hacks, damit 2 Packs miteinander funktionieren.


Najo, diese Sachen kommen aber meistens hauptsächlich davon, weil diese Packs mit der Idee entwickelt wurden, dass keine unbekannten Sachen zusätzlich geladen werden.

>nur, dass du extrem selten, wenn überhaupt, zwei Programme ineinander kompilieren muss


Das schätzt du falsch ein. Abhängigkeitsprobleme dieser Art sind nicht unüblich und werden typischerweise eben durch das Umbenennen von Symbolen oder durch spezielle Linker-Features gelöst.

>Was bringt es mir als Entwickler, für eine Version zu entwickeln, wenn ich genau weiß, dass das Pack in der nächsten Version kaputt ist?


Warum entwickeln Leute Sachen für CR, wenn sie genau wissen, dass sie mit OC nicht funktionieren? Warum gibt es (neue) Software, die auf Qt4 oder GTK+2 aufbaut, obwohl es Qt5 oder GTK+3 gibt und es damit kaputt ist? Man muss sich nun mal in irgendeiner Form auf eine Version festlegen oder ständig bei der aktuellen Entwicklung mitziehen. Meistens ist die Umstellung auf eine neuere Version auch gar kein so großer Aufwand, wenn man sie in einem Rutsch macht. So sind die meisten inkompatiblen Änderungen zwischen 7.0 und 8.0 umbenannte Objekte und Funktionen, die schnell halbautomatisiert abgearbeitet werden können.

---

Als Idee für die Zukunft könnte ich mir ein Upgrade-Tool im Stil von `go fix` vorstellen, das automatisiert Skripte für die neueste Version fit macht oder zumindest Inkompatibilitäten erkennt und davor warnt, wenn eine automatische Lösung nicht möglich ist. So könnte der bisherige Entwicklungsstil beibehalten werden, aber externen Entwicklern unter die Arme gegriffen werden.
117

>Najo, diese Sachen kommen aber meistens hauptsächlich davon, weil diese Packs mit der Idee entwickelt wurden, dass keine unbekannten Sachen zusätzlich geladen werden.


Exakt. Und mit dem Mitschleppen eigener Objects.ocd - Funktionen setzt man dies teilweise auch voraus.

>Das schätzt du falsch ein. Abhängigkeitsprobleme dieser Art sind nicht unüblich und werden typischerweise eben durch das Umbenennen von Symbolen oder durch spezielle Linker-Features gelöst.


Ah, danke, gut zu wissen.

>Warum entwickeln Leute Sachen für CR, wenn sie genau wissen, dass sie mit OC nicht funktionieren? Warum gibt es (neue) Software, die auf Qt4 oder GTK+2 aufbaut, obwohl es Qt5 oder GTK+3 gibt und es damit kaputt ist? Man muss sich nun mal in irgendeiner Form auf eine Version festlegen oder ständig bei der aktuellen Entwicklung mitziehen.


Da gibt es aber einen Unterschied für den Endanwender. Es ist mir als Endanwender ~egal, ob die Software nun Qt4 oder Qt5 verwendet (außer, wenn ich den Stil festlegen will); es ist mir aber nicht unbedingt egal, wenn ich zwei verschiedene Versionen eines _Spiels_ auf dem Computer haben muss, um das Pack zu spielen.

> So sind die meisten inkompatiblen Änderungen zwischen 7.0 und 8.0 umbenannte Objekte und Funktionen, die schnell halbautomatisiert abgearbeitet werden können.
>Als Idee für die Zukunft könnte ich mir ein Upgrade-Tool im Stil von go fix vorstellen, das automatisiert Skripte für die neueste Version fit macht oder zumindest Inkompatibilitäten erkennt und davor warnt, wenn eine automatische Lösung nicht möglich ist. So könnte der bisherige Entwicklungsstil beibehalten werden, aber externen Entwicklern unter die Arme gegriffen werden.


Würde ich begrüßen.