Cerator's Allerlei

Die Hauptmechanik des Spiels soll das Sammeln und Verarbeiten von Ressourcen sein. Als Ressourcen hatten wir bald eine Liste zusammen und um diese abzubauen dachten wir an verschiedene Werkzeuge.

Die Werkzeuge

Eine Axt, um Bäume zu fällen, ein Hammer, um Ressourcen verarbeiten zu können und einige weitere waren schnell gefunden. Eine passende Datenstruktur war schon schwieriger zu finden.

Eine Überlegung war, die Werkzeuge als Struktur zu definieren und zusätzlich dem Spieler eine Tabelle mit den bereits gefundenen Werkzeugen mitzugeben, in das die neuen Werkzeuge nach und nach hinzugefügt werden, sobald der Spieler sie findet oder herstellt.

Das Problem dabei wäre gewesen, dass die Reihenfolge der Werkzeuge dynamisch gewesen wäre und außerdem wollten wir im Spiel eine komplette Leiste der Werkzeuge anzeigen, bei der noch nicht gefundene oder hergestellte Werkzeuge als versperrtes Vorhängeschloss dargestellt werden, um den Spieler auch ein wenig neugierig zu machen, was ihn noch erwartet. Also haben wir für jeden Werkzeugplatz einen Eintrag in der tools Unterstruktur der Spielerstruktur angelegt. Über die boolean Variable own wird festgehalten, ob das Werkzeug bereits im Besitz des Spielers ist und damit nicht mehr nur als Vorhängeschloss in der Werkzeugleiste angezeigt wird. Die zweite boolean Variable use markiert das gerade aktive Werkzeug, das in der Werkzeugleiste durch einen roten Rahmen hervorgehoben wird.

Welches Werkzeug erntet welche Ressource?

Für diese Zuordnung hab‘ ich mich der Flags bedient, die PICO-8 für jedes Sprite zur Verfügung stellt. Das sind die kleinen Kugeln unter der Spriteansicht im Sprite-Editor. Sind sie grau, ist das jeweilige Flag false, wenn sie allerdings bunt sind, ist das jeweilige Flag true. Diese Flags kann man entweder alle auf einmal über FGET(<spritenumber>) abfragen, oder einzelne Flags über FGET(<spritenumber>,<flag>). Also habe ich eine Liste von vier Eigenschaften erstellt, um die Fähigkeiten der Werkzeuge abzubilden:

Dazu kamen dann noch openable für Kisten und collectible für generell einsammelbare Ressourcen und Gegenstände wie Äpfel oder Pilze zum Beispiel, die unabhängig vom aktiven Werkzeug funktionieren sollen. Sowohl bei den Sprites der Werkzeuge als auch bei den Sprites der Ressourcen müssen die entsprechenden Flags gesetzt werden dann kann man mit einem binären Und (BAND) herausfinden, ob man eine Ressource mit dem aktiven Werkzeug ernten kann.

IF BAND(FGET(<sprite_tool>),FGET(<sprite_resource>)) > 0 THEN...

Im folgenden Bild sieht man die ausgewählte Axt und einen Baum mit dem gelben Flag aktiviert.

Wer sich jetzt über die Anordnung der Sprites wundert: Alle Ressourcen, Werkzeuge und UI-Elemente hab’ ich auf der ersten Sprite-Seite (Tab 0) untergebracht. Die zweite Seite (Tab 1) enthält dann eher Sprites für die Umgebung und die dynamisch generierte Map. (Hmmm... Eigentlich sollte die Kiste wohl auf Seite zwei wandern... :))

Inspiriert von Minecraft und ähnlichen Spielen hat mein Jüngster(8) eines Tages gemeint, “Wir entwickeln jetzt ein Spiel” und hat ganz wild angefangen verschiedene Elemente zu zeichnen.

Die erste Hürde war: Für welche Plattform mit welcher Spiele-Engine bzw. welcher Entwicklungsumgebung startet man am besten?

