Spielmechaniken
Bei Soko Move handelt es sich um ein für Android entwickeltes Puzzelspiel. Den Namen hat das Spiel aufgrund seiner Ähnlichkeit zu
Sokoban bekommen, auch wenn diese nur geringfügig vorhanden ist. Um die Puzzle zu lösen, muss man Blöcke verschieben und farbig markierte Blöcke auf dafür vorgesehene Positionen bringen. Neutrale, nicht eingefärbte Blöcke müssen nicht auf bestimmte Positionen verschoben werden, sondern stellen lediglich Hindernisse dar. Weiterhin gibt es neutrale Blöcke mit eingeschränkter Bewegungsrichtung, die ebenfalls ausschließlich Hindernisse darstellen.
Diese Blöcke kann es in unterschiedlichen Größen geben. Für farbige Blöcke heißt das aber auch, dass sie auf eine farbig markierte Fläche der gleichen Größe geschoben werden müssen, damit das Rätsel gelöst wird.
Im Spiel soll außerdem ein Editor enthalten sein, mit dem der Spieler seine eigenen Puzzle erstellen kann. Ich benutze diesen Editor derzeitig auch, um die Puzzle für das Spiel zu erstellen. Es ist vorgesehen, dass die Puzzle dann über soziale Netzwerke oder per E-Mail geteilt werden können. Wird der Link auf einem Android-Gerät mit installiertem Spiel geöffnet, soll Anhand eines URL-Scheme das Spiel geöffnet werden, welches anhand der in der URL enthaltenen Parameter das Puzzle übergeben bekommt. Um einen Fallback für Android-Nutzer ohne das Spiel und alle Nutzer anderer Geräte zu haben, würde der Link auf meine Seite verweisen, die einerseits einen Informationstext anzeigt und andererseits eine Vorschau auf das erstellte Puzzle.
Das Spiel soll am Ende kostenlos zur Verfügung gestellt werden, ohne Werbung oder in-App-Käufe. Kurz gesagt soll es keine Monetarisierung geben.
Soko Move ist bisher nur ein Arbeitstitel. Es kann sein, dass dieser noch geändert wird.
Entwicklungsstand
Die Spielmechaniken und der Editor sind soweit implementiert und funktionieren, ohne dass mir großartige Fehler bekannt sind.
Ansonsten steht mir eine bereits relativ gut überschaubare Menge an Aufgaben bevor, bevor das Spiel als fertig betitelt und veröffentlicht werden kann.
- Diverse Verbesserungen am UI, wie Vereinheitlichungen des Layouts, ggf. anpassen der Button- und Schriftgrößen, Anpassen der UI-Farben usw.
- Soundeffekte, auch wenn ich noch nicht ganz entschlossen bin, welche einzubauen
- Verbesserte Darstellung der Blöcke, sodass diese aus Teilen - Ecken, Kanten, Inhalt und zusätzliches Symbol bei Bewegungseinschränkung - zusammengesetzt werden, statt die bisher verwendet Grafik einfach zu skalieren
- Etwas höher aufgelöste Grafiken generell
- Polishing an ein paar weiteren Stellen, wie Partikeleffekte
- Das Teilen der Puzzle. Im Grunde sollte das kein zu großes Problem sein, sofern alles so funktioniert, wie ich es mir derzeitig erhoffe.
- Puzzle! Auch wenn das eine kleine, also mit wenig Worten beschreibbare, Aufgabe ist, dürfte sich das letztendlich am stärksten in die Länge ziehen. Bisher sind die ersten 12 fertig und in einer sinnvollen Reihenfolge angeordnet, idealerweise will ich aber 60 oder 120 Puzzle ausliefern. Möglicherweise werde ich genau hier aber Abstriche hinnehmen müssen
Technische Details
In einem Forum wie diesem dürfen natürlich ein paar Informationen zur Umsetzung nicht fehlen. Ich verwende Unity - derzeitig in der Version 4.6 - mit den 2D Tools und dem in der Version 4.6 dazu gekommenen UI System. Derzeitig verwende ich keine Plugins, das könnte sich aber für das Teilen der Puzzle noch ändern, gerade was das Definieren des URL-Schemes angeht.
Rückblickend betrachtet wäre es vielleicht nicht ganz unsinnig gewesen, statt Unity ein Framework für reguläre Apps zu verwenden, da das Spiel im bei der derzeitigen Umsetzung hauptsächlich aus "normalem" UI besteht. Da ich aber nicht ausreichend Vorteile in einem Umstieg sehe, und mir so auch die Möglichkeit für viele Spielereien offen halte, werde ich auch weiterhin Unity verwenden.
Da ich Unity verwende, könnte ich zwar relativ leicht auch für andere Plattformen, wie andere Mobilgeräte, Desktop-PCs oder den Webplayer exportieren, allerdings kann ich nicht für iOS exportieren, da ich weder Mac noch iOS Gerät habe, für Windows Phone könnte ich es nach dem Export nicht testen, da ich kein solches Gerät da habe, und da das Spiel für Touch-Eingabe konzipiert ist, wäre eine Bedienung mit Maus zwar möglich, würde sich aber sehr wahrscheinlich weniger gut anfühlen.
Bevor es das neue UI System gab, habe ich angefangen, mir ein eigenes System zu entwickeln, welches u. a. ausreichend dynamisch die Elemente anordnen sollte. Da das neue UI System allerdings eine gute Ausgangsbasis für das Definieren von Layouts mitbringt und notfalls auch erweitert werden kann, stieg ich relativ schnell darauf um und warf das, was ich davor gemacht hatte, über Bord.
Warum Unity 4.6? Ich habe bereits einen Umstieg auf die neue Version versucht, aufgrund diverser Probleme habe ich das dann aber wieder verworfen. Die Probleme, die ich bisher nicht lösen konnte, waren:
- Alle Touch-Eingaben waren vertikal verschoben. Hat man Buttons oder Blöcke etwas zu weit oben antippen wollen, hat man diese nicht erwischt. Ausgelöst wird das durch den Aufruf Screen.SetResolution(Screen.width, Screen.height, false). Diesen benötige ich derzeitig aber, da das UI derzeitig darauf ausgelegt ist, dass der Benutzer immer den normalen Back-Button sieht. Da das UI entsprechend angepasst werden kann, stellt das kein unlösbares Problem dar, aber dennoch eins, welches mit Aufwand verbunden wäre.
- Wird das Spiel über Application.Quit() beendet, zeigt Android - zumindest auf meinem Gerät - die Meldung "Leider wurde Soko Move beendet." an. Bisher war das Einzige, was ich in dieser Richtung gefunden habe, Anmerkungen, dass dieses Problem durch Plugins ausgelöst wird, und man etwas machen soll, was ich bei mir nicht machen konnte - da ich keine Plugins eingebunden habe - und wovon an anderer Stelle aufgrund eines Folgeproblems abgeraten wurde.
In einem fast leeren Testprojekt konnte ich diesen Fehler allerdings nicht nachstellen, das heißt auch dieses Problem sollte auf Dauer lösbar sein, wäre aber ebenfalls mit Aufwand verbunden.
Ebenso hätte ich mit Unity 5 den Nachteil, dass Unity dann im Editor unter Windows die im System eingestellten DPI-Wert ausliest und für das UI verwendet. Der Standardwert ist dabei 96 DPI, der Bildschirm meines Laptops, an dem ich vorrangig entwickle, hat aber rund 141 PPI. Da Unity vom System einen Wert bekommt, greift auch nicht die Fallback-Angabe, die ich vorher auf 141 stellen konnte. In Unity 5 kann ich also nur schwerer abschätzen, ob die Größe der UI-Elemente ausreichend ist, um gelesen zu werden - auch wenn dafür ein endgültiger Test auf einem Zielgerät ohnehin unumgänglich ist.
Assets
Derzeitig verwende ich die
Kenney Game Assets für die Puzzle- und diverse UI-Elemente und
Gemicons als Symbole für das UI. Ob ich bei diesen bleiben werde, wird sich aber erst zukünftig zeigen.
Schlusswort
Ich würde mich über Feedback, Anregungen und Fragen freuen. Sollte beispielseise Interesse an bestimmten Aspekten des Spiels bestehen, kann ich darauf gerne genauer eingehen.
Richard