CSNDR ist ein 2D-Adventure. Die Story steht bisher noch nicht fest, jedoch wird der Spielablauf vorraussichtlich recht linear ablaufen. Man steuert eine Spielfigur, welche diverse Aufgaben erledigen und evtl. auch Rätsel lösen muss. Das sind bis jetzt allerdings nur recht vage Vorstellungen von dem, was einmal möglich sein wird.

OpenSource-Software ist grundsätzlich nie fertig, was eher als positive Eigenschaft aufgefassen werden sollte. Momentan befindet sich CSNDR noch in einem sehr frühen Stadium. Wenn in ferner Zukunft einmal alle Mainfeatures eingebaut sind, kann man es evtl. als „halb-fertig“ bezeichnen. Dann wird der Fokus hauptsächlich auf dem Fixen von Bugs und dem Ausbau der Story liegen. Bis dahin ist es aber noch ein weiter, hoffentlich nicht unüberwindbarer Weg, bei dessen Beschreitung DU mithelfen kannst!

Möglicherweise. Möglicherweise aber auch nicht. Das hängt einerseits von der Art des Features ab, welches natürlich in das Konzept passen muss. Andererseits muss es implementierbar sein, und schließlich auch von jemanden implementiert werden. Die letzteren beiden Dinge sind wohl die Haupthindernisse.

Neue Ideen und Verbesserungsvorschläge sind natürlich immer erwünscht und können hier mitgeteilt werden.

Keine. Es gibt sehr wenig Software, bei denen Versionsnummern auch wirklich etwas über die Qualität/Stabilität aussagen. Meistens dienen sie lediglich zur Kennzeichnung bestimmter Releases, oder sagen überhaupt gar nichts aus. Genau das ist auch hier der Fall. Es gibt auch keine Unterscheidung zwischen Stable- und Development-Release. Sämtliche Releases sollten für den Endanwender ausreichend stabil sein. Ausnahmen bestätigen die Regel.

Einerseits Friedrich Wilhelm I. sowie Friedrich der Große durch Beihilfe zur Einführung der Schulpflicht, andererseits der Beschluss des Jugendarbeitsschutzgesetz und damit Eingrenzung der Kinderarbeit. Denn nur dadurch hat die heutige Generation an Kindern nahezu unendlich viel Zeit, sich mit den sinnlosesten und abartigsten Gedankengängen zu beschäftigen. Eben diese Gedankengänge haben zur Erschaffung der Charaktere und damit letztendlich auch zur Erstellung dieses Spiels geführt.

Grundsätzlich ist es jedem erlaubt, Beiträge zu leisten, solange man eine oder mehrere der unten aufgelisteten Fähigkeiten besitzt.

Das Erstellen von neuen oder überarbeiteten Texturen und Skins sollte ein leichtes sein, solange man ein paar Grundkenntnisse in der Grafikbearbeitung besitzt.

Neue Charaktere sind immer willkommen. Optimalerweise können sie auch gleich in die Story integriert und mit Dialogen versehen werden.

Neue Level sind ebenfalls erwünscht. Allerdings fehlt bisher noch eine Gesamtkarte, welche das Erstellen neuer Level derzeit leider verhindert.

Storyelemente werden gerne entgegengenommen, ebenso Verbesserungen und Anregungen.

Beiträge in Form von Code sind ebenfalls erwünscht, ob Realisierung geplanter Features, Bugfixes/Verbesserungen oder komplett neue Funktionen. Letzteres sollte jedoch vorher abgesprochen werden.

Ob Effekte, Musik oder Synchronisationen. Alles ist erwünscht und wird auch dringend benötigt. Gerade bei Dialogen kann die Vielfalt nicht groß genug sein. Und besondere Fähigkeiten braucht man dafür nicht.

Egal ob Code, Erstellung von Levels/Item/Charakteren oder anderen Dingen, Dokumentationen sind immer willkommen.

Wer keine der oben genannten Fähigkeiten besitzt und einfach nur ein paar Vorschläge hat, kann und soll diese hier äußern.

Auftretende Probleme, die nicht in dieser FAQ besprochen werden, können im Bereich Verbesserungen und Anregungen gemeldet werden.

Dies ist ein bekanntes Problem mit Version 0.3.5 und einem Großteil der Grafiktreiber. 0.3.5 war das erste Release mit OpenGL-Unterstützung, jedoch wurden die Texturen erst ab 0.3.6 auf eine Zweierpotenz skaliert, was Pflicht für OpenGL-Texturen ist. Die Charakter-Skins sind die einzigen Texturen mit einer „gültigen“ Größe. Interessanterweise führte das jedoch unter Linux und einem Testsystem mit Windows und einem uralten Detonatortreiber zu keinerlei Problemen.

Die Möglichkeit, unter Windows zwischen Fenster und Vollbild zu wechseln, existiert erst seit Version 0.3.7. Unter Windows wird bei einem Wechsel der Auflösung der momentate OpenGL-Status zerstört. Um ihn erneut zu initialisieren, müssten alle Texturen zusätzlich im RAM zwischengespeichert werden, um sie wieder in den Grafikspeicher laden zu können. Da das zusätzlichen Speicher benötigt und etwas Arbeit bei der Implementierung bereitet, ist diese Funktion unter Windows momentan nicht benutzbar.

Zum Starten der vorkompilierten Version entpackt man zu erst das Archiv. Unter KDE ist das mit Ark möglich, unter Gnome beispielsweise mit File-Roller. Unter der Kommandozeile führt man dazu tar xzf <Dateiname> aus. Anschließend wechselt man auf der Kommandozeile in das entsprechende Verzeichnis und führt ./bert aus.