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.
Vor einiger Zeit hat sich Newton darangesetzt und ein fortgeschrittenes Konzept der Hauptseite von OC gestaltet.
Aus diesem Design lässt sich eine Menge entnehmen. Angefangen bei dem Aussehen, sieht man langsam, wohin denn OC vom Stil her steuern möchte: Handfest, holzig, robust…eben clonkig! Es scheint sich auch langsam ein Logostil zu etablieren, der sich auch eindeutig mit den Vorgänger-Logos anfreunden möchte. Aber vor allem möchte das Redesign eines erreichen: Ein freundliches, übersichtliches auftreten. Clonkige Items als Symbole, kleine Javascript Galerien zum durchklicken, was meiner Meinung nach mit am wichtigsten ist: Ein schnell auffindbarer Download Button und eine kleine Newsspalte. 100 Punkte im Web-Fengshui ;) Denn seien wir ehrlich, vom viel verwirrenden Developerfachgeplänkel mit Mercurial Übersicht – Seiten hat der Otto-normal-Clonker nicht viel, außer die Möglichkeit frustriert den Tab wieder zu schließen.
Ihr merkt, das soll sich alles ändern. Und ich persönlich finde das auch sehr gut. OC möchte offener für alle werden. Da fehlt im Redesign fast nur noch eine Sprachauswahl mit deutschem Inhalt und dann wären wohl alle glücklich. Mir persönlich fehlt nur noch ein Favicon, sowie ein etwas breiteres Layout. 16:10er haben da ziemlich viel Freiräume links und rechts. Das alles kommt aber sicherlich noch, ich bleib optimistisch :)
Bisher waren die Sources der Entwicklermodus-Dokumentation nur auf Deutsch verfügbar. Die Doku basierte auf der von Clonk Rage, die ebenfalls für einige Zeit nur in Deutsch verfügbar war und erst später in’s Englische übersetzt wurde. Wie auch immer, bevor etwas übersetzt werden konnte, musste ja erst einmal eine deutsche Version verfügbar sein (siehe Bug #287) – daher konnte bisher auch keiner der englisch-sprachigen User etwas zur Doku beitragen. Nach einiger anfänglicher Arbeit von Maikel setzte ich mir letztes Wochenende zum Ziel die Situation zu ändern: Die Hauptdokumentation sollte auf Englisch vorhanden sein, welche dann möglicherweise in Deutsch (oder andere Sprachen) übersetzt werden kann. Dazu wäre das Tool xml2po, das alle XML-Dateien in docs/sdk scannt und danach daraus sogenannte po-Dateien erzeugt, die alle entsprechenden Strings zum Übersetzen enthalten, am Besten geeignet. Die po-Dateien werden dann von Menschen aus Fleisch und Blut übersetzt.
Die folgenden Schritte müssen dafür unternommen werden (Plus/Minus etwas Detailarbeit):
Die Englische Übersetzung vervollständigen: Als ich anfing, waren an die 200 unübersetzte deutsche Strings in der Doku, die ich mir vornehmen musste. gtranslator ist ein nettes Tool, das bei der Übersetzung hilft, bis auf eine Tatsache: Es zeigt nicht an, wo der String herkommt (z.B. welche Zeile aus welcher XML-Datei) – das musste ich von Hand in der po-Datei nachsehen, wenn ich das wissen musste.
Ein Script schreiben, das die po-Datei der englischen Übersetzung liest, den deutschen Inhalt aller XML-Dateien mit ihrer englischen Version ersetzt, und eine po-Datei mit der Übersetzung von Englisch zu Deutsch anlegt. Dieses Script fing als sehr hübsches und klares Python-Script an, aber dann musste es immer mehr Spezialfälle behandeln. Inzwischen kann ich nicht mehr sagen, dass ich besonders stolz darauf bin… aber naja, schlussendlich erfüllte es seinen Zweck. Eine weiter Sache, die ich währenddessen gelernt habe: Es ist eine gute Idee, Python-Strings und Unicode-Objekte möglichst nicht durcheinander zu benutzen; stattdessen sollte man lieber immer entweder das eine, oder das andere benutzen – andernfalls bekommt man seltsame „UnicodeDecodeError“-Exceptions und was nicht alles überall verstreut… ein Grund, warum ich Programmiersprachen mit starker Typisierung lieber mag.
Duplikate in der neu erstellten de.po-Datei loswerden. Es gab doch einige Fälle, wo zwei verschiedene deutsche Strings mit dem gleichen englischen String übersetzt werden. Das sieht man besonders oft in Tabellen, die (Englische) Bezeichner auflisten – die sollten gar nicht übersetzt werden, denn sie beziehen sich auf einen Eintrag in einer Konfigurations-Datei. Ich habe beschlossen, sie mit einem anderen XML-Tag zu markieren (<literal_col> statt <col>), sodass sie in der Übersetzung gar nicht erst auftauchen.
Einige der Strings, die noch zu übersetzen sind, enthalten XML-Fragmente, zum Beispiel um Platzhalter oder Text-Highlighting einzufügen. Nicht wenige dieser XMLs in der englischen Dokumentation sind kaputt. Ich frage mich, warum das Problem nicht gleich erkennbar war, als die Dokumentation am entstehen war.
Nun, wenn du die Dokumentation nach Deutsch, oder eine andere Sprache übersetzen möchtest, brauchst du lediglich die docs/de.po Dateien mit einem Tool deiner Wahl (zum Beispiel ein simpler Texteditor – das Format der Datei ist wunderhübsch selbsterklärend) bearbeiten. Auf Linux kannst du die .po-Dateien recht leicht neu generieren (mittels Scan der XML-Dateien für neue Strings) und eine übersetzte Version mittels make in docs/(für Windows ist das alles etwas komplizierter, aber bei Bedarf kannst du in die Anleitung schauen: README.cygwin.txt) erzeugen. Dabei werden ebenfalls die XML-Dateien zu HTML konvertiert – ideal um in Webbrowsern (Firefox kann zum Beispiel aus irgendeinem Grund nichts mit XMLs anfangen) angezeigt zu werden. Wenn du von Grund auf eine Übersetzung in eine neue Sprache anfangen möchtest (oder du möchtest sie in den make Prozess mit einbinden, weißt aber nicht wie) fühl dich frei einer der Entwickler im Forum oder Chat anzuschreiben. Ein Wort zur Warnung: Alle Docs zu übersetzen ist eine unglaublich große Arbeit, da diese mehr als 4000 Strings enthalten. Wie auch immer, es wäre schon eine feine Sache wenn alles Stück für Stück in kleineren Portionen übersetzt wird. Unübersetzte Strings bleiben vorerst auf Englisch.
Abgesehen von dieser hier gibt es noch mehr Arbeiten, die die Dokumentation betreffen. Newton hat uns darüber bereits einen netten Überblick im Forum gegeben. So, meine englisch-sprachigen Freunde, jetzt habt ihr keine Entschuldigung mehr :D . Außerdem enthält der Code noch einige Strings oder Kommentare, die auf Deutsch geschrieben sind. Später irgendwann können diese auch übersetzt werden, aber die Kommentare sollten auch ganz gut unübersetzt verständlich sein. Wenn ihr die Dokumentation-XMLs übersetzt, könnt ihr euch sogar ein direkte Vorschau eurer Änderungen im Internet Explorer (nicht im Firefox) anschauen.
Ungefähr Anfang Juli haben ich und Clonk-Karl es geschafft uns persönlich in meinem Heimatland zu treffen: Kanada. Da ich zur Zeit der einzige Entwickler bin, der auf in der westlichen Hemisphäre lebt, war es eine sehr tolle Sache, dass wir uns getroffen haben. Wie das Leben so spielt war zufälligerweise sein Zielort gar nicht weit von meiner Heimatstadt enfernt.
Während seines Aufenthaltes spielten wir ein paar Runden OpenClonk (and fanden dutzende Bugs), ein paar ClonkRage (bei welchen ich in Meleerunden armselig verlor :] ) . Außerdem bestiegen wir beide und ein Freund, Andrew (mehrere sind besser gegen allerlei Getier!), einen unserer berühmten britisch-kolumbischen Berge. Das war echt ein klasse Abenteuer … als wir noch nicht einmal am Berg waren stieg ich beinahe auf eine Schlange. Nachdem wir einen ziemlich steilen Pfad entlangwanderten, wurden wir von einem schwarzen Bären beobachtet, der allerdings die Höflichkeit hatte sich bei unserem Anblick aus dem Staub zu machen – was wir für eine gute Idee befanden.
links Andrew, rechts Clonk-Karl und mein sonderbares Ich in der Mitte
Und möglicherweise das meist-besprochene Thema bei dem Meeting: Doppelkeks. Nun, nur von uns Kanadiern. Diese kleinen Kekse schmecken verdammt gut und die gibt’s hier in Kanada nicht zu kaufen:´(
Ursprünglicher Post von Ringwaul am 18. Juli 2010.
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.
Einge OpenClonk Entwickler und Spieler haben sich letzte Woche in Offenburg, Deutschland getroffen, um die Zukunft des Projektes zu besprechen und um etwas Spaß miteinander zu haben. Die Teilnehmer waren: Tobias “Newton” Zwick, David “Zapper” Dormagen, Ruth “Clonkine” Fiedler, Martin “Mortimer” Plicht, Maikel “Maikel” de Vries, Benjamin “Loriel” Herr, seine Freundin Irina “Sul” Kadyrova, Günther “Guenther” Brammer, Sven “(der berühmte) Sven2″ Eberhardt and Armin “Clonk-Karl” Burgmeier. Ruths kleine Schwester Judith „tschudi“ Fiedler kam ebenfalls noch in den Abendstunden nach Feierabend dazu. Newton hat die meisten Besprechungen und Entscheidungen in das Forum zusammengefasst (Link tot?). Dazu Link: 1, 2 und 3. Zunächst wollten wir ein Release im Meeting erreichen, aber das haben wir nicht geschafft. Es gibt immer noch Pläne um bald wieder eines zu machen. Es braucht noch einiges an Brimborium (zum Beispiel ein Logo, mit dem jeder Leben kann, sowie Menügrafiken und ein Tutorial).
Wir sind aber recht produktiv, wie ihr an der Anzahl der Commits und Bugfixes sehen könnt. Abgesehen von OpenClonk haben wir noch andere Spiele (Video-, Brett und Kartenspiele), wie Clonk Rage gespielt. Wir haben da einige Top Scores in der Siedelliga geschafft. Auch haben wir einen Ausflug in den Schwarzwald gemacht. (es ist toll, wenn es warm genug ist um nur ein T-Shirt zu tragen, aber hier liegt noch immer Schnee herum). Zudem haben wir uns Freiburg im Breisgau angeschaut. Ein anderes mal haben wir einen Kletterpark besucht, um etwas Spaß in mehreren Metern Höhe zu haben. Ich meinerseits habe jetzt viel mehr Respekt vor hangelnden und kletternden Clonks :D .
Von oben links nach unten rechts: Loriel, Sven2, Clonk-Karl, Zapper, Untere Reihe: Newton, Irina, Maikel, Günther, Clonkine, Mortimer.
Ursprünglicher Post von Clonk-Karl am 31. März 2010.
Ich sehnte mich seit Wochen regelrecht etwas über die Gamepadsteuerung zu schreiben, aber ich habe ständig neue Features hinzugefügt, um die Steuerung zu verbessern (was allerdings einige Bugs zur Folge hatte). Jetzt funktioniert die Steuerung so wie sie sollte. Hier ist die Tastenbelegung.
Steuerkreuz („D-Pad“) und Analogstick: Bewegen, Zielen und sich im Menü bewegen
Die Steuerung ist noch nicht entgültig, aber zur Zeit die beste Lösung einen Clonk zu steuern.
Wenn du ein Gamepad hast, probier es doch bitte aus! Gehe zur Spielerauswahl –> [Dein Spieler]] –> Einstellungen –> Steuerung – und wähle, wenn du ein 8-Tasten Gamepad ohne Analogstick hast, das Kontrollschema „GamepadSNES“, oder wenn du so ein Gamepad wie auf dem Bild oben hast, dann wähle „GamepadDualshock“ aus.
Natürlich ist OpenClonk eher dafür gedacht mit Tastatur und Maus zu spielen. Aber Gamepad-Spieler werden niemals so effektiv und schnell sich bewegen und zielen können, wie Maus-Spieler (jemals GTA3 auf einer Konsole gespielt?, hoho!) – und das ist auch nicht unser Ziel. Unser Ziel ist es, das klassische Splitscreen-Feature zu erhalten (ja, du kannst Clonk im Splitscreen-Modus spielen :D), falls eure Freunde mal vorbeikommen. Wir wollen nicht die Standard-Maussteuerung mit den limitierten Möglichkeites des Gamepads kaputtmachen, nur um auf gleichen Niveau zu sein. Damit will ich nicht sagen, dass ich nicht alles versuchen werde die Gamepad-Steuerung so komfortabel wie möglich zu machen.
Der größte Unterschied zur Maussteuerung ist natürlich das Zielen. Mit dem Gamepad kannst du nicht einfach irgendwohin klicken, daher hier eine Erklärung, wie es funktioniert: Wenn du die Taste für Benutzen/Werfen gedrückt hältst, stoppt der Clonk und ein Cursor erscheint, mit dem du die Richtung in die der Clonk zielen soll steuern kannst. Der Cursor wandert kreisförmig um den Clonk. Du kannst ihn mit dem D-Pad oder dem Analogstick steuern. Mit dem D-Pad bist du aber, wie beim Stick, nicht auf nur acht Richtungen limitiert. Du kannst in jede Richtung zielen. Mit dem Analogstick ist es natürlich schneller und präziser. Wenn du die Taste loslässt, schießt/wirft der Clonk in die festgelegte Richtung.
Es gibt einige Werkzeuge, die benutzt werden, sobald der benutzen-Button gedrückt wird – wie zum Beispiel die Schaufel. Wie auch immer, wenn du die entsprechende Taste wieder drückst, ist der Cursor automatisch wieder in der Richtung wie vorher, egal ob D-Pad oder der Analogstick benutzt wird. Das ist eine sehr große Hilfe, um noch schneller zu zielen.
Nun, Gamepads für PCs sind eine große Schweinerei, es gibt keinen Standard in welcher Reihenfolge die Tasten nummeriert sind und auch keinen Standard welche Steuerungen für das D-Pad und den Analogstick gelten. Ich habe nur zwei Gamepads zum Testen, daher wäre es großartig wenn ich ein bisschen Feedback von euch dazu hören würde. :)
Wir präsentieren ein neues Szenario für OpenClonk. In „Die Hüter der Windräder“ müsst ihr die Windräder vor den bösen Windrad-essenden-Raketen, die auf euere kleine Himmelsinsel von überall her zusteuern, beschützen.
Es ist ein recht simples, kooperatives Überlebens-Schieß-alles-ab Szenario, um den Bogen und die Muskete zu testen. Die beiden Waffen haben einige echt coole Soundeffekte von Checkmatey, einen Modder des Spiels Mound&Blade, bekommen. In diesem Szenario gibts unendlich Munition, also: Macht den Raketen die Hölle heiß!
Die Screenshots zeigen ein Spiel im Netzwerk mit fünf Spielern.
Möglicherweise habt ihr gesehen, dass die Crew Icons oben links die selben Animationen ausführen, wie die, die der Clonk gerade ausführt. Habt ihr schon einmal probiert mit dem Speer so zu zielen, dass der Crew-Icon-Clonk ihn genau auf euch zu wirft? Das passiert dann so schnell, dass du es fast nicht sehen kannst, aber hier ein Schnappschuss davon :D
Wer weiß schon, welche anderen Wunder das Perspektive-Rendering noch für Clonk auf Lager hat?
Ursprünglicher Post von Newton am 25. Februar 2010
