Die Entstehung von daWindci
comment
Feature

Die Entstehung von daWindci


Mimimi Productions hat den schwierigen Sprung vom Studententeam zum kommerziellen Entwickler geschafft. Dominik Abé und Johannes Roth geben detaillierte Einblicke in die technisch anspruchsvolle Entwicklung des preisgekrönten Spiels daWindci für iPhone und iPad.

Making Games

@ Facebook

Making Games

@ Twitter

Mimimi Productions ist ein studentisches Team, das sich im Zuge des Game-Design-Studiums an der Mediadesign Hochschule 2008 in München zusammengefunden hat. Seitdem entwickeln wir gemeinsam Spiele in Gruppenstärken von fünf bis zwölf Personen. Unser Erstlingswerk »Grounded« erhielt 2009 den Deutschen Entwicklerpreis in der Kategorie Newcomer Award und war im darauffolgenden Jahr für den Deutschen Computerspielpreis nominiert. Das zweite Projekt »daWindci« konnte diese Erfolge wiederholen und hat sich als unser erstes kommerzielles Produkt auch auf dem Markt bewiesen: Für mehrere Tage standen wir auf Platz 1 im deutschen iPad-App-Store als meistverkaufte App und umsatzstärkstes Spiel. Auf diesen Werdegang und die technischen wie organisatorischen Herausforderungen wollen wir im Folgenden genauer eingehen.

Das iPhone- und iPad-Spiel daWindci wurde von einem Studententeam der Mediadesign Hochschule München entwickelt und hat unter anderem den Deutschen Entwicklerpreis abgeräumt.

Der Werdegang einer Idee
Die schon seit 2009 bestehende Grundidee von daWindci ist schnell erklärt: Der Spieler übernimmt die Kontrolle über das Wetter. Er beschwört Winde, Wirbelstürme und Regenwolken herauf. Ziel ist es, einen Heißluftballon – durch den geschickten Einsatz dieser Kräfte – indirekt zu dirigieren und unversehrt ins Ziel zu manövrieren. Die Kamera zeigt die Welt dabei in einer Vogelperspektive. Das Konzept wurde zuerst in Form eines 2D-Flash-Prototypen (siehe Abbildung 1) getestet und entpuppte sich schnell als innovative Abwandlung des klassischen Scroll-Shooter-Genres. Nach der Entwicklung von Grounded beschlossen wir, uns in eine 3D-Engine einzuarbeiten und setzten einen PC-Prototypen in der 3D Engine von Unity um (siehe Abbildung 2). Als wir das Ergebnis 2010 auf der gamescom präsentierten, hätte das Feedback der Branche und Spieler kaum besser ausfallen können: Der aquarell-artige Grafikstil gekoppelt, die entspannte Musikuntermalung von Filippo Beck Peccoz sowie Spielidee und -mechanik kamen fantastisch an. Schnell wurde aber auch klar, dass das Eingabegerät Maus für die verwendete Gestensteuerung eine zu große Barriere darstellte. Nicht selten verursachte dies Frustmomente und folglich gab man uns häufig die Empfehlung, daWindci doch auf einem Touch-Gerät umzusetzen.

Abbildung 1: Die allererste Umsetzung von daWindci orientierte sich stark am Stil der berühmten Zeichnungen von Leonardo da Vinci.

Es wird ernst
Basierend auf den Rückmeldungen machten wir uns kurze Zeit später Gedanken über eine Umsetzung für das iPad. Eine erste Überschlagsrechnung ergab allerdings ein Investitionsbudget von circa 15.000 Euro für Hardware und Software, das wir privat nicht tragen konnten. Mit dem Prototyp hatten wir allerdings den Entwickler Reality Twist derart überzeugen können, dass uns dieser als Publisher mit Arbeitsplätzen und den dringend benötigten Geräten und Lizenzen ausstattete. Weil wir mit dem Spiel auch etwas verdienen wollten, mussten wir die Teamgröße auf maximal fünf Personen begrenzen. Nach einem studieninternen Bewerbungsverfahren fanden wir zwei Artists (Florian Smolka und Lucas Reiner), die einen komplett neuen Stil – der Qualität und Effizienz unter einen Hut bringen musste – entwerfen und umsetzten (siehe Abbildung 3). Immer parallel zum Vollzeitstudium verlief dann die Arbeit an der iOS-Version von daWindci, gipfelnd im Release am 14. April 2011.

