quixotic project blog

Ich weiss garnicht mehr genau wann und wo ich Meggy Jr RGB zum ersten mal gesehen habe, aber mir war sofort klar, dass ich so ein Ding brauche! Meggy ist eine do-it-yourself Spielekonsole. Das bedeutet, dass man es selbst zusammenbaut und optional auch selbst Programme dafür schreibt. Entwickelt wurde das ganze von Evil Mad Scientist Laboratories als open-source Hardwareprojekt. Open-source bedeutet in diesem Zusammenhang, dass sowohl das Layout der Platine sowie die für die Programmierung benötigten Librarys frei erhältlich sind. In Meggy werkelt ein Atmega 168 Microcontroller vor sich hin. Meggy baut, im Hinblick auf einfache Toolchains und Prototyping-Qualitäten, auf Arduino auf.

Neben dem Microcontroller ist das Display sicherlich mit das größte Feature: Es ist eine LED Matrix bestehen aus 8×8 Elementen, die jeweils eine große Anzahl verschiedener Farben anzeigen können. Eine Auflösung von 8 auf 8 Pixel hört sich zwar klein an, aber schon die mitgelieferten Spiele zeigen, dass durchaus einiges Potential für gute Spiele vorhanden ist. Bisher habe ich sehr spaßige Meggy-Versionen von Frogger und Space Invaders gespielt. Das vorinstallierte Spiel ist ein sidescrolling Shoot-em-up bei dem man laut Beschreibung die Welt vor ein paar Tomaten rettet :) Es gibt sogar ein Meggy Roguelike (hier), allerdings habe ich es noch nicht selbst gespielt.

Aber Meggy eignet sich nicht nur als Spielekonsole. Mittlerweile gibt es auch eine ganze Reihe von Anwendungen die mit Spielen an sich nichts zu tun haben. Begünstigt wird das durch eine Serial Port mit dem man Meggy mit dem Rest der Welt sprechen lassen kann. Durch die Wahl von Arduino als Entwicklungsumgebung genügt dafür eine einzige Zeile für die Initialisierung und anschließend ein Serial.println("..."); um Text den Serial Port runterzuschicken. Als Beispiel sei hier mal das Projekt genannt in dem Meggy zusammen mit einem Arduino WaveShield als Sequenzer benutzt wird: MeggySeq

Hier ein paar Bilder vom Zusammenbauen:

Meggys Platine

Heh, ohne Kommentar..

Halbfertig mit Microcontroller und LED Treiber

Meggy Jr RGB fertig zusammengebaut

Kevin Glass neuestes Projekt MootoX nimmt langsam Formen an! Es handelt sich um ein 2D Racing Spiel bei dem man ein Fahrzeug, dass man von der Seite sieht durch ein Level steuern muss. Im Moment geht es nur darum alle Sterne einzusammeln bevor man ins Ziel kommt und dabei schneller zu sein als der Gegner, aber geplant sind wohl noch mehr Aufgaben.
Die Featureliste umfasst unter anderem eine eingebaute Physik, die das Spiel erst so richtig zur Herausforderung macht und den Wiederspielwert unglaublich erhöht. Ganz neu hinzugekommen ist jetzt die best-times Liste auf der ich im Moment auch verewigt bin, und zwar beim Level Underground. Dies liegt hauptsächlich daran, dass ich den Level selbst erstellt habe, denn die Konkurrenz ist extrem gut und scheint den ganzen Tag nichts anderes zu spielen ;)
Das Levelerstellen ist meiner Meinung nach fast das beste Feature am ganzen Spiel: Auf der Website ist es ganz genau beschrieben, deswegen hier nur in Kürze: Mit einem beliebigen SVG Tool zeichnet man einfach ein paar Polygone und hängt im Objektbezeichner ein Schlüsselwort dran und die Spielengine interpretiert die Zeichnung dann als Level. Das bedeutet, dass man die Levels fast im wörtlichen Sinne einfach nur hinmalen muss und schon kann man sie spielen.
Hier kann man das Spiel mit Java Webstart spielen.

Screenshot aus einem Multiplayerspiel

Vor einiger Zeit gab es eine Umfrage auf Andrew Doulls Seite Ascii Dreams welche Features ein roguelike unbedingt haben muss um ein roguelike zu sein. Zur Auswahl standen viele Dinge, hier eine Liste mit den am häufigsten genannten Punkten:

• Randomly generated levels 102 Stimmen (75%)
• Turn based combat 77 Stimmen (56%)
• Permadeath 77 Stimmen (56%)
• Character advancement 68 Stimmen (50%)
• Overhead view 53 Stimmen (38%)
• Unknown items / identify system 48 Stimmen (35%)
• Lots of items 47 Stimmen (34%)

Da 136 Leute abgestimmt haben hat die Abstimmung durchaus etwas Gewicht und spiegelt wider was die Besucher unter einem Roguelike verstehen. ASCII Grafik kam übrigens nur auf 32 Stimmen (23%)! Zum Spass kann man diese Liste mal als Maßstab nehmen um Spiele auf ihre roguelike-heit zu untersuchen:

Diablo:
Diablo hat zufällig erstellte Level, man kann den Protagonisten immer weitere Skills verpassen, sieht von oben schräg auf ihn herab und es gibt eine Menge von Gegenständen, von denen viele erst identifiziert werden müssen bevor man ihren wahren Wert erkennt. Das macht fünf Übereinstimmungen von sieben Möglichen. Diablo kann man nach dieser Skala also gut und gerne als roguelike bezeichnen.

