Vielleicht erinnert sich noch der ein oder andere Forenmember: Ich hab mal vor ewigen Zeiten (2010) bereits einen Sokoban-Clone geschrieben, der quelltextmäßig alles andere als gut war. Ich dachte, ich hätte in den letzten Jahren etwas gelernt und wollte erneut eine Umsetzung des Spiels schreiben^^.
Zu Sokoban selbst: Ziel des Spiels ist es, Kisten zu Kistenzielen zu schieben. Allerdings hat der Spieler nur begrenzt Platz und kann Kisten auch wirklich nur schieben, nicht ziehen. Was die Ganze Sache zu der einen oder anderen Kopfnuss führt; im Grunde ist es also ein Rätsel- oder Knobelspiel. Bedienung ist: WASD, Pfeil- oder Nummerntasten für die Bewegung, "u" für einen Schritt zurück.
Downloadlink der Sourcen: https://mkcloud.goip.de/downloads/mksok ... an_src.zip (ca. 811 KB groß)
Programm wurde unter Python 2.7 und 3.6 erfolgreich unter Windows und Android getestet, sollte aber auch unter Linux und Macs laufen. Wer das Spiel auf Android zum Laufen bringen möchte, lädt sich vom Google PlayStore den "Kivy Launcher" runter und kopiert das Verzeichnis "mksokoban" in den Ordner "/sdcard/kivy/" rein (ggf. erstellen). Unter Windows lässt sich Kivy mit der entsprechenden Einrichtungsseite sehr leicht installieren (das auf der Seite erwähnte, optionale "kivy.deps.gstreamer" braucht ihr nicht, um Sokoban ausführen zu können). Linux-User müssen über den Paketmanager entsprechende Kivy-Pakete runterladen und installieren.
Screens:
Ich dachte, es wäre vielleicht interessant, meine Gedanken während des Programmierens festzuhalten, weshalb ich euch nun damit behellige/langweile^^:
- Irgendwie hab ich mir angewöhnt, "MVC"-mäßig das Ganze aufzuteilen (was im Laufe des Projekts aber nicht immer gut klappte^^). Da gibts etwa die "models.py", welche quasi die kompletten Spielregeln und Geschäftslogik beinhaltet. Zum Testen hab ich mir einen Viewer geschrieben, der in der Kommandozeile bedient wird ("cmdviewer.py"). Sollte übrigens immernoch einwandfrei laufen, wenn man in der "main.py" die Zeilen 5 und 6 entsprechend anpasst. Auf alle Fälle ist das Ding perfekt dafür geeignet, das Modell auf Herz und Nieren zu testen, bevor man sich an die Umsetzung der Grafiken wagt. Die Kommunikation findet über Events statt: Der Viewer schnappt sich die Modelle und bindet die Events, die besagte Modelle bereitstellt, an eigene Methoden. Auf einen echten "Controller" in dem Sinne habe ich verzichtet...
- Fallstrick: Ich hielt es beim Modell für eine gute Idee, "verbesserte" Versionen zu erstellen und davon abzuleiten (z.B. das "SokobanGame"-Modell mit einem Schritt-Zähler zu erweitern). Erst im Nachhinein fielen mir Methoden auf, die bei Fehlern einfach aus der Methode rausspringen, aber beim "Erben" besagter Methoden logischerweise nicht. Was leider zu fünf, sechs Zeilen kruden Code zu den entsprechenden Methoden geführt hat und ich keinen Nerv mehr hatte, das Ganze neu zu überdenken.
- GUI-Programmierung nervt. Wahrscheinlich habe ich auch nicht genügend Kenntnisse in dem Bereich... Ich hab trotzdem nicht damit gerechnet, dass beim "kivyviewer.py" ein Drittel mehr Quelltextzeilen existieren als bei der "model.py".
- Generell fand ich es nach längerer Zeit ziemlich dumm von mir, jegliche mögliche Klasse beim Viewer in ein- und derselben Datei unterzubringen. Am Anfang hielt ich das für eine gute Idee (bin eher ein Freund von wenigen Quelltextdateien), später war ich froh, in einer IDE mit Komfortfunktionen programmiert zu haben beim dauernden Hin- und Herspringen^^. Lektion ist diesbezüglich gelernt, sowas werde ich nie wieder machen und war gegen Ende richtig frustrierend für mich^^.
- Was mir auffällt: Ich weiß, Singletons sind in den allermeisten Fällen phöse, trotzdem finden sich bei Quelltextbeispielen - gerade wenn es um die Entwicklung von Spielen geht - überraschend viele Beispiele dafür. Ob das auf Unwissenheit beruht, wage ich stellenweise ernsthaft zu bezweifeln, da ich hier z.T. recht aktuelle Bücher über Spieleprogrammierung habe und ebenfalls hie und da Singletons verwenden.
- Andererseits eignen sich Singletons (leider) perfekt dafür, nicht so ganz durchdachte Kapselung der Klassen und Methoden zu kaschieren (*hust*). Ich hab mich auch das ein oder andere Mal dabei ertappt, dass ich eigentlich eine Info einer Methodenvariable bräuchte, die sich allerdings in einer anderen Klasse befand...
- Achja, pep8: Hab ich zum Großteil umgesetzt, aber rund 99% der Fehler werden von Leerzeilen geworfen, die eingerückt wurden. Sorry, werd ich auch nicht ändern, da ich sonst mit JEDER IDE wahnsinnig werden würde und zudem die Lesbarkeit wirklich nicht einschränkt - es sei denn, jemand will sichtbare Leerzeichen haben...
- Generell muss ich sagen, dass mich insbesondere die Programmierung der GUI ziemlich geschlaucht hat. Ich glaub, ich hab mehr als 50% der Zeit nur damit verbracht. Alleine deswegen verstehe ich jetzt (besonders bei umfangreichen Programmen) mehr als deutlich, warum es nicht zu jedem Programm eine grafische Benutzeroberfläche gibt^^. Ich will in nächster Zeit von Kivy echt nichts mehr sehen und bin froh, das Programm endlich fertiggestellt zu haben und es in nächster Zeit nicht mehr anzufassen^^.