Ich hatte ja schon seit einiger Zeit (aus einem Humble Bundle) PICO-8, eine Fantasy-Konsole. Mit seiner Auflösung von 128x128, 16 Farben und 8x8 Sprites ist die optische Seite schonmal recht überschaubar und durch die integrierte Entwicklungsumgebung mit Code-, Sprite-, Map-, FX- und Musikeditor hat man alles recht einfach im Griff. Das integrierte Framework und die verwendete Programmiersprache Lua sind auch ein Pluspunkt, weil man sich auf die Spielelogik konzentrieren kann und nicht auch noch seine eigene Grafik-Engine programmieren muss. Trotz dieser Einschränkung kann man PICO-8 Spiele allerdings auch ganz einfach für Windows, Linux oder Mac kompilieren, oder aber als HTML5 und JS-Projekt auf der eigenen Webseite einbinden.

Der Held unseres Crafting-Abenteuers war recht schnell gepixelt und auch bald hüpfend animiert. Darf ich vorstellen Schleimi! 

Inspiriert durch einen Vortrag über das Zeichnen mit CSS, habe ich mich gleich mal an einem stilisierten Baum versucht:

See the Pen CSS Tree by Cerator (@Cerator) on CodePen.

Anfänglich habe ich angefangen, die Teile mittels Prozentwerten (%) zu definieren. Dann bin ich allerdings draufgekommen, dass das vielleicht keine so gute Idee ist, weil der vorgegebene Arbeitsbereich fast doppelt so breit wie hoch ist, und ich deswegen ein gleich breites Objekt zum Beispiel mit width: 10%; height: 20%; beschreiben musste.

Also alles umschreiben in Pixelwerte (px).

Danach war natürlich das Bild zu groß. Es füllte den ganzen Bildschirm, was sich beim Einbetten hier durch große Scrollbalken und wenig Inhalt ausgezeichnet hätte.

Nochmal alle Pixelwerte durchgehen und halbieren.

Dann war das Bild noch immer breiter als hoch, also ein letztes Mal die Werte bearbeiten, um ein quadratisches Bild draus zu machen.

Mein erster C64 Chiptune geschrieben mit SidWizard 1.7 im C64 Emulator WinVice.

Für ein aktuelles Demo-Projekt und auch für zukünftige Demos hab’ ich nach einer Möglichkeit gesucht, einen kompletten TrueType Font in einen C64 Charset zu konvertieren. Das einzige Tool, mit dem man TrueType Fonts in ein C64 Charset konvertieren kann, ist Charset Minion, mit dem man allerdings jeden Buchstaben einzeln umwandeln muss. Um einen ganzen Font auf einen Rutsch zu konvertieren, musste ich anders vorgehen.

Ein Font, den ich verwenden wollte, war schnell gefunden:

Codehead’s Bitmap Font Generator

Als erstes habe ich diesen Truetype Font mit Codehead’s Bitmap Font Generator in eine Bitmap rendern lassen:

Leider kann man in diesem Tool den zu rendernden Text nicht einstellen und man muss mit dem gesamten Alphabet inklusive diverser Sonderzeichen vorlieb nehmen und sich den Zeichensatz nachher in einem anderen Tool in der gewünschten Reihenfolge zusammensetzen.

Deswegen habe ich die Breite des Bildes so breit eingestellt, dass alle Buchstaben und Zeichen, die ich übernehmen wollte, in der ersten Zeile stehen.

Auch wenn ich im finalen Charset nur 8x8 Pixel pro Zeichen habe, habe ich im ersten Schritt die Zellenhöhe mit 14 großzügiger eingestellt, um genug Spielraum für Großbuchstaben und Unterlängen zu haben. Für die Fontgröße hab ich 13 gewählt, sodass noch (fast) alles in die Zellenhöhe passt.

Photoshop

