Clonkspot Forum
| Ja, packt die Sturmgewehre und Defibrillatoren aus! | 24 | 62% | |
| Nein, zu viel 3D und kein Editor! | 15 | 38% |
Nah das klingt doch mal vielversprechend, viel Erfolg mit der Idee =)
> So kann man beispielsweise spielzielspezifische Objekte wie Flaggenposten oder verbündete Spieler schon vor der eigentlichen Sichtung im Raum finden und dorthin navigieren.
> Die Auflösung der einzelnen Clienten ist dabei überflüssig, jeder sieht gleich weit.
>>Objekte koennen angeben, dass sie oberhalb des Fog of War gezeichnet werden sollen.
>Auch müssten diese Anfragen in einer hohen Frequenz dauerhaft wiederholt werden, da die Minimap sonst stark verzögert und so nutzlos wäre.
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.
Ist das hier eigentlich noch im Portfolio oder wurde die Idee inzwischen verworfen?
Ist, beeinflusst durch mehrere Faktoren, nicht über das Planungsstadium hinausgekommen.
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.
Zusätzlich zu dem, was Michael sagt, möchte ich auch noch folgendes anmerken:
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...>und selbst wenn sich ein paar aufopfern würden, würde die Spielerzahl gering bleiben
>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.
>CMC soll also teilweise seine eigene Objects.ocd verwenden? Wie stellst du dir da bitte Kompatibilität mit anderen Packs vor?
>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.
>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.
>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.
>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.
>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?
>ich habe einfach keine Lust mehr auf irgendwelche Hacks, damit 2 Packs miteinander funktionieren.
>nur, dass du extrem selten, wenn überhaupt, zwei Programme ineinander kompilieren muss
>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?
>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.
>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.
>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.
> 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.
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.Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
Forum