Dwarf Fortress:
Die meisten Leute werden wohl sagen, dass Dwarf Fortress durch seine Ascii Grafik nur den Anschein erweckt als sei es ein Roguelike. Betrachten wir nur den Fortress-Mode und machen den Test. Die Level werden zwar vom Spieler erst so richtig mit Inhalt gefüllt, aber dennoch generiert das Spiel eine riesige, zufällige, persistente Welt zu Spielbeginn. Ich würde sagen das zählt als “randomly generated levels”. Mit kann das Spiel zu jeder Zeit angehalten werden, aber im Endeffekt ist es nicht rundenbasiert. Speichern ist nur möglich wenn man das Spiel verlassen will und wenn ein Zwerg stirbt, dann ist das ziemlich permanent. Ein Punkt für die roguelikes also. In DF steuert man keinen einzelnen Protagonisten, aber oft eine ganze Horde davon, die durchaus besser auf ihrem Gebiet werden können. Noch ein Punkt fürs Roguelike. Die Ansicht der Welt kann durchaus als “overhead view” bezeichnet werden und Gegenstände gibt es in Hülle und Fülle, allerding ist von allen klar was sie machen. Nochmal zwei Punkte aufs Roguelikekonto. Alles in Allem macht das fünf von sieben möglichen Punkten und Dwarf Fortress ist genauso ein Roguelike wie Diablo.

Ihr findet Dwarf Fortress kann trotzdem nicht als Roguelike bezeichnet werden oder es fehlen noch wichtige Punkte auf der Liste? Schreibt mir!

Beim Stöbern durch die Bibliotheken von ACM bin ich auf folgenden Artikel gestoßen: Computer games as motivation for design patterns. Paul V. Gestwicki beschreibt darin wie er mit Hilfe eines Computerspiels seine Studenten motiviert sich mit Design Patterns zu beschäftigen. Obwohl man ja gerade bei Spielen oft darauf aus ist noch die letzten FPS aus dem Code herauszuquetschen lohnt es sich doch nicht allen Code auf Performance auszulegen, sondern einen strukturierten Ansatz zu verfolgen. Die Vorteile liegen auf der Hand: Der Code wird lesbarer, leichter wartbar und besser erweiterbar.

Das erste Design Pattern in seinem Paper ist das State Pattern. Anhand einer Sprite Klasse, die zuständig für das Aussehen, die Größe und Position des Spielers ist, erläutert er das Pattern. Der Spieler kann sich in mehreren Zuständen(=States) befinden und das Verhalten der Sprite Klasse ändert sich mit jedem Zustand. Eine naive Implementation würde jedem Zustand einen int-Wert geben und dann in einer update() Methode später einen großen switch-Block durchlaufen in dem jedes Verhalten in jedem Zustand beschrieben ist.

Im Buch Design Patterns von Gamma et. al. wird jedoch genau dies als Grundlage der Anwendbarkeit des State Pattern angegeben:

• An object’s behavior depends on its state, and it must change its behavior at run-time depending on that state
• Operations hve large, multipart conditional statements that depend on the object’s state. This state is usually represented by one or more enumerated constants.

Wie sieht nun so ein State Pattern aus? Zu allererst brauchen wir ein Interface, dass einen Zustand beschreibt:

1
2
3
4
5
6

public interface State {
public void install();
public void uninstall();
public void draw();
public void update();
}

Die Spieler Klasse muss nun eine Variable vom Typ State besitzen mit der angegeben wird in welchem Zustand der Spieler sich gerade befindet. Außerdem müssen alle Aufrufe die den Zustand des Spielers betreffen an die State-Implementation deligiert werden. Skizzenhaft sieht der Spieler dann so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class Spieler{
State aktuellerZustand;
 
...
 
public void update(){
aktuellerZustand.update();
}
 
public void draw(){
aktuellerZustand.draw();
}
 
...
}

Was nun noch fehlt sind tatsächliche Implementationen des State-Interfaces. Hier hat man mehrere Möglichkeiten. Zum einen kann man innere anonyme Klassen verwenden:

1
2
3
4
5
6
7
8

//Konstruktor
public Spieler(){
aktuellerZustand = new State(){
public void install(){...};
public void uninstall(){...};
public void update(){...};
public void draw(){...};
}

oder man verwendet einfache innere Klassen, d.h. in der Spieler Klasse werden weitere Klassen definiert die jeweils das State Interface implementieren. Beides hat den Vorteil, dass man die Logik und das Verhalten des Spielers sehr nahe am Spieler selbst hat. Die inneren Klassen können auf Variablen der äußeren Zugreifen und so mit dem Spieler interagieren. Weiterhin verbirgt man die konkreten Zustände vor der Außenwelt.

Das Spieler Objekt könnte nun selbst entscheiden wann es welchen Zustand braucht, einfacher und manchmal auch schöner ist es jedoch die Zustände selbst entscheiden zu lassen. Hierfür gibt es die Methoden install() und uninstall(), die einen Übergang von einem zum anderen Zustand erlauben indem sie einfach die State Variable des Spielers neu setzen. Denkbar ist natürlich auch, dass in diesen Methoden spezielle Animationen für die Übergänge ausgelöst werden usw.