Abbildung 2: Auf dem PC konnte die 2.5D-Darstellung durch Shadereffekte wie Schärfentiefe und Bewegungsunschärfe qualitativ hochwertig umgesetzt werden.

Von Äpfeln und Birnen
Ein witziges Detail der Entstehungsgeschichte ist mit Sicherheit die Tatsache, dass kein einziges Teammitglied ein mobiles Gerät von Apple besaß. Der ein oder andere hegte sogar eine starke Abneigung gegen die riesige Firma. Trotzdem war ein Release im App Store der einzig realistische Weg. Die Geräte sind mit ihrer Auslegung auf Gesten- und Touchsteuerung wie für daWindci gemacht und der Markt ist verglichen zu anderen Veröffentlichungsmethoden leicht zugänglich (was aufgrund der Überflutung durch schnell produzierte und billige Apps oft auch als Nachteil betrachtet werden kann). Wenn man sich an die gegebenen Richtlinien hält, kann man sein Produkt zügig veröffentlichen. Außerdem war es mit der eingesetzten Engine möglich, für iPhone, iPod und iPad zu entwickeln (siehe Abbildung 4) – so konnten wir Fragmente des PC-Prototypen weiterverwenden und mussten nicht bei Null anfangen.

Für das iOS setzten Florian Smolka und Lukas Reiner einen markanten und individuellen, aber auch effizienten Grafikstil um.

Gestensteuerung: Striche treffen Kreise
Das Bedienungskonzept von daWindci ist eines der stärksten und wichtigsten Features. Der Spieler steuert nicht wie in den meisten Spielen direkt einen Avatar, indem er diesem genaue Anweisungen gibt, sondern beherrscht das Wetter, mit dem er wiederum die Spielwelt beeinflusst. Ein Wind wird erzeugt, in dem man mit dem Finger über den Touchscreen fährt. An der entsprechenden Stelle entsteht ein Windstoß und bläst getroffene Gegenstände davon. Die Bewegung – also ein mit dem Finger gerichteter Stoß – überträgt sich eins zu eins in die Spielwelt. Die Barriere zwischen Rezipient und Medium wird nahezu aufgelöst und nicht wie bei vielen anderen Touchscreen-Applikationen verstärkt, in denen Interface-Elemente wie Joysticks als zusätzliche extramodale Schnittstelle dienen. Der Bildschirm wird nicht durch zusätzliche Grafiken verdeckt und die ganze Oberfläche des Touchscreens kann und muss als Eingabefläche genutzt werden.
Die Stärke eines Windes ist abhängig von der Geschwindigkeit der Fingerbewegung. Sie wird durch die Distanz zwischen den Eingabepositionen in Spielweltkoordinaten berechnet. Dadurch entstand aber das Problem, dass die Nutzer aufgrund der unterschiedlichen Bildschirmgrößen von iPhone und iPad bei einer identischen Handbewegung andere Windstärken erreichen. Eine alternative Berechnung mit der real zurückgelegten Distanz löste diese Problematik auch nicht, weil man trotzdem auf einer kleineren Fläche einen gleich großen Ausschnitt des Spiels sieht und entsprechend kürzere Bewegungen machen muss. Die Beschleunigung und das Auf- und Absetzen des Fingers verhält sich aber nicht proportional zur Länge der Bewegung. Der richtige Faktor für ein gutes Spielgefühl auf beiden Geräten wurde letztlich empirisch ermittelt.

Abbildung 4: Dank Unity-3D-Engine läuft daWindci, hier in der Alpha-Version, auf dem iPhone, iPod und iPad.

Probleme mit dem Tornado
Ein weiteres Feature ist der Tornado, der durch das Malen eines Kreises entsteht. Die Bewegung des Spielers wird wiederum bestmöglich als Element in der Spielwelt dargestellt. Die effiziente Erkennung der Kreisbewegung stellte sich am Anfang problematisch dar, wurde aber durch Optimierungen am Erkennungsalgorithmus behoben. Die größere Schwierigkeit war und ist das Kommunizieren der genauen Geste an den Spieler. Ein Tornado entsteht, wenn man den Finger auf den Bildschirm drückt, einen oder mehrere Kreise malt und dann loslässt. Zu Fehlerkennungen und unerwartetem Verhalten führen unter anderem:

  • Es wird nur eine halbe bis dreiviertel Umdrehung ausgeführt.
  • Es werden mehrere Kreise ohne Unterbrechung gemalt, weil erwartet wird, dass ein Tornado direkt entsteht. Wenn der Spieler dann loslässt, entspricht das gemalte Endergebnis nicht mehr einem wirklichen Kreis.
  • Auf älteren Geräten, bei denen die Framerate gelegentlich einbricht, werden die Bewegungen so schnell ausgeführt, dass zu wenige Informationen über die Fingerpositionen gespeichert werden können.


