HackAddict

auch wenn Spieleentwicklungen sicher zu den aufregenderen Disziplinen in der Softwareentwicklung gehört, gibt es immer wieder Phasen in denen man langweiligere Sachen machen muss. Durch diese Phasen muss man sich regelrecht quälen und es sind echte Motivationskiller.

In so einer Phase befinde ich mich gerade auch in DMW. Wir sind jetzt an einem Punkt an dem wir erste Testanimationen brauchen und es ist abzusehen, dass wir bis zum release etliche weitere brauchen werden. Schon das schreiben der Animationsklassen war reichlich unangenehm, in dem Sinne das man die ganze Zeit dachte 'Hey das hab ich doch schon 1000x gemacht...". Wir verwenden ein XML-basiertes Animationsformat, dass sehr sehr rudimentär und lightweight ist, aber wir denken für DMW wird es schon reichen.

Nun habe ich mir gedacht, es wäre doch cool die Animationen mit einem kleinen Tool zu bauen, damit man nicht immer und immer wieder XMLs tippen muss, zwischen dem grafikprogram und dem editor hin und her muss und dann am ende noch das spiel starten muss um zu gucken, wie dass Teil nun aussieht. Hätte ich gewusst, wie das mal wieder ausartet, hätte ich es wohl bleiben gelassen.

Wie auch immer hier ein erster Screen (ich weiss, den icons fehlt transparenz):

Es ist noch einige zu machen, wenn Lee unsere Swing-Guru mal mehr supporten würde, wäre ich vielleicht schon fertig.

auch wenn es vermutlich keinen interessiert, dachte ich es wäre mal Zeit für einen kleinen Grundsatzartikel 'Behind the Scenes' wie ein HackAddict-Produkt entsteht.

In der Regel beginnt alles mit der fixen Idee ein neues Projekt zu starten. Normalerweise passiert das eigentlich immer wenn das aktuelle Projekt tot oder eingeschlafen ist oder uns zweifel am aktuellen Projekt kommen zum Beispiel unüberwindbare (scheinende) technische oder konzeptionielle Probleme. Förderlich ist auch wenn sich das Freizeitniveau von Lee oder mir mal wieder knapp über 0 bewegt und die letzte 'Revoultion' schon lange zurückliegt. Wir starten normalerweise mit einer recht ausführlichen Konzeptionsphase die wir intern gerne als Specing bezeichnen. Da wir uns aus zeitgründen trotz gemeinsamer (haupt-)Arbeitstelle recht selten persönlich sehen und wir die persönlichen treffen lieber zum wirklichen Coden verwenden wollen, findet diese Phase in der Regel rein virtuell statt. Entweder in Form einer Kettenmail die immer wieder hin und her gesendet wird und somit quasi chatcharakter hat oder gleich in unsere #HackAddict IRC-Chat auf EUIrc.

Häufig fangen wir unbewusst mit sowas an und noch bevor wir uns eingestehen, dass es bei dem Project das wir gerade fertig stellen wollen (im bestenfall temporär) nicht weiter geht.

Am Anfang gleicht das Specing mehr einem Brainstorming mit dem Austausch von größenwahnsinnigen Ideen. Da das mittlerweile eine recht lange Tradition bei uns hat, haben wir einen ganzen Stapel von halbausgegorenen Konzepten im Keller, die im Rahmen der ersten Phase gerne mal wieder hervorgezaubert und neu diskutiert werden. In der Regel wird auch das ein oder andere Projekt was bereits halb fertig ist auf den Tisch geworfen und diskutiert ob man nicht besser daran weitermachen sollte. Wenn TankYou nicht gerade das abzulösende Projekt ist, ist dass normalerweise der heisseste Kandidat dafür...