Die resultierende Bitmap-Datei habe ich dann in den Photoshop (Elements) im Bitmap-Modus geladen. Um ein Gefühl für die Zeichengröße zu bekommen, hab’ ich mir ein Raster anzeigen lassen.

Da die Reihenfolge der Zeichen beim Bitmap rendern leider nicht beinflussbar war, musste ich das erstmal in Photoshop richtig stellen.

Ich wollte für mein Demo ein Charset mit Groß- und Kleinbuchstaben erstellen. Daher musste ich erstmal eine Liste der Zeichen als Referenz herausfinden:

@abcdefghijklmnopqrstuvwxyz[£]↑← !"#$%&'()*+,-./0123456789:;<=>?ABCDEFGHIJKLMNOPQRSTUVWXYZ

Und dann fing das fröhliche Pixeln an! :-)

Da in Summe in der Höhe nur 8 Pixel für ein 1x1 Charset zur Verfügung stehen, dieser Zeichensatz aber auch nur für eine einzelne Zeile verwendet wird, hab’ ich die ganzen 8 Pixel für Großbuchstaben, Zahlen und die hohen Kleinbuchstaben genutzt. Die Unterlängen der Kleinbuchstaben habe ich einfach nach oben geschoben und ein wenig zusammengestaucht.

Und so ungefähr sieht das dann aus:

Das Ganze musste ich dann nur noch als Bitmap-Datei speichern und schon geht es zum nächsten Tool.

Pixcen

Es gibt zwar mehrere Tools, mit denen man Bitmaps in Charsets umwandeln kann, doch das beste Gefühl hatte ich bei Pixcen.

Beim Importieren muss man nur den entsprechenden Modus wählen. In meinem Fall “Single color Char”:

Und das dann als “Indexed char map” speichern:

Und schon hat man ein neues Charset, dass man dann in seinem Projekt importieren kann.

Und so sieht das dann im Demo im WinVICE aus:

Wie alles begann...

Angefangen hat wohl alles mit den Crackern. Also mit den Leuten, die den Kopierschutz von Software-Titeln entfernt haben, sodass man sie problemlos kopieren konnte. Damit auch jeder wusste, welcher Gruppe er seine kopierte Software verdankte, haben die Cracker angefangen einfache Intros vor die eigentlichen Programme zu hängen. Da war dann der Name der Cracker-Gruppe zu lesen, ein paar bunte Effekte zu sehen und eine Laufschrift, die mehr oder weniger sinnvollen Text zeigte und eventuell auch Grüße an andere Gruppen beinhaltete.

Die dabei gezeigten Effekte und Tricks wurden immer komplizierter, aufwändiger und unabhängiger von der eigentlich gecrackten Software, sodass sich parallel zu den Intros die Demos entwickelten. Demos waren eigenständige Programme, deren Ziele es waren

das Können der beteiligten Personen unter Beweis zu stellen und

mit allen möglichen Tricks das letzte aus der verwendeten Plattform herauszuholen

Gerade beim C64 wurden über die Zeit immer neue, un- (oder schlecht) dokumentierte Besonderheiten der eingebauten Chips (der Grafik-Chip VIC und der Sound-Chip SID) entdeckt und für verschiedenste Tricks verwendet.

Begriffsverwirrung

Im Laufe der Zeit wurden zur Unterscheidung weitere Begriffe wie Cracktro (Intro zu einer gecrackten Software), Dentro (Mittelding zwischen Intro und Demo) oder Trackmo (mehrteilige Demo, die ohne User-Interaktion abläuft) erfunden, die eher in der Amiga oder PC-Demoszene entstanden sind.

Auch wurde bei großen Demos (meistens Trackmos ;-) immer mehr Wert auf Konsistenz im Design und im Flow gelegt, wodurch die Demoszene und deren Input immer mehr in den künstlerischen Bereich vordrang.

Woraus besteht so eine Demo?