Weil daWindci möglichst wenig Text enthalten und der Spielfluss nicht unterbrochen werden sollte, wurde dem Spieler das Malen des Kreises nur durch die Kombination eines Bildes und eines sehr kurzen Textes, die in die Spielwelt integriert wurde, beigebracht. Dies hat sich im Nachhinein leider als ungenügend erwiesen. Der sehr gute und empfehlenswerte Vortrag »Tales From Red Steel 2: How Motion Control Will / Won't Save Us All« von Jason VandenBerghe beleuchtet dieses Thema und die Problematik von der Vermittlung der Gestensteuerung genau. Die verbesserte Version des Algorithmus, der nun auch Kreisbewegungen ohne Loslassen erkennt, erscheint mit dem nächsten Update. Weitere Gesten, wie sie im ursprünglichen Prototyp enthalten waren, wurde nicht in die iOS-Version übernommen, weil sie weniger intuitiv waren und den Spielfluss ausbremsten.

Mehr Hürden als gedacht: Unity und iOS in der Praxis
Mit der Unity-Engine kann man – laut Hersteller – in nur einem Klick bestehende Projekte für PC, Mac, Browser, Konsolen, iOS und Android portieren. So ganz richtig ist das im Falle für iOS allerdings nicht: Zum einen gibt es nachvollziehbare technische Einschränkungen, weil mobile Plattformen deutlich leistungsschwächer als ein PC sind. Zum anderen benötigt man einen (nicht unbedingt günstigen) Mac mit Apple Betriebssystem, auf dem die Engine und eine aktuelle Version von XCode (einer Entwicklungsumgebung für Objective C) installiert sind. Auch die zwingende Mitgliedschaft im Apple-Developer-Programm, die mit 100 Dollar im Jahr zu Buche schlägt, verhindert mit der teils mehrere Wochen andauernden Registrierungsphase sicherlich eine zügige Portierung. Es ergeben sich also gleich mehrere Probleme: Teammitglieder müssen mit der eventuell unvertrauten Benutzeroberfläche des Macs erst einmal zurechtkommen, was zu Effizienzproblemen und Fehlern führen kann. XCode ist zudem ein sehr instabiles Programm, das nicht nur uns durch viele Abstürze Nerven gekostet hat. Das Installieren einer Testversion kann zudem schnell zur Geduldsprobe werden, weil der Kopiervorgang über das USB-Kabel extrem langsam ist. Konkurrenzprodukte wie das Unreal Development Kit ermöglichen es zum Beispiel, Spiele auch direkt am PC für iOS zu entwickeln – ein unserer Meinung nach immenser Vorteil. Glücklicherweise ist es mit Unity aber auch möglich, mit einem PC am selben Projekt zu arbeiten und die gemachten Änderungen via Versionskontrollsystem zu verteilen, was fast immer reibungslos läuft. Es muss dennoch ganz klar sein, dass ein bestehendes Projekt nicht einfach zu einer »App« werden kann. Neben den inhaltlichen Anpassungen des Konzepts auf die neue Geräteklasse, müssen auch die Zeit für Optimierungen und das Kennenlernen der hinzukommenden Software wie XCode beachtet werden. Wenn man die Einstiegshürden gemeistert hat und mit der »neuen Welt« vertraut genug ist, kann man allerdings effizient entwickeln. Die folgende Liste nennt die größten Probleme, die wir bei Arbeit mit der Unity-3D-Engine für iOS sehen:

  • Ohne Optimierung verbraucht Unity schnell sehr viel Arbeitsspeicher, die Apps stürzen dann unvorhergesehen ab. Es ist daher wichtig, möglichst früh mit der Überwachung der Applikation zur Laufzeit (mittels geeignetem Profiler) zu beginnen.
  • Apps, die größer als 20 Megabyte sind, können nur mit WLAN oder via iTunes am PC / Mac heruntergeladen werden. Das kann besonders beim iPhone eine Minderung des Verkaufserfolges darstellen. Weil allein die Unity Executable bei vollem Funktionsumfang schon bis zu 14 Megabyte verbraucht (also nur der Engine-Teil, ohne Inhalt), muss auch hier von Anfang an überprüft werden, ob eine Überschreitung der Dateigröße überhaupt vermeidbar ist.
  • Neuere iOS-Geräte unterstützen mit OpenGL ES 2.0 auch aufwendige Shader. Unity ermöglicht es zwar, diese Schnittstelle zu verwenden und dann tolle Effekte umzusetzen, aber die Performance leidet extrem darunter. Das ist selbst dann der Fall, wenn man keine neuen Effekte hinzufügt. Eine Testversion von daWindci für OpenGL ES 1.1 erreicht bis zu 60 FPS, während eine unveränderte Version unter Verwendung von OpenGL ES 2.0 unspielbar vor sich hin ruckelt. Das Problem liegt bei Unity: Mit den letzten Updates wurde zwar stark nachgebessert, aber trotzdem bleibt die Performance kritisch beim Einsatz der neueren Schnittstelle.