Am Ende kommt dann meistens was ganz neues dabei raus, ohne dass irgendwelche objektiven Vorteile für den Gewinner sprechen müssen. Wenn wir glauben uns auf eine Idee geeinigt zu haben, geht das Specing in Phase zwei, bei der wir immer ziemlich schnell (zu) tief ins Detail gehen. Dabei bekommen wir uns regelmässig über Realisierungsdetails in die Wolle die zu dem Zeitpunkt eigentlich garkeine Rolle spielen dürften und nicht selten stellen wir dann fest, dass wir zwei völlig unterschiedliche Visionen im Kopf haben, wie dass fertige spiel den nun aussehen sollte (und damit meine ich nicht den Grafikstil oder so banale Dinge). Nicht selten stirbt das Projekt schon hier und wir gehen wieder zu Phase 1 zurück. Stellen wir diese Differenzen erst später fest überlebt das Projekt meistens und wir mergen unsere Ideen irgendwie zusammen. Ziemlich früh in Phase 2 einigen wir uns auch schon auf einen Namen, was wiederum jedem Schulbuchvorgehen wiederspricht, aber es ist einfach besser nicht von Projekt X sondern von irgendwas konkretem zu sprechen und zu schreiben. Steht der Name fest bürgert sich recht zügig eine Abkürzung, meist ein Akronym ein, weil keiner Bock hat 1000x z.B. Dead Men Walking, Martes Zibellinae oder Tank You zu schreiben, heisst es dann schnell DMW, MZ bzw. TY und jedes zumindest wir beide wissen was gemeint ist. Wie (glaube ich) alle Informatiker besitzen wir eh eine Affinität zu Abkürzungen und schaffen exessiv neue währen wir uns austauschen was die Kommunikation erstaunlich verbessert und erstaunlicher weise bisher nie zu missverständnissen geführt hat, obwohl die Abkürzungen normalerweise Stillschweigend ohne große Erklärung von einem in den Raum geworfen werden.

Als nächstes entscheiden wir normalerweise welche Sprache oder Engine wir zu realisierung benutzen wollen. In unseren wilden Tagen waren dass auch immer endlose Diskussionen, in letzter Zeit einigen wir uns aber immer schnell auf Java.

Während ich die Zeilen schreibe fällt mir auf, dass ich verdammt Bock hätte mal wieder was in C++ zu machen. Genau das sind diese gefährlichen Gedanken, die ein Projekt zum scheitern bringen und eine neues initieren, weshalb ich sie gleich wieder tief in mir verberge...

Wie dem auch sei, wie oben angedeutet legen wir auch recht früh Implementierungsdetails fest, die sind zwar nicht in Beton gegossen es kommt aber irgendwie selten vor, dass wir nacher daran rütteln. Bei DMW um ein Beispiel zu bringen, waren wir uns zum Beispiel sehr schnell einig Grafiken als logische Masken zu verwenden, wir diskutierten nur kurz ob es besser wäre Vector- oder Rastergrafik zu nutzen. Die Entscheidung viel lange vor anderen spielmechanisch wichtigeren Entscheidungen z.B. wie sich Zombies an Wänden verhalten sollen oder ähnlichem. Während Phase 2 zwingt dann einer den anderen von Zeit zu Zeit eine Zusammenfassung über das bisher beschlossene zu verfassen. Dieser sogenannte Roman dient dazu in den 1000000mb Chatlogs und Mailhistorie nicht den Überblick zu verlieren.

Am Ende des Specings setzt Lee dann ein Projekt in Trac unserem Projektmanagement-Tool der Wahl auf und wir schreiben eine Seite in das integrierte Wiki auf denen alles nochmalgrob zusammen gefasst ist.

Neben Trac richtet Lee dann auch noch ein Repository in der Versionskontrolle ein, was wir da benutzen ist auch immer Diskussionsgegenstand, in letzter Zeit haben wir uns auf svn eingeschossen.