Die kleineren Demos hatten meistens ein Logo (das sich gerne auch mal von einer Seite zur anderen schwingt), einen Scrolltext (der gern vertikal in Sinus-Form schwingt), ein oder mehrere bunte Rasterbalken (die auch gerne reglemäßig die Farben ändern), Sprites (die sich in ebenfalls einer Sinus-Form bewegen) und natürlich passende Musik (die dem SID das Letzte abverlangt).

Ein Teil des Scrolltextes waren oft auch die Greetings oder Credits, in der andere Gruppen oder Personen gegrüßt wurden.

Bei größeren Demos wurde wie schon geschrieben das Gesamtkonzept und das Design immer wichtiger. Außerdem wurden neuen oder verbesserten Effekten oder Tricks gerne eigene Teile der Demo gewidmet.

Parties, Compos und Achievements

Ein wichtiger Treffpunkt der Demoszene sind die Demo-Parties. Dort werden meistens Wettbewerbe (Compos) abgehalten in unterschiedlichen Kategorien (Demo, Intro, Grafik, Musik, ...). Noch immer finden C64 Demo-Parties statt. 2014 gab es zumindest 3 größere Parties mit einer Menge an qualitativ hochwertigen Demos (Datastorm 2014, Revision 2014 und X'2014)

Ein weiterer Nebenschauplatz der Demoszene sind die Achievements. Wer hat welchen Effekt wann zum ersten Mal oder am besten verwendet. Ein Beispiel dafür ist das Sprite-Multiplexing (also das Verwenden von mehr als den 8 gleichzeitig möglichen Hardware-Sprites). Da geht's einerseits darum, wer die meisten Sprites gleichzeitig am Bildschirm darstellen kann und zusätzlich ist auch noch der vertikale Abstand zwischen den gleichen Sprites in unterschiedlicher Form ein Thema. (Umso geringer der Abstand zwischen den gleichen Sprites ist, desto genauer muss das Timing des Multiplexers sein.)

Demo-Maker

In den späten 80ern sind dann auch diverse Intro- und Demo-Maker veröffentlicht worden, mit denen man auch als Laie selbst ein Intro oder eine Demo erstellen konnte. Man konnte ein eigenes Bild, einen eigenen Zeichensatz und eine eigene Musik laden, Effekte auswählen und schon war die eigene Demo fertig.

Mit so einer Demo macht man sich in der Demoszene natürlich keinen guten Namen! ;-)

Wie ja schon in früheren Einträgen geschrieben, hab' ich mich ja immer mal wieder mit z.B. dem Erzeugen von Fake-C64-Grafiken oder dem Erstellen von Chiptunes beschäftigt.

Als ich eines Tages einem Kollegen eine Fake-Demo-Animation zeigte, fragte mich der, ob das am C64 erstellt sei. Das war der Auslöser für ein neues Projekt: Meine erste richtige C64 Demo! 

Lange hab’ ich auf den Moment gewartet! Mein zweites größeres Text-Adventure “Wasser-Hasser” wurde heute gemeinsam mit einem zweiten Spiel “Die Geschichte des Herrn P.” von Hannes Schüller im brandneuen Textpäckchen veröffentlicht!

Das Spiel “Wasser-Hasser” war anfänglich nur als Test gedacht, ob es möglich ist, Interactive Fiction komplett gereimt zu schreiben. Doch gewöhnte ich mich schneller an das Reimen, als ich dachte und so war es eine recht kurzweilige Entwicklungszeit.

Will man es dem Spieler in einem in Inform6 geschriebenen Interactive Fiction Stück ermöglichen, auch einfach nur an der aktuellen Stelle zu graben, muss man da ein wenig nachhelfen. Die Deform-Bibliothek sieht die Eingabe des Verbs ‘grab’, das zur Aktion Dig führt nur mit einem Noun im Dativ vor, was bei dem Befehl ‘grab’ die Nachfrage: “Worin willst du graben?” erzeugt.