Die Physik: Wie der Apfel effizienter fällt
In daWindci gibt es sehr viele Physik- und Kollisionsobjekte, wie zum Beispiel sich biegende Bäume, Hausdächer und Berge mit geometriegenauen Hüllkörpern. Seit Unity 3.0 kann man anhand eines Flag-Layersystems festlegen, welche Objekte mit welchen kollidieren und interagieren. So können durch geschicktes Planen und Abwägen viele Physikobjekte verwendet werden. Zum Beispiel können fliegende Objekte mit Bäumen kollidieren und diese leicht umbiegen. Untereinander reagieren Bäume nicht auf Kollision: Wird ein Baum also soweit verbogen, dass er einen anderen umbiegen würde, ignoriert er dies. Der Fall tritt sehr selten ein und lässt sich verschmerzen, denn ohne die Optimierung wäre das ganze Feature wegen seines relativ hohen Leistungsverbrauchs nicht ins Spiel integriert worden.
Das Unity Triggersystem, das Teil des Physiksystems ist, benutzt dieselben Layer. Ein Trigger ist ein Kollisionsobjekt, das bei Berührung mit einem anderen Trigger eine Methode in seinen angehängten Skripten aufruft. In diesem Fall verhindert die Layer-Maske, in der die Layerbeziehungen kodiert sind, viele unnötige Überprüfungen und Aufrufe. Bei daWindci wurde das System noch weiter genutzt: Zum Beispiel ist eine Todeszone nur noch ein simpler Trigger auf einem bestimmten Layer ohne jegliches Skript. Ein Objekt, das mit einem »Todes-Layer«-Objekt kollidiert, muss beim Aufruf der Trigger-Methode nur den Layer-Index überprüfen, um zu wissen, wie es reagieren soll. Dies ist ein einfacher Integer-Vergleich. Es ist nicht mehr nötig, ein Skript zu suchen und den Datentyp der Klasse zu überprüfen. Weil solche Operationen sonst sehr häufig stattfinden würden, haben wir durch diese Optimierung sehr viel Rechenleistung gespart. Im Falle der Todeszone handelt sich es noch um ein sehr triviales Beispiel, die Technik wurde aber auch bei vielen anderen und komplexeren Features, wie zum Beispiel dem Hakensystem, benutzt. Der größte Nachteil des Layer-Systems ist, dass die Layer-Maske nur auf 32-Bit (Integer) basiert – es sind also nicht mehr als 32 unterschiedliche Layer verwendbar. Für unser Projekt waren zum Glück schon 31 Layer ausreichend, wobei sieben intern von Unity verwendet werden.

Abbildung 5: Schatten passen sich an den Untergrund an und werden nicht über den Objekten in der Luft gerendert.

