Steamclash - Sales I

Sales and Trends I - It has begun

Steamclash

Post Mortem

Steamclash ist unser dritter und letzter Prototyp der im Verlaufe des Kurses entstanden ist. Der zweite Prototyp bestand aus vielen kleinen Versuchen, die sich leider nicht richtig entwickelt haben. Aber das war Sinn und Zweck der ganzen Sache, mal Fehler im Verlaufe eines Kursprojektes zu erlauben.

Einer der Prototypen sollte ja weiter verfolgt werden, das haben wir mit Steamclash gemacht. Das ging so weit, das wir das Spiel App Store reif gebracht haben. In den nächsten Tagen sollte es erhältlich sein.

Die Website http://steamclash.com erklärt das Spiel in Videos und Bildern besser als ich es hier mit Worten machen kann.

Gameplay

Anders als bei Protoyp1 hat sich im laufe der Entwicklung nichts an der Grundidee geändert. Einzig an den Details mussten wir feilen.

Mit Grundidee mein ich, das es ein zwei Spielerspiel mit zwei iPhones ist, sich das Geschehen auf beide iPhones abspielt, jeder einen Hafen hat und mit Schiffen den anderen Hafen zerstören muss. Schiffstypen, Upgrades, alle Werte usw. waren dann die Details. Immer noch ne ganze Menge.

Grafik

Die Richtung hatte Malte relativ früh raus, wie das aber so ist, im laufe der Zeit entwickelt sich auch das weiter. Die Schiffe mussten mehrmals neu gezeichnet werden, da wir einmal von der Retina Auflösung weg mussten und dann die Anzahl der Bahnen verringert haben, wodurch sich die Grösse der Schiffe nochmals geändert hat.

Das Interface hat sich auch ständig verändert, bis wir dann die momentane und auch beste Lösung erreicht haben. Auch der Part geht auf Maltes Kappe, hat er sehr gut gemacht.

Technik

Beim ersten Prototypen hatte ich es ja schon angesprochen, das wir in die ein oder anderen technischen Schwierigkeiten gekommen sind, da wir 0 Plan von der Spiele-Entwicklung hatten. Das hat sich zwar mit dem verbessert, dennoch haben wir uns dazu entschieden impact.js zu kaufen und zu verwenden. Vor allem die Option den iOS Shim zu nutzten kam uns recht. Es hat sich gelohnt die 99$ zu investieren. Auch wenn im fertigen Spiel recht wenig von impact über blieb (kein Leveleditor, keine Kollision etc) hat es uns immens beim entwickeln geholfen.

Da das Endprodukt ja ein iOS App ist, mussten wir uns aus den warmen gefieden des Browser bewegen und mal ne „richtige“ Programmiersprache benutzten. Ich hab ja schon ein wenig Erfahrung mit Objective-C gesammelt, daher gab es da weniger Probleme. Impact hat da einiges vorbereitet. Interessant war mal mit zu bekommen, wie viel cooler es ist, im Browser zu entwickeln. Die Kontrolle die man während der Laufzeit über den Code hat ist einfach mega praktisch.

Ich mag Objective-C übrigens immer noch nicht. Der Syntax ist einfach hässlich. Brrr…

Netzwerk

Auf zwei Geräten das selbe Kampfgeschehen zu zeigen hat sich als schwerer herausgestellt als gedacht. Über den Daumen geschätzt würde ich sagen das die Hälfte meiner Entwicklungszeit dafür drauf ging. Und es ist leider immer noch nicht perfekt. Aber es funktioniert ausreichend, das Spiel leidet darunter keineswegs. Eine besondere Herausforderung war, wie ich zumindest dachte, den Netzwerkcode so zu gestalten, dass es im Browser und auf iOS Geräten funktioniert. Angefangen haben wir im Browser mit node.js und socket.io. Damit is zu so wenig Problemen wie möglich kommt, liegt im Serverpart keinerlei Logik, es werden blos Nachrichten weiter gereicht. Eines der Geräte übernimmt die Funktion des Servers, beim verbinden beider Geräte wird dieser per Zufall bestimmt.