Nach dem Specing beginnen wir dann mit der eigentlichen Implementierung, die, besonders am Anfang, eigentlich fast ausschliesslich im Rahmen von persönlichen Treffen, den sogenannten Sessions abläuft. Da wir wie schon erwähnt nur sehr selten dazu kommen uns zu treffen, schleppt sich die Implementierung immer etwas zäh dahin. Wenn wir einen gewissen Stand erreicht haben verteilen wir auch schonmal Aufgabenpakete und jeder kann dann für sich weiter machen auch ohne Treffen. Von allen Sessions ist die aller erste normalerweise die schlimmste. Vor der Session haben alle die tollsten Erwartung und man malt sich schon aus wie weit man kommen wird, am Ende folgt dann in der Regel die Ernüchterung, dass man gerade mal das Projekt aufgesetzt und sich auf einen Packagenamen geeinigt hat. Gerade am Anfang weiss man halt nie genau wie man anfangen soll und wo was hingehört und es dauert immer bis man ein gute Grundgerüst aufgebaut hat.

Bei DMW haben wir es diesmal mit Prototyping versucht, dass hatten wir uns schon bei etlichen Projekten vorgenommen, aber nie durchgezogen bis jetzt und es klappt bisher hervorragend, aber dazu will Lee nochwas schreiben und dem will ich natürlich nicht zuvorkommen.

Wie ihr es von uns gewohnt seit lagged unsere Blogbereichterstattung mal wieder gewaltig.

TankYou hat sich seit unserer Techdemo ziemlich gewandelt und ist auch wieder ein gutes Stück vorran gekommen (wenn auch langsam). Sogar so stark, dass der Arbeitstitel TankYou wohl nicht mehr für den release taugt. Aber dazu vielleicht später mehr, wenn das Projekt wieder in den Fokus rückt. Momentan haben wir unsere Aktivitäten dies bezüglich nämlich erstmal auf Eis gelegt und uns ein kleines Intermezzo mit einem neuen Projekt gegönnt.

Dead Men Walking lautet der Arbeitstitel. Es ist ein eher casualiges Puzzlegame bei dem man Versucht eine Horde Untote von einem Eingang in einen Ausgang zu geleiten. Die Spielmechanik ist an den Klassiker Lemmings angelehnt. Im Gegensatz zu Lemmings bedienen wir uns bei DMW allerdings einer strikten TopDown-Perspektive was einige interessante Twists mit sich bringt.

Hauptziel ist es ein Miniprojekt fertig zu stellen und damit auch die Motivation für unseren langläufer TankYou zu erhalten.

Wir planen diverse DMW Versionen, neben einem Applet soll es auch eine eigenständige Desktopversion und auch eine mobile Android-App geben. Momentan evaluieren wir welche Engines bzw. Libs für welche Version am geeignetsten wären oder ob wir lieber alles in simplen Java2D halten sollten.

Eine Techdemo die läuft haben wir im Prinzip bereits, dass User-Interface und auch die Grafik ist aber dermassen unterirdisch das wir uns momentan noch mit ersten Screens oder gar einer öffentlichen Demo zurückhalten wollen und werden.

Nun da wir endlich ein Blog für das TankYou-Projekt haben, denke ich wir sollte mit einem kleinen Rückblick auf die Geschichte des Projektes beginnen. Auch wenn es unglaublich scheint und ziemlich peinlich ist, reichen die Wurzeln von Tank You zurück in das Jahr 1995. Das Projekt (bzw. sein Vorgänger) startete unter dem Namen "Martes Zibellinae" (Latein für Zobel). Geplant war einen simplen Worms-Clone mit kleinen Zobeln anstatt Würmern zu bauen. Wir liebten Worms sehr, doch fanden dass es mit der Qualität der Serie mit jeder Fortsetzung weiter Berg ab ging. Weil wir damals noch zur Schule gingen, hatten wir eine Menge Freizeit, aber wir begannen mit wenig Erfahrung in Spieleentwicklung und nur mit mittelmässiger Programmiererfahrung.