Optimierung der Schatten
Bei einem Spiel mit fliegenden Objekten sind Schatten sehr wichtig, da sonst kaum Höhenbeziehungen wahrgenommen werden können. Echtzeitschatten werden in Unity generell nicht für iPhone- und iPad-Spiele unterstützt, weil deren Berechnung das Erreichen einer akzeptablen Framerate verhindern würde. Eine gängige Darstellungsalternative sind sogenannte Blob Shadows, die mit Hilfe von Projektionstechniken verwirklicht werden. Es handelt sich hierbei meist um Projektoren, die gezielt nur mit den 3D-Modellen verknüpft werden, die einen Schatten werfen sollen. Dann wird eine Textur auf alle sich unterhalb befindenden Elemente projiziert. Die Projektionsziele müssen ein weiteres Mal gerendert werden, was häufig zu einem sehr starken Leistungsverbrauch führt.
Diese Technik konnten wir im Fall von daWindci nicht verwenden, weil viele Objekte gleichzeitig auf viele unterschiedliche Modelle Schatten werfen. Deshalb wird bei uns die Darstellung durch texturierte Planes realisiert, die sich mit Hilfe von Raycasts an die Höhe des Untergrundes anpassen. Der Trick dabei ist, dass die sich am Boden befindenden Modelle als erstes gerendert werden. Danach werden die Schatten – ohne Testen und Schreiben des Z-Buffers (einem Verfahren zur Berechnung von Verdeckungen) – gerendert und erst im letzten Schritt all die Modelle, die sich in der Luft befinden. Alle Schattenwürfe können somit in einem einzigen Render-Aufruf dargestellt werden. Die Raycasts, die die richtige Höhe ermitteln, müssen auch nur bei sich gerade bewegenden Gegenständen und nicht für jeden Frame berechnet werden. Diese Vorgehensweise ließ sich natürlich nur umsetzen, weil sich die Kamera immer in der Vogelperspektive befindet. Aus einem anderen Winkel und in Ausnahmesituationen fallen die Tricksereien auf. Berge sind eine große Besonderheit, weil zum einen der untere Teil Schatten empfangen und der obere Teil diese andererseits verdecken muss. Die Berge mussten also horizontal geteilt werden und einmal vor und einmal nach den Schatten gerendert werden. Abbildung 5 und 6 illustrieren dieses System und dessen Ausnahmen.

Abbildung 6: Der Schattenwurf aus einer anderen Perspektive: Verdeckte Schatten werden über Berge »drübergerendert«, aber der roten Linie verdecken die Berge wieder. Diese Perspektive kommt so nicht im Spiel vor.


Level up: Experience +4
Einer der wichtigsten Abschnitte bei der Entwicklung ist die Zeit nach der Veröffentlichung. Reviews und Kundenfeedback sind nicht nur extrem spannend, sondern auch eine wichtige Grundlage, um das eigene Produkt zu verbessern. Der App Store fördert und belohnt nachträgliche Patches und inhaltliche Nachreichungen sogar: Ein aktualisiertes Spiel wird nicht nur für ehemalige Käufer gesondert markiert, sondern hat auch die Chance, dadurch in Kategorien wie »Topaktuell« zu erscheinen, was häufig zu einer Vervielfachung der Verkäufe führen kann. Daraus folgt, dass die Produktpflege den Lebenszyklus in vielen Fällen deutlich verlängert und von vornherein mit eingeplant werden sollte.
Obwohl daWindci mehrfach zum Spiel der Woche in verschiedenen Ländern und von vielen Spielern sehr gelobt wurde, haben wir natürlich auch einige Fehler und Erfahrungen gemacht, aus denen wir viel gelernt haben. Auf die wichtigsten wollen wir an dieser Stelle noch eingehen.

Umfang
daWindci beinhaltet 45 komplexe Levels und erreicht damit eine Spielzeit von durchschnittlich fünf Stunden. Kein Review hat diesen Umfang bisher als besonders positiv hervorgehoben: Der App-Store-Kunde ist teils mehrere hundert Levels gewohnt, die dann aber jeweils nur wenige Sekunden andauern (siehe z. B. »Cut the Rope«). Mit der Zahl »45« ist also nicht zu punkten, zumal der Großteil der Spieler statistisch betrachtet anfangs nur bis etwa Level 15 spielt (Abbildung 7). Erst nach einiger Zeit steigen die Spielfortschritte – lange, nachdem die erste Meinung gebildet wurde. Strategisch schlauer wäre es gewesen, nur 20 Levels zu veröffentlichen und danach kostenlose Updates mit neuen Inhalten anzubieten. Unter diesen Gesichtspunkten ist es noch fataler, dass wir zwar sehr viele unterschiedliche Features integriert haben – von Schwebeminen bis hin zu riesigen Magneten, diese aber nicht »beworben« werden und teilweise erst sehr spät vorkommen: Der Spieler weiß also unter Umständen nicht einmal von deren Existenz.