Nun funktionierte das Netzwerk im Browser, Zeit das Ganze unter iOS zum laufen zu bringen. Mit wirklich 0 Erfahrung was das Thema angeht, hab ich blos einen Tag gebraucht um die aktuelle Version auch auf dem iPhone laufen zu lassen. Gamekit ist wirklich ziemlich einfach, zumindest wenn man sich mit einer einfachen Bluetooth Verbindung zufrieden geben kann.

Finale

Unserer erste grosse Termin war erstmal natürlich die finale Präsentation vom Kurs. Danach kam die IGF Students Entry Deadline und letztendlich der Appstore.

Gerade für den Appstore musste alles funktionieren und so hat ein recht langwieriger Prozess von Testen begonnen. Zweimals hatten wir das Spiel sogar schon hochgeladen, nur um es am nächsten Tag gleich wieder zurück zu ziehen, da wir unverzeihliche Fehler gefunden hatten. Die Phase hätten wir etwas gelassener angehen sollen, aber ich glaub wir beide waren zu aufgeregt und wollten das Projekt zumindest vorerst abschliessen. Dann kam endlich der selige Tag an dem es veröffentlicht war. Und es startete nicht. Yay. Natürlich haben wir die Release Version nie getestet, die Debug Version lief ja, also warum testen. So lernt man schmerzhaft.

Aber auch gut, das Spiel ist wieder eingereicht. Den nächsten Release Termin werden wir selber bestimmen und auch besser vorbereiten. So kann man sich mal in die fiese Welt des Marketings bewegen.

Just In Time

there are no more javascript interpreter

JavaScriptCore Nitro

Webkit / Safari

Compiles JavaScript to native machine code since 2008, just in time.

JägerMonkey

Firefox 4+

Based on JavaScriptCore Nitro.

V8

Chromium / Google Chrome 1+

Just in time compiling, one month later than Webkit.

Chakra

Internet Explorer 9+

Yes, Internet Explorer also does. And some fancy multi core stuff.

So, modern Javascript engines never interpret javascript?

Nope, they do. While compiling, they are interpreting the byte code, line for line. The result is that javascript applications speed up when the compiling is done. For video games based on javascript it would be nice to start after compiling to get stable fps.
I am searching for a way to do that, we will see.

threejs.org

We are working currently with mrdoop's WebGL and Canvas 3D Engine threejs. But we dislike the official API documentation, a single markdown formatted wiki page. So I created the alternative API documentation threejs.org. Clientside, non pre-indexed fulltext search, with daily git update from the official API (thanks philip for the regular expressions). based on our own webystem Hopkins. Next steps are examples and comments. mrdoop writes me that he will probably editing/improving the api documentation from time to time. I hope on it.

Prototyp1

Post Mortem

The first prototype is complete so it is time to write a post mortem. We set out to complete it in one month, it took only a week longer. So that goal was accomplished. It was the first video game for both of us.

The idea

In the last post Malte described the idea we had at the beginning. In short, we wanted to do a isometric real-time strategy game in a digital pre big bang world. The story stuff was getting to complex, so we cut it awayand concentrated on the gameplay itself. And even this changed a lot along the way.

The process was pretty iterative, our professor Dennis Paul even called it bottom up game development. I bet he didn’t know that this term already exists, I just discovered it right now. (As it turned out, he did know it. And this term is much older then game development. Sorry for that.)

We started with a world where you could build several buildings. We changed the behavior of the buildings constantly till we found something that was working. In the end only the land itself and one building was left.

So what is the game now? I don’t know if there is a good term for it, but maybe it’s a “expand and conquer multiplayer game”. That sounds somewhat right. The game itself has a more detailed description on what you do.

The technical stuff

Being web guys, it was pretty clear that this game has to run in the browser. But we had to choose between vanilla HTML, canvas or webgl. Like the previous post stated, we settled with vanilla HTML. The node.js part was new for both of us, so choosing a new technology in the graphical part sounded after to much work. And this was a good decision, we ran almost into no problem on this side.

Combined Server & Client Code