Der erste Versuch wurde in C++ entwickelt und nutzte reines Direct X. We kamen überraschend weit und hatten eine Art Demo mit Explosionen, zerstörbarem Land, Minen und so genannenten "Quietscheentchen", aber ohne spielbare Zobels. "Quietscheentchen" sollten eine spezielle Minenart werden, die explodiert sobald ein Zobel sie wieder verlässt, nachdem er auf sie drauf getretten war. Wegen unsere fehlenden Erfahrung war die Codequalität grauenvoll und das ganze Projekt war kaum wart- oder erweiterbar. Da war ein Bug in der Zündungslogik der "Quietscheentchen" und egal wie sehr wir es versuchten, wir konnten ihn nicht beheben. Letztendlich haben wir dann den ersten Versuch für tot erklärt und uns entschieden nochmal komplett von vorne zu beginnen. Ich würde euch gerne diese alte Demo mit ihrer Pixelgrafik zeigen, aber unglücklicherweise ist sie während eine Plattencrashs verloren gegangen (wir hatten auch wenig Erfahrung in Datensicherung und Versionskontrolle ;) )

Im zweiten Versuch wollten wir ein Fundament schaffen, auf dem wir das Spiel aufbauen konnten, also versuchten wir eine kleine Spriteengine als Abstraktion von Direct X zu schaffen. Das Ding hiess HASE ein backronym für (HackAddict Sprite Engine). Es konnte Animationen und hatte einen coolen Algorithmus für die automatische Aufteilung der Spritegrafiken auf die einzelnen Offscreensurfaces. Ich weiss nicht mehr genau warum der zweite Versuch schief lief, aber er tat es. Ich denke es war, als wir die Schule verliessen und der Wehrpflicht sei dank zur Bundeswehr mussten. Wir hatten kaum noch Freizeit und die die wir hatten verbrachten wir damit den Sold zu versaufen.

Im dritten Versuch wechselten wir von Direct X zu SDL zunächst nur um das Spiel plattformunabhängig zu entwickeln, aber in Endeffekt hat es sich als Verbesserung in fast allen Bereichen herrausgestellt. SDL ist eine super Engine, aber dass hielt die Entwicklung nicht davon ab wieder einzuschlafen.

In der Zwischenzeit hatten wir begonnen auch hauptberuflich als Softwareentwickler zu arbeiten und auf der Arbeit entwickelten wir Applikationen in Java. Auch wenn Java nicht den besten Ruf für Spieleentwicklung hat, entschlossen wir uns es einfach mal auszuprobieren. Wir schauten uns damals auch Slick an, entschieden uns dann aber auf 3D umzuschwenken und die jMonkeyEngine einzusetzen. Es klappte ziemlich gut, aber wir hatten viel Ärger mit der Landgenerierung und wieder einmal zu wenig Erfahrung, diesmal in der 3D-Entwicklung.

Nach dem Ausflug in die Java-Welt gingen wir zurück auf C++ und SDL. Wir bauten eine Engine auf die ich immer noch recht stolz bin. Sie konnte mit erweiterbaren und in XML-beschriebenen Ressourcen umgehen und war sehr flexibel und performant. Dieser Versuch starb, als wir merkten, dass wir hardware-beschleunigte Rotation brauchen könnten. SDL unterstüzt nur sehr langsame Software-Ration und die OpenGL-Einbindung erforderte sehr viel OpenGL-Erfahrung, welche wir nicht hatten.

Nach diesem Fehlschlag entschieden wir uns dann das Spielkonzept radikal zu verändern und Panzer statt Zobel zu verwenden, hin zum jetzigen Design. Aller guten Dinge sind Sechs. We ihr sehen könnt sind wir wieder auf Java unterwegs, mit Slick und echtzeit Physics in (j)box2d. Wir sind alt und erfahren genung und wissen was wir tun, dass einige Problem ist immernoch unser Mangel an Freizeit, die wir in das Projekt investieren können.

Jetzt sind wir sehr heiss darauf endlich ein Projekt abzuschliessen.

Wir haben endlich die Motivation gefunden unsere Seite zu relaunchen.