Preispolitik im App Store
Der Käufer nimmt es einem natürlich sehr übel, wenn er sich hintergangen fühlt. Leider haben wir unsere erste Preissenkung zur Einführung von daWindci ungünstig kommuniziert, weil diese auch als »Osteraktion« gekennzeichnet war. Als dann am Ostersonntag eine weitere Vergünstigung als kleines Dankeschön für das gute Feedback startete, ernteten wir zahlreiche negative Kundenrezensionen, in denen »irreführender Preispolitik« die Rede war. Die Reaktionen sind nachvollziehbar und nicht mehr zu korrigieren, was uns im Nachhinein natürlich sehr ärgert.

Abbildung 7: Mit »nur« 45 Levels lässt sich ein Spiel im App Store lediglich schwierig bewerben, zumal der Kunde häufig gerade einmal 15 davon spielt. Besser wäre es gewesen, erst nach und nach neue Kapitel per In App Purchase anzubieten.

Balancing bei Zeitlimits
Wenn man ein Level abschließt, erhält man bis zu drei Sterne für unterschiedliche Leistungen. Neben dem Einsammeln von versteckten Gegenständen und dem schadensfreien Ankommen im Ziel wird auch eine besonders schnelle Spielzeit belohnt. Keine dieser Auszeichnungen ist wirklich wichtig, weil man sich mit den erarbeiteten Sternen letztlich nur neue Ballon-Muster kaufen kann. Unterbietet man die (durch uns festgelegte) Zielzeit nicht, erscheint allerdings die Nachricht »Zeit: Zu Langsam« – was offenbar einen enormen Druck auf die Spieler ausübt, die das Level danach wiederholen und schließlich frustriert aufgeben (Abbildung 8). Auch viele Reviews erwähnten die nicht zu schaffenden und viel zu schwierigen Zeiten, die eigentlich für Hardcore-Gamer als Herausforderung gedacht waren. Als Reaktion darauf haben wir die Zeiten leicht erhöht und zeigen nun einfach die Differenzzeit statt der demotivierenden Wortmitteilung an.

Abbildung 8: Zwei Worte mit großer Wirkung: Obwohl für den Fortschritt irrelevant, wurden Spieler durch die Mitteilung »Zu langsam« demotiviert.

Werbung und Reviews
Das beste Spiel der Welt wird sich nicht verkaufen, wenn niemand davon gehört hat. An den richtigen Stellen Werbung zu schalten, Review-Seiten zu kontaktieren und Pressemitteilungen zu verschicken, ist keine einfache Aufgabe. Gerade als junges Team fehlen hier Erfahrung und vor allem auch Zeit. Zudem ist der iOS-Markt in dieser Hinsicht häufig nicht mit den bisher üblicheren Märkten zu vergleichen. An dieser Stelle wollen wir uns gesondert bei der Unterstützung durch unseren Publisher und die Mittelpunkt Media GmbH bedanken, die sehr viel Arbeit und Mühe in die Promotion von daWindci gesteckt haben.

Bis zum nächsten Mal!
Die Entwicklung von daWindci war für uns eine der anstrengendsten und zugleich schönsten Zeiten als Team. Der Schritt vom Spaßprojekt hin zur kommerziellen Entwicklung wurde durch viele Hürden erschwert, die wir mal besser und mal schlechter gemeistert haben. Am Ende steht aber tatsächlich ein Produkt, das sich auch aus finanziellen Gesichtspunkten schon etwas bezahlt gemacht hat – und die eigens gesteckten Anforderungen sogar überbieten kann. Die gesammelte Erfahrung und der Erfolg geben uns Recht, dass es sich immer lohnt, die eigenen Ziele zu verfolgen und sich nicht durch Probleme oder Schwarzmalerei entmutigen zu lassen!
Dominik Abé, Johannes Roth

Dominik Abé
ist Game Director bei Mimimi Productions.

Dominik hat an der Mediadesign Hochschule in München Game Design studiert und hatte die Grundidee zum Geschicklichkeitsspiel daWindci. Er kümmerte sich während der Entwicklung vor allem um das Game Design und die Programmierung des iPhone- und iPad-Titels.

Johannes Roth
ist Geschäftsführer bei Mimimi Productions.

Johannes hat ebenfalls Game Design an der Mediadesign Hochschle in München studiert. 2008 gründete er das Team »Mimimi Productions« und war für die Projektplanung, das Management und für die Programmierung zuständig.