That was a thought that sounded pretty good in my head. We use javascript in the client and the server so why not combine the code base and use the same files for both. This turned out to be completely wrong. At least for two unexperienced javascript programmers like us who didn’t have a solid framework to build on.

Network Performance

To much network traffic makes the browser to melt down. We thought, hey, this is an event based environment, so respond to this events. There were to much of them so we had to collect them in the end and send them in a packet. The game isn’t that smooth now, but works better in the later game.

Over the internet the response time isn’t that great, there are lags here and there. But it is playable. Over the local network it works really good.

Gif Performance

Yeah, never thought I would care about this. But somehow displaying more than 10 gifs, even small ones, is hardcore for the browser. Malte did something smart and put a translate 3d css property on the gifs. Just rotate the gif around 0 degree. That way the gif will be rendered in a separated process. Combined with the massive html we rendered and complex css3 matrix transforms, this still wasn’t enough. So we scraped the gifs and used plain pngs instead.

Conclusion

It was fun. And hard. We started with a lot of ideas, got technical problems in the middle, which frustrated both of us a lot, we lost sight of where we are going and found a good solution in the end. I think the game is fun, even if I loose all the time against Malte.

Vorstellung Prototyp 1

Maschinenspiele

Unser erster Videospiele Prototyp wird ein Isometrisches Aufbaustrategiespiel in einer digitalen Vor-Urknall Welt.

Ein wenig zur Welt: Eine generierte Landschaft, eine schrumpfende Welt, Ressourcen Abbau bedingte Schrumpfbeschleunigung. Ein weiteres wichtiges Kernelement ist es, dass jede Ressource einer Einheit, einem Lebenspunkt und einem Angriffspunkt entspricht. Lasst euch überraschen was genau damit gemeint ist.

Da es sich um ein Multiplayer Spiel handelt denken wir aktuell an folgendes Setup: node.js für den Server, Websockets als Protokoll und JS/HTML/CSS für den Client. Eigentlich wollten wir WebGL einsetzen aber da fehlt uns noch etwas das Know How. Wenn der Prototyp begeistert im werden wir aber im zweiten Schritt auf OpenGL setzen.

früher Entwurf

Webweisheit #1

Ich werde ab Heute hin und wieder kleine Webdesign Weisheiten posten. Grundsätzlicher oder im Detail, da sortiere ich erstmal nicht.
Ich fange mit einer grundsätzlicheren Sache an die ich für sehr wichtig halte.

Entscheide was für eine Art Website du gestalten willst, ich kenne derzeit 3 Formen die man in Aufbau, Funktion und Interface unterscheiden sollte: Webpage (Text geprägt), Webstory (eher visuel) und Webapp (das Werkzeug). Die Kombination von zwei oder gar allen Formen halte ich grundsätzlich für schwierig und würde davon abraten.

Maschinenspiele

Von A nach B

Die derzeitige Situation in der Welt der Videospiele wird von Wenigen dominiert: In der Regel geistlose Spielen mit wiederkehrenden Interaktionsformen in immer gleichen Szenarien. Wir wollen Inhaltsvolles und Neuartiges in ungewöhnlichen Umgebungen erschaffen. Die Suche nach neuen Ausdrucksformen treibt uns an neue Technologien und die Vorstellung von alternativen Spielformen auf bewährten Plattformen zu erschaffen. Von Idee auf oder entlang einer Technologie, am Ende bleibt das echte Vergnügen oder die spielerische Erkenntnis.

In der ersten Phase werden wir in kürzester Zeit 3 spielbare Prototypen erstellen. Reflektierend werden wir eins oder mehrere, ganz oder in Teilen kombiniert zur vollen Reifen bringen. Das Ergebnis sollte ein kurzweiliges und neuartiges Videospielerlebniss sein und im Idealfall eine Aussage transportieren.

Eine Analyse des aktuellen Marktes gehören eben so zu unserem Vorhaben wie eine Recherche bezüglich Möglichkeiten für Festivals und Awards.

Begleitend werden wir alle Schritte in diesem Weblog dokumentieren und veröffentlichen.