Clonk unterstützt parallaxe Objekte und Hintergründe schon eine Weile. Parallaxes Scrollen ist eine Methode, um einen 3D-Effekt allein mit 2D-Methoden zu imitieren, indem Objekte langsamer oder schneller bewegt werden wenn die imaginäre Kamera über die Landschaft bewegt wird. Dieser Ansatz funktioniert allgemein gut, aber bei geänderter Zoom-Stufe sahen seine Auswirkungen etwas ungünstig aus. Anstatt bei Zoom parallaxe Objekte und Hintergründe einfach genauso aussehen zu lassen wie die anderen Objekte, haben Clonk-Karl und ich ausgetüftelt wie sie sich verhalten würden, wären sie tatsächlich vor oder hinter der Landschaft. Die erste Frage, die es zu beantworten galt war, was verschiedene Zoom-Stufen in der virtuellen Welt darstellen: Ändert sich der Abstand zwischen Kamera und Landschaft, oder verstellt sich die Kameraoptik wie bei einem Zoom-Objektiv? Letztendlich kamen wir zu dem Schluss, dass wir beides benötigten: Das Zoom-Objektiv, damit jeder Spieler ungefähr das selbe Bild sieht, unabhängig von der Pixelzahl seines Monitors, und die Distanzänderung um Zoom darzustellen. Während Zoom im echten Leben ein Zoom-Objektiv nutzt, ist dies bei echten, unmodifizierten Menschen nicht der Fall, demnach müsste sich die Distanzänderung natürlicher anfühlen.
Danach war es ganz einfach, mit Hilfe eines Diagramms herzuleiten wie die Objekte dargestellt werden sollen. Man setze einen Punkt für die Kamera, eine Linie für die Landschaft und den Bildschirm (denn sie ist immer auf der selben Ebene wie der Bildschirm. Der Bildschirm sorgt dafür, dass Himmelsinseln nicht abstürzen), und noch eine Linie für das Objekt. Dann zeichne man Linien von den Ecken des Objektes zur Kamera. Das Objekt sollte dann dort angezeigt werden, wo diese Linien den Bildschirm schneiden. Allerdings brauchten wir mehrere Durchgänge dafür, dies in die Formeln zu fassen die in der Engine verwendet werden, weil wir noch nicht völlig verinnerlicht hatten was die gegebenen Werte bedeuten. So bezeichnet die Position eines Objektes nicht den Punkt, an dem sich das Objekt in der virtuellen Welt befindet, sondern wo es in der Landschaft angezeigt wird wenn sich die Kamera an Position 0/0 befindet und der Zoomfaktor 1 ist. Und die Kamera ist an dieser Position wenn die linke obere Ecke des Bildschirms dort ist. Das ist so, als ob nur das rechte untere Viertel der Kamerasicht angezeigt würde. Der Grund ist, dass die Parallax-Berechnungen dadurch recht nett rauskommen: Beim umsetzen von Landschafts- auf Bildschirm-Koordinaten, wird einfach die Position der oberen linken Bildschirm-Ecke mit dem Parallax-Faktor multipliziert, und von der Objektposition abgezogen. Unsere ersten Diagramme hatten aber noch die Kameraposition in der Mitte des Bildschirms, was etwas verwirrend war, da dadurch die Bildschirmgröße in den Formeln auftaucht. Wir wussten aber, dass dies im Engine-Code nicht der Fall war.
Schließlich gelangten wir zu Formeln, die wir für korrekt hielten, und bauten sie in die Engine ein. Das Ergebnis war größtenteils zufriedenstellend, besonders der Himmel verhielt sich nett. Aber manche Objekte bewegten sich auf dem Bildschirm umher, wenn man den Zoomfaktor änderte, während sie sich wie erwartet bewegten wenn man nur die Kamera umher bewegte. Ich entdeckte schließlich den Grund dafür, als ich folgendes Diagramm ein paar Tage später konstruierte:
Das Diagramm zeigt eine Seitenansicht von Kamera, Landschaft, und einem Objekt. Da die Formeln für X und Y unabhängig voneinander und identisch sind, wird hier nur eine Dimension dargestellt.
Die schwarzen Abstände sind gegeben, die roten sind die, die wir berechnen wollen. Die grünen sind Zwischenergebnisse. Die gestrichelten Linien sind die Sichtlinien zwischen Kamera und Objekt.
In der oberen linken Ecke des Diagrammes befindet sich die Kamera, die die internen Objekt-Positionen definiert: Die Position eines Objektes ist dort, wo diese Kamera das Objekt in der Landschaft sehen würde. Etwas weiter rechts ist eine Kamera an Position 0/0, aber mit einem anderen Zoomfaktor (genannt „Zoom“). Unsere erste Version verwechselte diese Kamera mit der erstgenannten. Für Objekte an Position 0/0 macht das keinen Unterschied, was auch erklärt warum der Himmel richtig funktionierte: Wir testeten nur in einem Szenario, in dem sich der Himmel nicht mit dem Wind mitbewegte.
Unterhalb der zweiten Kamera ist die dritte, die, für die die Berechnungen gemacht werden sollen. Sie hat einen Abstand „TargetX“ vom Ursprung, und einen Zoomfaktor „Zoom“, wie die zweite Kamera.
Rechts ist das Objekt, das dargestellt werden soll. Es ist hinter der Landschaft, aber glücklicherweise funktionieren die Formeln genauso gut für Objekte vor der Landschaft. Sein Abstand zur ersten Kamera auf der Z-Achse ist „1/Par“, wobei „Par“ der Parallax-Faktor ist. Folglich ist der Abstand zur Landschaft „1/Par-1“, weil die erste Kamera den Abstand „1“ zur Landschaft hat. Die Position in der virtuellen Welt auf der X-Achse ist „VX“.
Sobald ich dieses Diagramm hatte, war die Berechnung des Ergebnisses eine simple Anwendung des Strahlensatzes. Diejenigen, die am Ergebnis interessiert sind, können einen Blick auf die Funktion C4Object::GetDrawPosition() in der Engine werfen.
Dieser Artikel ist für all diejenigen geschrieben, die Clonk Rage kennen und nun wissen möchten, was es in OpenClonk Neues gibt. Seit das Projekt Open Source ist, wurden einige experimentelle Features eingeführt. Im neuesten Teil der Clonk-Spieleserie haben wir alte Fesseln abgeworfen und etwas erschaffen, das weiter fortgeschritten ist als alles was ihr jemals in Clonk gesehen habt.
Man kann mit Sicherheit sagen, dass wir mit OpenClonk den größten Sprung machen, was neue Features und Änderungen seit Clonk 4 angeht.
Allgemein
Neu in OpenClonk ist die Möglichkeit zu Zoomen. Der Clonk kann jetzt in einer angemessenen Größe angezeigt werden, also größer als ein Mauszeiger ;-). Zoomen kann man mit dem Mausrad oder den Tasten F5/F6.
3D-Rendering
Auch neu ist, dass 3D-Modelle im Spiel dargestellt werden können. Im Gegensatz zu den klassischen Sprite-Grafiken sind 3D-Modelle wesentlich vielseitiger: Erstens, die Modelle verwaschen nicht und die Animationen sehen nicht abgehackt aus wenn hineingezoomt wird. Animationen werden direkt im Modell gespeichert. Man muss sie nicht mehr aus Einzelbildern der verschiedenen Animationsphasen zusammenpuzzlen (Tschüss, anigrab.exe). Das ermöglicht viel mehr Animationen als früher. Im Moment hat der Clonk mehr als 100 verschiedene!
Der Renderer lädt Modelle im Ogre3D-Format, einem leichtgewichtigen Format für 3D-Modelle, das speziell auf Echtzeit-Darstellung zugeschnitten ist. Modelle in der Landschaft werden orthogonal, Bilder von Objekten dagegen perspektivisch projiziert. Abgesehen vom Grundlegenden unterstützt der Renderer noch:
Texturen mit UV-Maps (einschließlich Multi-Texturing)
Transparente Texturen / Alpha-Maps
Texturanimation
Bones-Animation, einschließlich dem Mischen mehrerer Animationen gleichzeitig
Backface Culling
In Echtzeit Script-gesteuerte Mesh-Transformationen und Attachments
Siehe auch den Artists Guide dazu, wie man Modelle erstellt, die in Echtzeit gerendert werden sollen. Unser Ressourcen-Repository beinhaltet bereits viele solcher Modelle.
Neue Steuerung
Allerdings sind die meisten Änderungen, die wir gemacht haben und noch machen, nur deshalb möglich geworden, weil wir entschieden haben die Abwärtskompatibilität zu Clonk Rage über Bord zu werfen und alle Spielinhalte von Grund auf neu zu erstellen. Das ist auch der Grund, warum die Spielinhalte von OpenClonk noch weit davon entfernt sind, den Umfang derer von Clonk Rage zu erreichen.
Die Steuerung wurde komplett überarbeitet und wird jetzt komplett per Script bestimmt. Mit dem neuen Steuerungssystem ist es gleich viel einfacher und intuitiver seinen Clonk zu steuern. Für neue Spieler war die ungewöhnliche und unintuitive Steuerung schon immer eine große Hürde gewesen, bevor sie endlich in den Genuss des wuseligen Gameplays von Clonk kommen konnten.
Der Clonk gräbt in Richtung des Mauszeigers, solange die Maustaste gedrückt bleibt.
Die Steuerung ist jetzt vollständig anzupassen und kann in jedem Szenario/Mod verändert werden. Die Standard-Steuerung basiert auf dem allgemein bekannten Schema vieler anderer Spiele: Bewegen mit WASD, werfen, zielen und Werkzeuge benutzen mit der Maus. Leertaste, um Objekte in der Landschaft zu benutzen (wie etwa ein Gebäude betreten oder ein Fahrzeug anpacken). Die neue Steuerung schöpft die Maus vollständig aus, und gibt euch damit präzise Kontrolle über alle Gegenstände und Waffen. Die neue Schaufel zum Beispiel kann auch beim Klettern und Hangeln benutzt werden, und der Clonk gräbt einfach genau in Richtung Mauszeiger, solang der Mausknopf gedrückt gehalten wird. Weitere Details zur neuen Steuerung werden in den ersten Tutorial-Missionen im Spiel erläutert.
Abgesehen von der Steuerung mit Maus+Tastatur kann man auch ein Gamepad benutzen. Allerdings ist dieses Feature noch experimentell, und so funktioniert im Moment von mehreren angeschlossenen Gamepads immer nur eins. Es ist ebenfalls noch nicht möglich, dessen Belegung zu ändern, aber das ist für die Zukunft geplant. Eine frühe Version der Gamepad-Steuerung wurde in einem Blog-Post vorgestellt.
Umfassende Dokumentation zur anpassbaren Spielsteuerung findet ihr in der C4Script-Dokumentation.
Insgesamt ist der Clonk viel agiler als zuvor: Er kann nicht nur herumlaufen und Sachen im Sprung benutzen, darüber hinaus helfen ihm eine Menge Werkzeuge dabei, durch die Welt zu kraxeln – zum Beispiel Enterhaken, Strickleitern, die verbesserte Schaufel und viele weitere.
Werkzeuge und HUD
Eng im Zusammenhang mit der Steuerung steht das Inventar-System des Clonks. Jeder Clonk hat jetzt einen Rucksack, in dem er fünf Sachen (Kapazität änderbar durch die Szenarien) tragen kann. Er kann seinen Rucksack öffnen und leicht Objekte aus dem Rucksack und aus seinem Inventar hin- und hertauschen.
Stark im Mittelpunkt stehen die Werkzeuge in OpenClonk. Der Clonk braucht zum Graben eine Schaufel, zum Bäume Fällen eine Axt, und zum Bauen einen Hammer. Als Ausgleich kann der Clonk nicht nur mehr Dinge tragen als der klassische Clonk, er kann auch jeden Gegenstand benutzen: Schwert, Bogen, Schaufel, Muskete, Zauberstab, etc. Der Bedarf an spezialisierten Clonks ist Geschichte, denn die Fähigkeiten eines Clonks werden jetzt rein durch seine Ausrüstung bestimmt. Durch die Nutzung der Maus sind Werkzeuge vielseitiger und einfacher zu bedienen.
Spielerclonks, mit Rang, Energie und Atem. Wurzel trägt eine Schaufel, Carlo taucht.
Die neue Spielsteuerung geht auch Hand in Hand mit der gründlichen Überholung des HUD. Das minimalistische HUD war eine Sache, die wiederholt als Kritik an Clonk angebracht wurde.
Ab sofort wird das HUD vollständig per Script bestimmt (anstatt von der Engine), was mehr Flexibilität für Szenarien und Entwickler bedeutet. Die Standardoberfläche zeigt alle Clonks des Spielerteams am oberen Rand, jeweils mit einer Energie- und Atem-Leiste direkt unter ihrem Bild. Außerdem zeigt das Bild den Clonk live in Aktion, sprich, wenn er angegriffen wird oder gerade ertrinkt sieht man das dort.
Am unteren Bildschirmrand sieht man die zwei Gegenstände, die der Clonk in seinen Händen trägt.
Benutzbare Gegenstände: Inventar links (mit Zusatzinfo, z.B. Munition), eine Kiste beim Clonk rechts.
Sie können mit Links- oder Rechtsklick benutzt werden. Darüber hinaus werden dort auch alle Objekte in der Landschaft angezeigt, die der Clonk gerade benutzen kann.
Alle Knöpfe die man im HUD sieht kann man anklicken, um sie auszulösen oder auszuwählen, und Gegenstände kann man per Drag&Drop sinnvoll herumziehen. Dieses Feature ist interessant für Mod-Autoren.
Neue Spielinhalte und Konzepte
Da der gesamte Spielinhalt von Grund auf neu ist, muss man die vielen neuen oder erneuerten Werkzeuge, Waffen, Gegenstände, Gebäude, Fahrzeuge und Tiere, Regeln, Ziele und Umweltobjekte unbedingt erwähnen. Abgesehen von den Objekten ersetzen wir vollständig die alten Grafiken, Sound-Effekte und Texturen. Texturen zum Beispiel sind keine Graustufenbilder mehr, die nachher nach Farbe des Materials getönt werden, sondern Farbbilder mit mehr Variation. Dadurch sieht die Landschaft besser und detaillierter aus. Neue Sound-Effekte suchen wir uns bei den verschiedenen freien (Creative Commons) Archiven, oder wir machen sie selbst.
Die Frage sollte also eher lauten, was ist denn nicht neu?
Nun ja, was den Spielinhalt angeht, gar nichts. Allerdings haben wir nicht einfach nur alte Objekte neu entworfen. Ein paar ganz neue Konzepte sind bereits im Spielinhalt zu sehen. Beispielsweise wurde der nervige automatische Clonk-zu-Clonk-Kampf beseitigt und wird durch den Kampf mit diversen Nahkampfwaffen ersetzt. Die klassischen Flints, die sich eigentlich nur in ihrer Explosionsgröße unterschieden haben, werden jetzt durch spezialisiertere Bergbau-Werkzeuge und Waffen ersetzt, wie etwa der Dynamitkiste. Aber anstatt jetzt alle neuen oder erneuerten Objekte hier aufzulisten empfehle ich euch, spielt einfach eine Runde und seht selbst :-P.
Für Entwickler
Viele vorgenommene Änderungen sind für Scripter und Szenario-Entwickler interessant:
C4DT
Ein Tool für die Clonk-Entwicklung soll hier besonders hervorgehoben werden: C4DT, die Clonk-Entwickler-Werkzeuge für Eclipse. Eclipse ist eine erweiterbare open-source Entwicklungsumgebung, die eine Vielzahl an Programmier- und Scriptsprachen unterstützt. Ab sofort auch C4Script: Das C4DT-Plugin erlaubt es euch, neue Inhalte für Clonk mit der mächtigen Eclipse-IDE zu entwickeln. Und da C4DT nicht versucht, eine eigenständige IDE zu sein, übernimmt sie jede Menge Features von Eclipse, und erleichtert die Entwicklung dadurch enorm. Unter den Features sind:
Errors und Warnings werden direkt in Eclipse angezeigt
Syntax-Highlighting für C4Script, Landscape.txt und Konfig-Dateien wie DefCore.txt und Scenario.txt
Alle Referenzen auf gültige Identifier (Variablen, Funktionen) können wie Weblinks angeklickt werden, um zu ihren Deklarationen zu springen. Das funktioniert sogar mit den Platzhaltern für Einträge in den Stringtabellen.
Schnell zur Objektdefinition springen, einfach indem man den Namen oder die ID des Objektes eintippt
Kontextabhängige Hilfe und Hinweise zu Parametern und sonstigem Code beim Tippen(!) (siehe Bild unten)
Hilfreiche Auto-Vervollständigung und -Einrückung
Ein Überblick über das aktuell geöffnete Script
Ein eingebauter Parser zeigt Errors und Warnings im Script auf, sodass man dazu die Engine nicht starten muss(!)
Refactoring von Variablen und Funktionen
Ein echter Debug-Modus für die Engine: Debug-Szenarien im Eclipse-Debugger(!)
Die alte editor.exe aus Clonk Rage-Zeiten wurde entfernt. C4DT ist der eindeutige Nachfolger des alten Freundes aller C4Script-Entwickler. Und eigentlich ist es ein mehr als würdiger Nachfolger, denn die Clonk-Entwicklung könnte wirklich kaum fortgeschrittener sein als mit diesem Eclipse-Plugin.
Auto-Vervollständigung und kontextabhängige Hilfe, noch während man tippt
C4Script-Änderungen
Abgesehen davon wurden folgende große Änderungen an C4Script vorgenommen:
Die ID eines Objekts ist nicht mehr auf 4 Großbuchstaben beschränkt. Zum Beispiel geht jetzt CreateObject(Musket); statt CreateObject(MSKT);
Alle Funktionen, die mit Objektkontext arbeiten, wurden von ihrem Objektparameter befreit. Beispielsweise schreibt man jetzt clonk->GetX(); statt GetX(clonk);
Ein paar veraltete Funktionen sind weg oder ersetzt. So verhält sich jetzt etwa FindObject() wie FindObject2() aus Clonk Rage, FindObject2() gibt es nicht mehr.
Viele Funktionalitäten, wie das Klettern an Strickleitern, Seilphysik, Basisgebäude, Werkstatt oder Clonk-Steuerung wurden in einheitlichen Bibliotheks-Objekten thematisch zusammengefasst, und können jetzt von den konkreten Objekten genutzt werden. Das vereinfacht die Nutzung von Funktionalitäten anderer Objekte, ohne alles von ihnen erben zu müssen. Zum Beispiel haben alle Produktionsgebäude #include Library_Workshop in ihren Scripts stehen, um die Grundfunktionalitäten einer Werkstatt zu bekommen.
Ein neuer Datentyp, genannt „Proplist“. Proplisten sind assoziative Arrays mit Prototypvererbung, wie bei Javascript-Objekten. Ein Beispiel: var info = { XP = 1200, Comment = "I'm new here." }; Log("%d",info.XP); gibt „1200“ im Log aus. Objekte und Objektdefinitionen sind jetzt ebenfalls Proplisten und Objekte erben von ihrer Definition: Log("%s",Bow.Name); gibt sprachabhängig den übersetzten Namen des Bogens aus. Lokale benannte Variablen sind jetzt Properties eines Objekts.
ActMaps werden ebenfalls als Proplist in einer Property in der Objektdefinition gespeichert. Wahrscheinlich wird die DefCore.txt ihrem Beispiel folgen.
Die Dateien DescXX.txt und Names.txt werden nicht mehr genutzt. Der Name wird per Script gesetzt und je nach Sprache aus der entsprechenden StringTblXX.txt gelesen. Nur noch wenige Objekte benötigen eine Beschreibung, und diese wird ebenfalls im Script definiert und in der String-Tabelle übersetzt.
Die Steuerung wurde überarbeitet. Szenarien und Objekte können Tastatur, Maus und Gamepad beliebig nutzen und neu belegen. Das Script des Clonks definiert ein neues Interface (siehe ControlUse) für den Umgang mit Objekten.
Variablen können jetzt den Wert nil haben, egal von welchem Typ sie sind. nil ist wie null in anderen Programmiersprachen, und wird in C4Script üblicherweise benutzt um anzuzeigen, dass etwas nicht gesetzt ist. Ob eine Variable 0 oder nil ist, ist beispielsweise nicht dasselbe. Sie ist 0, wenn sie die Zahl 0 enthält und nil, wenn sie nicht gesetzt ist. Für Funktionen hingegen kann nil benutzt werden, um einen optionalen Parameter nicht festzulegen (das ist, als ob man ihn ausgelassen hätte). Zum Beispiel spielt Sound("Water",true,nil,nil,+1) den Wasser-Sound endlos für alle Spieler, mit 100% Lautstärke (dem Standard), während dieser Sound mit Sound("Water",true,nil,0,+1) nur für Spieler 0 zu hören ist. Außerdem erlaubt nil es, zwischen Funktionen zu unterscheiden die keinen Rückgabewert (also nil) liefern und z.B. solchen, die die Zahl 0 zurück geben.
Unabhängig davon, ob eine Variable foo entweder nil, 0 oder false ist, dieser Ausdruck gibt immer noch „yay“ aus: if(!foo) Log("yay");
#strict und #strict 2 wurden abgeschafft. #strict 2 gilt implizit für alle Scripts.
Wie üblich gibt es einige neue Funktionen und Engine-Callbacks. Siehe dazu die Dokumentation.
<Nachtschatten> Das ist ja wie Kraut und Rüben, wer soll da noch durchblicken? – Gedanken zur schieren Übermacht an Mods
Das Thema dieses Artikels sind Mods. Modifikationen von Szenarien sind zur Zeit sehr beliebt, wie man auch am CCAN-Screenshot weiter unten sehen kann. Ich werfe mal in den Raum: Nimmt das denn nicht Überhand? Fakt ist, Mods gab es schon immer. Da bekenne ich mich auch gerne selbst schuldig, ich habe früher meine eigenen Versionen von Divine Prophecy, Straßen von Clonkago und vielen weiteren Szenarien gehabt und gespielt. So eine Mod ergibt sich ja auch fast von selbst. Man mag ein bestimmtes Szenario sehr gern, und spielt es deshalb oft und ausgiebig. Dabei fällt einem hier ein kleiner Fehler auf, dort ist noch etwas verbesserungsfähig, das Balancing könnte noch einen Tick besser sein… es sind oft Kleinigkeiten.Und so eine Kleinigkeit ist auch schnell geändert. Eine kleine Ausbesserung, ein schneller Patch, und schon entspricht das Szenario genau deinen Vorstellungen… Und voller Freude erhöhst du die Versionsnummer, fügst noch deinen Nicknamen hinzu, und lädst das Ding auf’s CCAN.Aber die Frage ist: War das jetzt eine gute Sache ™? Im Extremfall geht die Geschichte des Szenarios folgenden Weg: Deine Version gefällt genug anderen, und jemand davon kommt auf die Idee, deine Mod wiederum zu verändern. Daraus entsteht seine eigene Version, die er ebenfalls veröffentlicht. Wenn wir das weiterspinnen, kommen wir irgendwann z.B. bei „Blackfield v3.2 EXTREME Twonky Edition Dr.Stupid Edit GREEN Style by Jens“ an. Außer, dass da sowieso keiner mehr durchblickt, fragt man sich: Bei diesen ganzen Mini-Änderungen, warum denkt jeder er hätte jetzt etwas vollbracht und möchte es der ganzen Welt zeigen? Eine andere Möglichkeit ist, dass verschiedene Spieler auf verschiedene Ideen zur Verbesserung kommen. Das ist dann so eine Situation, in der man auf dem Masterserver fünfundzwanzig Versionen von Battlefield sieht, jede mit ihren eigenen drei Änderungen, aber doch wieder mit allen möglichen Schwächen. Und jeden Tag sprießen neue nach. Wie soll man sich da eigentlich noch entscheiden, welcher Runde man beitreten soll? Wenn wir ehrlich sind, wäre es bei den meisten Mods im Umlauf wahrscheinlich sinnvoll gewesen, die Verbesserungen als Vorschlag an den ursprünglichen Autor zu senden. Warum? Nun ja, der Autor ist mit Sicherheit dankbar für konkrete Vorschläge. Gut, manche werden ihm aus diversen Gründen nicht gefallen. Aber bei den meisten wird er sagen „Oh, daran hab ich noch gar nicht gedacht“, und deinen Vorschlag einbauen.
Wie sieht die Situation jetzt aus? Viele Vorschläge sind gar nicht erst zu eigenständigen Mini-Mods geworden, also haben wir einige wenige Versionen des Szenarios. Die dürften sehr ausgereift sein, im Vergleich zu den Mini-Mods – immerhin steckt in ihnen so viel Arbeit, wie in allen Mini-Mods zusammen. Eine solche Version könnte man als „Best Of“ aller Mods ansehen. Und das Beste zum Schluss: Zu deinem Ruhm kommst du trotzdem! Der ursprüngliche Autor ist ja kein Unmensch, und nimmt dich sicher gerne in die Danksagungen auf, schließlich hast du dir das mit den guten Vorschlägen auch verdient. Jetzt kommt noch das große aber:Es kann trotzdem sinnvoll sein, an einer Mod zu arbeiten und sie zu veröffentlichen. Eine klare Grenze kann man hier nicht so recht ziehen. Aber hier ein paar typische Fälle: Es kann sein, dass du (vielleicht sogar mit einem Team) große Änderungen oder Erweiterungen vor hast. Dann ist es zwar noch so, dass man Gemeinsamkeiten zwischen Mod und Original erkennt, aber vieles ist anders. Hier kann man vermutlich nicht erwarten, dass der Autor alle (oder zumindest die meisten) Änderungen übernimmt, und es ist wohl gerechtfertigt, das als eigenständige Version anzusehen.Ein anderer Fall ist, wenn das Szenario seit längerer Zeit nicht gepflegt wurde. Vielleicht, weil der Originalautor es aufgegeben hat, oder weil er sich von Clonk zurückgezogen hat. Vielleicht ist er sogar gar nicht mehr erreichbar. Da kann man ruhigen Gewissens seine eigene, neue Version verbreiten.
Wir haben die Übersicht über unsere Nightly Builds vor Kurzem stark überarbeitet. Wir unterstützen nun Builds für verschiedene Architekturen und mit verschiedenen Compilern. Zusätzlich zu den Builds für Windows 32Bit gibt es sie nun auch für Windows 64Bit mit MinGW und MSVC (dank Isilkor). Die Farbe des Build-Status ist jetzt nicht mehr nur grün („Build funktioniert“) oder rot („funktioniert nicht“), sondern kann auch dazwischen liegen, je nach Anzahl der Warnungen, die beim Kompilieren ausgegeben werden. Vielleicht ist das ja ein Anreiz für die Entwickler, ihren Build für ihre Plattform so grün wie möglich zu machen? :D
Es war etwas Puzzle-Arbeit nötig, um die Cross-Compiler-Umgebung für 64Bit-MinGW aufzusetzen: Debians gcc-mingw32-Paket beinhaltet zwar einen C-Compiler für 64Bit, hat aber keinen für C++ (ein Debian-Bug). Also habe ich versucht, den MinGW-Compiler selbst zu bauen, ohne Erfolg. Als das nicht ging tat ich das, was der Autor des Bugs empfohlen hatte: Ich holte mir den Quellcode von gcc-mingw32 mit „apt-get“, aktivierte die Unterstützung für C++ in debian/rules, und kompilierte das ganze Paket neu. Das funktionierte sehr schön. Die meisten Abhängigkeiten von OpenClonk bieten 64Bit-Binaries an, weitere bekommt man über das GNOME-Projekt. Nur fmod und d3dx9 machten Probleme, weil dafür keine Libraries für 64Bit angeboten werden. Dennoch habe ich es geschafft die entsprechenden Import-Libraries aus den DLLs mit den MinGW-Tools „gendef“ und „dlltool“ zu erzeugen. Ich frage mich ja, warum Import-Libraries überhaupt benötigt werden, wo doch alle Informationen in der DLL sowieso enthalten sein sollten – ich dachte zumindest, dass die Import-Libraries für Informationen da sind, die eben nicht in den DLLs enthalten sind, und man sie deshalb für das Linking braucht.
Grobe Pläne für die Zukunft wären die Builds für andere Plattformen wie Linux (vielleicht sogar als .rpms und/oder .debs) und die Windows Entwicklungs-Snapshots als Installer anzubieten.