Hannes aus dem IF-Forum hatte hier einen guten Vorschlag:

Man erweitert die Verb-Definition um die Version ohne Noun und leitet dies auf eine eigene Aktion (in seinem Beispiel DigHere).

Man definiert die zur Aktion gehörige Unterfunktion (DigHereSub) und behandelt die Eingabe so, wie man möchte.

Und hier der Beispiel-Code:

Extend ‘grab’ last * -> DigHere;

Von meiner Faulheit und dem Streben nach hoher Qualität angetrieben, hab' ich mich jetzt auch privat mit der Testautomatisierung für mein aktuelles Interactive Fiction Projekt auseinandergesetzt.

Mit meinem neuen Text-Editor (Sublime Text 2) habe ich begonnen, auch den Compiler über eine Batch-Datei per Hotkey anzustoßen, warum da nicht auch gleich Regressionstests anhängen, um sicherzustellen, dass neue Änderungen keine existierende Funktionalität zerstört haben?

Da Interactive Fiction ja "nur" aus Text besteht, waren die ersten Schritte für so einen Regressionstest schnell klar:

Finde einen IF-Interpreter, den man mit einer Kommandodatei beschicken kann und der eine Transkriptdatei ausspuckt.

Vergleiche das neue Transkript mit einem vorher angelegten Referenztranskript.

Bei meiner Interpretersuche war Google leider nicht allzu hilfreich, Erst Nachfragen im if-de Forum und anschließend im intfiction.org Forum haben mich auf bocfel gestoßen. (Und Gott sei Dank hatte ein Forums-User einen Link zu einer für Windows 7 kompilierten Version http://roody.gerynarsabode.org/intfiction/bocfel.exe, den Code zum selber compilieren gibt's auf https://code.google.com/p/bocfel/)

Aufrufen lässt sich der Interpreter mit der Befehlszeile

bocfel -r -R <playback file> -t -T <script file name> <game file>

Ich dachte, das Schwierigste wäre damit getan, doch ich hatte nicht mit Windows gerechnet...

Das Vergleichen zweier Textdateien ist zwar prinzipiell (per Kommandozeile) mit dem Kommando fc möglich, doch war der Output nicht so recht nach meinem Geschmack.

DiffUtils für Windows 32 waren auch schnell gefunden, doch hab' ich die 32-Bit Version leider nicht auf meinem 64-Bit Windows 7 zum Laufen gebracht. Die GNU utilities for Win32 (UnxUtils) machten allerdings keine Probleme. 

Den Vergleich hab' ich dann mittels

diff <script file name> <reference file name>

zusammengebracht. Da sind allerdings für mich noch ein paar unnötige Informationen drinnen. Interessant sind nur die Zeilen der Änderungen, also die Zeilen die nur in der Referenz drinnen sind (>) und die Zeilen, die nur in der neuen Transkriptdatei drinnen sind (<). Also die Zeile mit egrep erweitert:

diff <script file name> <reference file name> | egrep "<|>"

Das wäre jetzt auch schon alles wunderbar, wären da nicht die Umlaute in meinem Code... bocfel und diff kodieren den Output auf Windows in Latin-1 allerdings erwartet sich mein Sublime Build-Fenster den Text per default in UTF-8. Also musste ich meine Inform.sublime-build Datei um folgende Zeile erweitern

"encoding": "latin-1"

und schon funktionierte alles perfekt.

Das war der erste Schritt doch das erlaubt nur einen 1:1 Vergleich zwischen den Ausgaben, was sich am ehesten für den Minimal-Lösungsweg anbietet, da sich andere Texte öfter mal beim Programmieren (absichtlich) ändern können. Steht der Großteil des Textes einmal fest, kann man sich mit dieser Methode natürlich auch gegen unbeabsichtigtes Ändern der Texte absichern.