Storyworld II

(0 Kommentare.)

Ich habe erfolgreich prokrastiniert und dabei eine App in den Google Play Store gestellt. Und zwar ein altes Programmierprojekt, Storyworld, bei dem ich mir schon länger gedacht habe, dass sich das doch leicht fürs Smartphone umschreiben lassen müsste.

Das Projekt

Im Blogeintrag oben und einigen anderen wird das Projekt vorgestellt. Der Kerngedanke: Es gibt eine Spielwelt mit Orten, zwischen denen man sich bewegen kann, und an den Orten kann es Geschichten geben. Diese Geschichten können nachträglich modular in die Welt eingefügt werden. Aufgabe einer Klasse wäre es, diese Geschichten zu schreiben und zu implementieren, und dann kann ich sie zu dem Gesamtprojekt hinzufügen.

Vorbereiten des alten Projekts

Ich habe das alte BlueJ-Projekt genommen und erst einmal – neben kleineren Bugfixes – sauber aufgeteilt in ein Projekt mit der eigentlichen Engine und einigen Beispielklassen, das ich als .jar-Archiv exportiert habe. Alle bisherigen Lösungen aus dem Unterricht kamen in ein zweites BlueJ-Projekt, das dieses Archiv als Library importiert hatte.

Dieselbe .jar-Library ist auch die Grundlage für ein Android-Studio-Projekt, da habe ich dann nur einen neuen View für die bestehenden Controller- und Model-Elemente in der Library schreiben müssen, und den nach und nach erweitert. Das ging überraschend leicht und schnell, bis eben auf die vielen zusätzlichen Ideen.

Jetzt sieht das so aus

Das Spiel selber, sofern man es als solches bezeichnen kann, gibt es hier bei Google Play.

Beispielklasse für Schüler und Schülerinnen

So sieht ein Minimalbeispiel aus:

package com.herrrau.storyworld.examplesStories;
import storyworld.mvc.model.*;

public class Beispiel extends SingleLocationStory {

    @Override public String getName() {
        return "Eine kurze Geschichte";
    }

    @Override public String startStoryAt() {
        return "Hafen";
    }

    @Override public Report createReport() {
        Report r = new Report("Die Geschichte ist sehr kurz.");
        r.addOption("Das sehe ich.", "leave");
        return r;
    }
    @Override public void receiveMessage(String s) {
        if (s.equals("leave")) {
            exit();
        }
    }
}

Interessantere Geschichten sind aufwendiger, sowohl beim Programmieraufwand als auch von der Erzählkunst her.

Programmiert und getestet würde das weiterhin in BlueJ, mit der vereinfachten BlueJ-Spielweltoberfläche, und wenn ein Schwung Klassen fertig ist, kommen werden die zu einer Welt hinzugefügt und in die neue Android-Version als Auswahlmöglichkeit integriert. (Davor muss ich mir die urheberrechtliche Erlaubnis von Eltern und Minderjährigen holen, und natürlich nur, wenn die das überhaupt wollen.)

Was noch nicht eingeschaltet ist, aber bereits funktioniert

  • Sinnvolle Zufallsbegegnungen beim Unterwegssein. Man müsste nur welche schreiben.
  • Kontinuierliche laufende leise Hintergrundmusik. Man müsste nur welche suchen oder aufnehmen.
  • Geräuscheffekte, die in Location oder Story angelegt werden und dann in Zufallsabständen wiedergegeben werden; ich denke da an Vogelruf am Hafen und so etwas. Man müsste nur welche suchen oder aufnehmen.
  • Orte, die erst auf der Karte erscheinen, wenn man in ihre Nähe kommt. Das lohnt sich erst, wenn markiert wird, wo überall man bereits war.
  • Verschiedene Zoom-Levels.

Was noch nicht geht

  • Fog of War: Dass die Landkarte erst nach und nach aufgedeckt wird.
  • Tiling. Im Moment ist der Hintergrund eine einzige, mittelgroße Bilddatei. Für größere Projekte und mehr Details wollte ich eine höher aufgelöste Datei in gleich große Stücke zerschneiden und jeweils nur die aktuell sichtbaren zeichnen lassen. Dazu habe ich mir erst eine Grafik erstellt mit 5×5 solcher Tiles und einen roten, verschiebbaren Rahmen, der den Handybildschirm darstellt. Bei den dargestellten Größenverhältnissen werden je nach Position des Rahmens sechs bis neun der Tiles angezeigt, meistens unvollständig. Ich habe mir auf Papier, also am Rechner, notiert, wie der Algorithmus dabei wohl aussehen würde:
  • Und den notierten Java-Code rechts habe ich dann ins Programm kopiert und er hat – von einem falschen Doppel- statt Strichpunkt – sofort und perfekt funktioniert. Da war ich dann schon stolz. (Allerdings läuft das zu langsam. Double Buffering ist das erste, was mir dazu einfällt, da muss ich mal reinschauen, und notfalls halt doch mal ein Buch dazu lesen.)

Didaktische Sinnhaftigkeit

Schwierig. Die Klassen, die Schülerinnen und Schüler beisteuern, könnten eigentlich auch in einer anderen Syntax notiert werden, andererseits schadet Java auch nicht, ist ohnehin Lernziel, und ermöglicht mehr Möglichkeiten bei Sonderfällen. Allerdings wird man wenig Algorithmik üben, gar keine Schleifen, nur verschachtelte bedingte Anweisungen. Man modelliert halt einen Zustandsautomaten, das ist es schon. Ich suche nach einer Idee, wie man anspruchsvollere Aufgaben, also mit mehr Algorithmik oder Modellierung, in ein Framework integrieren kann. Also doch mal eine Art Core War?

(Arrays kann man einsetzen, wenn es um das Generieren von Zufallstext geht, aber auch dafür braucht man keine Schleifen.)

Design, Userfreundlichkeit und Aussehen

Ich kann das nicht gut, und ich interessiere mich zu wenig dafür. Ja, ich sehe, wenn ich am Kerning bei einem Schriftzug etwas ändern muss. Und ich weiß, dass ich mit einer Palette anfangen sollte. Aber die Mühe mache ich mir nicht; ohnehin rechne ich damit, dass die Schüler und Schülerinnen eigene Vorstellungen haben und Zeichnungen mitbringen werden.


Beitrag veröffentlicht am

in

Kommentare: 0

Schlagwörter:

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert