Alex Leutgöb (li.) und Christian Feldbacher von V-Play

Wir haben Christian Feldbacher und Alex Leutgöb, die Entwickler der V-Play Game Engine, in ihrem Büro in Wien besucht. Die beiden erzählten uns im Interview, wie sie auf die Idee gekommen sind, eine eigene Engine zu entwickeln, über ihre Pläne für die Zukunft und – natürlich – wodurch sich ihre Engine auszeichnet. Alle Details lest ihr gleich anschließend in unserem Exklusiv-Interview!

in-ga.me: Wie seid ihr auf die Idee gekommen, eine eigene Game Engine zu entwickeln, wie habt ihr euch zusammen gefunden – wie hat das ganze angefangen?

Christian Feldbacher: ”Angefangen hat es bei mir im Master-Studium. Ich habe in Hagenberg den Mobile Computing Master gemacht und habe vorher Spiele für die unterschiedlichsten Plattformen entwickelt – Jave ME damals noch für die guten, alten Nokia Handys, Objective-C für das erste iPhone, Flash für Web-Games, Java für Android und C++ für den Desktop. Im Endeffekt brauchte man für jede einzelne Plattform eine andere Sprache. Sobald ich also ein Spiel auf eine andere Plattform portieren wollte, war es ein kompletter Re-Write. Dann habe ich gesucht, was es in die Richtung Cross-Platform Game-Development für Handys gibt – und zu der Zeit gab es da einfach noch gar nichts. Da hat es Unity noch nicht gegeben und auch sonst keine Cross-Platform Game Engine, weil einfach iPhone und Android noch so jung waren – bei Android war es dann ja auch erst später mit dem Update zu Android 1.5 möglich, den selben Code für beide Plattformen zu benutzen. Ich habe damals dann erkannt, dass es sehr große Vorteile mit sich bringt, wenn man ein Spiel und die Technik dahinter soweit abstrahiert, dass man es für mehrere Plattformen verwenden kann. Das heißt, es ist eigentlich aus Eigeninteresse entstanden. Ich habe dann begonnen, eine Game Engine zu entwickeln – über den Zeitraum von zwei Jahren im Rahmen der Master-Arbeit. Danach habe ich es dann dem Alex gezeigt; wir beide kennen uns noch aus unserer gemeinsamen Schulzeit in der HTL Braunau. Wir hatten vorher auch schon einige Projekte gemeinsam verwirklicht – nicht nur Games, sondern auch Apps auf Auftragsbasis und privat für die unterschiedlichsten Plattformen. Ich habe ihm dann also das Game Engine-Projekt gezeigt und gefragt, ob er mitarbeiten will und er war sofort dabei. Letztes Jahr im Sommer haben wir dann zu zweit gestartet und seither arbeiten wir Vollzeit daran. Die ersten fünf Monate haben wir von zu Hause aus gearbeitet; also die typischen Garagen-Entwickler – bis wir uns dann im Dezember ein Büro genommen haben.”

in-ga.me: War euch das wichtig, dass ihr nicht zu Hause arbeitet?

Alex Leutgöb: ”Wir sind ziemlich schnell draufgekommen, dass es nicht wirklich funktioniert, wenn man das ständig macht. Erstens gibt es die Trennung zwischen Zuhause und Arbeit nicht – man kann einfach nie so richtig umschalten. Es geht zwar für eine gewisse Zeit, aber auf längere Sicht ist es einfach nichts.”
Christian: ”Jetzt haben wir im Büro eine neutrale Arbeits-Fläche. Wenn man jetzt daheim ist, hat man wirklich Freizeit – natürlich auch nicht immer, aber zumindest eher als vorher. Vorher gab es eben überhaupt keine Trennung.”
Alex: ”Da hat man kein schlechtes Gewissen, wenn man bis 11 oder 12 am Abend vorm Schreibtisch sitzt, wenn es nicht die Wohnung vom anderen ist.”
Christian: ”Wir haben natürlich lange überlegt, ob es uns das wert ist, weil die Kosten für ein Büro schrecken einen doch gerade am Anfang ab. Aber es war es absolut wert; ich würde das echt jedem empfehlen. Sogar zu zweit zahlt sich das schon aus.”

in-ga.me: War desk-sharing eine Alternative?

Christian: ”Das haben wir uns auch angesehen, aber das war eigentlich teurer.”
Alex: ”Und es war von der Identifikation her auch etwas anderes, weil der Desk nicht dir gehört und man jeden Abend seine Sachen zusammenpacken und am nächsten Tag wieder auspacken muss; da ist ein Büro einfach komplett etwas anderes.”
Christian: ”Was uns da bei den meisten zusätzlich gestört hat, war, dass man nicht ganz flexibel wäre von den Zeiten her. Wir arbeiten teilweise bis tief in die Nacht oder auch am Wochenende und da war es uns natürlich wichtig, dass wir immer hinein können, wenn wir wollen und das geht bei vielen nicht. Hier haben wir wirklich die Freiheiten, die wir brauchen. Und dann geht es ja noch weiter mit Meetings zum Beispiel. Meeting-Räume sind bei solchen Sachen meist auch schwierig und kosten oft auch noch extra. Von dem her hat eigentlich alles für das Büro hier gesprochen.”

in-ga.me: Wie seid ihr eigentlich auf den Namen für die Engine gekommen?

Christian: ”V-Play, gemeinsam spielen – das drückt ja auch das Logo aus. V auch für Vienna, natürlich (lacht).”
Alex: ”Wir wollten einerseits eine Verknüpfung zum Gaming im Allgemeinen ausdrücken und andererseits eben das ‘we’ für gemeinsam spielen, gemeinsam Levels erstellen, das heißt, ich kann mich komplett mit anderen austauschen und ich kann das Spiel komplett öffnen. Und das drückt der Name eigentlich ganz gut aus.”

in-ga.me: Kommen wir doch noch einmal auf die Entstehunggeschichte der Engine zu sprechen!

Christian: ”Die hat eigentlich ja als etwas ganz Anderes angefangen, als sie jetzt ist. Zuerst ging es rein um die technologische Machbarkeit: Geht das überhaupt, dass man für mobile Plattformen eine gemeinsame Basis schaffen kann. Dann habe ich mir unterschiedlichste Frameworks angesehen und welche Lösungen es gibt, etwas auf unterschiedliche Plattformen zu bringen. Ganz am Anfang war es eigentlich ja eine 3D Game Engine für Mobile Devices, mit der Zeit haben wir dann aber gesehen, dass es gerade für 2D mehr Potenzial gibt. Unsere Engine ist auf 2D Casual Games bzw. allgemein auf 2D-Games für mobile Devices spezialisiert. Für die mobilen Devices bieten wir alles an, was man für die Entwicklung braucht. Sprich: Man hat die Payment-Anbindung etwa für In-App-Purchases oder Ads für iOS und Android mit dabei, damit man das nicht für jede Plattform extra machen muss. Zusätzlich sind Services für Analytics oder Highscore und Achievements wie zum Beispiel Game Center oder Gree integriert. Unsere Engine ist also eine große Zeitersparnis, wenn man mobile Games entwickeln will.”

in-ga.me: Was muss man können, um eure Engine verwenden zu können?

Christian: ”Java Script oder C++, es geht beides. Man kann das wählen. Der schnellere Weg ist bestimmt mit Java Script, weil man beim Entwickeln einfach schneller ist. Aber man kann auch seine C++ Kenntnisse verwenden und in die Engine integrieren, also die plattformübergreifenden Sachen von uns und den eigenen C++ Code dazu verwenden.”

in-ga.me: Das heißt, der Einstieg ist dadurch leichter?

Alex: ”Genau! Keine Pointer, keine Pointer Pointer etc., wirklich Java Script beziehungsweise eine deklarative Sprache, um die Levels, GUI und Spielobjekte zu definieren.”
Christian: ”Es war uns aber eben auch wichtig, dass die Technologie dahinter in C++ geschrieben ist – ganz einfach aus dem Grund, da in puncto Performance mit Java Script derzeit noch nicht das machbar ist, was mit C++ möglich ist. Bei unseren internen Tests hat sich gezeigt, dass Java Script ungefähr drei Mal langsamer ist als C++. Nachdem aber Performance bei Games das Wichtigste ist, vor allem bei mobilen Games, haben wir dann eben diese Lösung gewählt. Java Script ist eben super für einfache Sachen oder Logik, die nicht ständig in jedem Frame aufgerufen wird. Diese Dinge sind dann in C++ besser aufgehoben, wie es auch unsere Komponenten sind. Von dem bekommt man als JS-Entwickler aber nichts mit, weil man auf die C++-Komponenten trotzdem mit JS zugreifen kann. Das heißt, es sind sozusagen die Vorteile aus beiden Welten enthalten.”

in-ga.me: Ihr seid derzeit ja noch in der Beta-Phase. Wie funktioniert das genau, wer kann sich dafür anmelden, wer soll sich anmelden, wie viele können sich anmelden?

Alex: ”Das ist komplett offen. Wir haben kein spezielles Auswahlverfahren oder halten es künstlich zurück. Sobald man sich anmeldet, kann man es sofort herunterladen und alles ausprobieren. Es gibt hier keinerlei Hürden. Das war uns natürlich auch bewusst wichtig, weil es der einzige Weg ist, wie man schnell von anderen Entwicklern Feedback bekommen kann.”
Christian: ”Die Beta-Phase wird aber jetzt demnächst zu Ende sein, weil der Launch kurz bevor steht.”
Alex: ”Das ist dann zuerst noch eine Vor-Version…”
Christian: ”Genau, das ist dann noch nicht der finale Release, der wird im November folgen, aber es geht jetzt eine Version raus, mit der man bereits komplette Spiele für die Stores entwickeln kann. Es fehlen punktuell noch Dinge, deswegen gibt es auch noch Vergünstigungen bzw. Belohnungen für die Early Birds, wenn sie die Engine jetzt schon nehmen und nicht erst später. Vom Pricing her ist es so, dass wir keinen Revenue-Share machen, wie es andere tun. Es handelt sich also um einen Flat-Preis, mit dem man so viele Games publishen kann, wie man will.”

in-ga.me: Zahlen muss man für eure Engine ja erst dann, wenn man für iOS und Android veröffentlichen will, oder?

Alex: ”Wenn man in den Stores veröffentlichen möchte, ja. Für Desktop-Betriebssysteme kann man Spiele komplett kostenlos veröffentlichen, genau so wie für Symbian und MeeGo. Wenn man iOS, Android und in weiterer Folge Blackberry und Windows Phone 8 veröffentlichen will, dann braucht man die Lizenz. Das heißt, man kann die Engine vorher schon kostenlos testen am Desktop und auf dem lokalen Entwickler-Smartphone, und kann theoretisch sein Spiel soweit fertig entwickeln. Wenn man sich dann entschließt, dass man es veröffentlichen will, löst man die Lizenz und ist dann in den Stores draußen.”
Christian: ”Gerade auch der Weg, wie man das Game vom Computer auf das Mobile bringt, ist bei uns ziemlich einfach gelöst. Man schreibt und testet das Spiel am Desktop, kann aber jederzeit hergehen und das Projekt an unseren Build-Server schicken. Auf dem Build-Server gibt es dann einen Link, wo man das Game über einen QR-Code direkt auf das mobile Gerät installieren kann. Das heißt, man braucht nichts am Gerät installieren, man braucht kein SDK lokal installieren, man braucht nur einen Desktop-Browser und einen QR-Code Scanner am Device und kann es so auf das iPhone oder das Android zum Testen raufspielen. Und das geht eben auch mit der Gratis-Version. Sobald man das Game eben in den Apple App Store oder den Google Play Store publishen will, gibt es die Bezahl-Lizenz. Man kann also die Engine in vollem Funktionsumfang testen und probieren.”

in-ga.me: Es ist ja ein Unterschied, ob ich ein Spiel für den PC oder für Mobiles mache. Worauf muss man denn achten, wenn man zum Beispiel ein Spiel für den PC macht und dann denkt, man will es jetzt auch zum Beispiel für Android veröffentlichen?

Alex: ”Der größte Unterschied für den Entwickler ist, dass man bedenkt, dass man auf dem PC andere Eingabemöglichkeiten hat als auf den kleinen Devices. Dort ist es natürlich Touch-optimiert. Am Computer hat man die Maus und die Tastatur dazu. Von der Technologie selbst ist es bei uns wirklich so weit abstrahiert, dass man sich keine Sorgen machen muss, dass es unperformant ist, wenn man jetzt nur am Desktop entwickelt, weil wir schon sicherstellen, dass es erstens gleich aussieht und zweitens dann auch auf den mobilen Plattformen mit einer optimierten Performance läuft.”
Christian: ”Gerade das mit den unterschiedlichen Plattformen ist ein sehr wichtiges Thema. Es gibt zwei unterschiedliche Ansätze, wie man das löst: Der eine ist, dass man ein anderes GUI hat, das man darüber setzt und nur die Spiellogik gleich bleibt. Es gibt aber auch Varianten, wo man das Spiel so gut wie 1:1 auf beiden Plattformen verwendet – auf der einen Seite hat man ein Keyboard als Eingabeinstrument, auf der anderen Seite ein virtuelles Touchpad oder auch Beschleunigungssensoren. Da sind aber unsere Komponenten schon so weit abstrahiert, dass man die einfach austauschen kann. Das heißt, für die Spiellogik ist es egal, wo der Input jetzt herkommt.”
Alex: ”Wo man dann natürlich noch mitdenken muss ist der Multi-Touch, weil der am PC natürlich schwierig wird, obwohl hier auch immer mehr Notebooks am Markt auftauchen die das ermöglichen.”
Christian: ”Prinzipiell macht es natürlich eher Sinn, wenn man eine optimierte Mobile-Version macht und eine für den Desktop.”

in-ga.me: Das ist ja alleine wahrscheinlich schon wegen der Grafiken sinnvoller, oder?

Christian: ”Das ist eigentlich egal. Beim neuen iPad zum Beispiel haben wir ja auch das Problem gelöst, dass es von sehr großen Auflösungen bis zu sehr kleinen alles gibt. Man hat in unserer Engine eine ‘safe zone’ im Spiel, die auf allen Geräten vorhanden ist und man macht die Hintergrundgrafiken auf allen Seiten ein wenig größer, damit das selbe Seitenverhältnis sichergestellt ist. Weil: Verzerrt man es, schaut es schlecht aus. Da bieten wir schon Photoshop-Templates an, die man herunterladen kann, wo man das alles einpassen kann bzw. dann auch aus programmiertechnischer Sicht, wo man eine Multi-Resolution Komponente hat, die man verwendet. Da gibt man an, wie die Grafik heißt und die richtige Grafik wird reingeladen, je nachdem welche Auflösung das Device hat. Das ist auch der performanteste Weg. Es ist zum Beispiel schlecht, wenn man riesige Grafiken macht und das dann herunter rechnet, weil dann braucht man im Speicher wieder sehr viel Platz; und das ist das, was die Performance killt.”

in-ga.me: Aber Speicherplatz ist da doch bestimmt auch ein Thema, wenn ich die Grafiken in verschiedenen Größen implementiere, oder?

Alex: ”Wir haben standardmäßig drei integriert. Wenn ich zum Beispiel weiß, ich werde nur für das iPhone entwickeln und nicht für das iPad, dann kann ich von vornherein die größeren draußen lassen. Desto höher die dpi Anzahlen werden, desto größer wird das Problem allgemein in der App-Entwicklung.”
Christian: ”Das kann man bei uns eben selbst einstellen ab welcher Auflösung welche Grafik verwendet wird. Voreingestellt ist, dass es drei verschiedene Größen gibt: Eine ab 1200 Pixel in der Breite, wie etwa das neue iPad oder andere große Tablets. Darunter dann jene bis zu einer Breite von 800px, wie zum Beispiel das iPhone 4 mit 960×640. Und dann noch die ganz kleinen Auflösungen wie etwa das iPhone 3GS. Das sind die drei Kategorien, die standardmäßig verwendet werden. Das kann man dann aber eben auch beliebig costumizen, wenn zum Beispiel auf Android-Devices die kleineren Grafiken verwendet werden sollen bis zu einer gewissen dpi-Anzahl. Das ist ein sehr wichtiges Thema in Hinblick auf die Performance.”
Alex: ”Das Schöne ist eben, dass man es einstellen kann, aber nicht muss.”

Gezeigt wurde uns das anhand des Spiels “Squaby Defense”, das man auch von der V-Play Homepage herunterladen kann.

Christian: ”Von dem Spiel ist auch der Source-Code verfügbar, das heißt, man kann es selbst kompilieren für den eigenen PC oder es mit unserem Build-Server auf das eigene Smartphone raufspielen und es beliebig anpassen. Und das Spiel ist auch in den Stores.”
Alex: ”Das war uns auch in beide Richtungen wichtig. Einerseits, dass man das Spiel sofort herunterladen kann und sieht, was mit der Engine umgesetzt wurde. Eine Homepage mit statischen Bildern ist zwar schön und gut, aber als Developer will man gleich sehen, wie das performt, wie es aussieht und was man wirklich damit machen kann. Andererseits war es ein logischer Schritt, in unser SDK den Source-Code zu integrieren, damit der Developer sehen kann, wie etwas umgesetzt worden ist, worauf man aufpassen muss et cetera. Und das war einfach der perfekte Link dazu.”

in-ga.me: Wie lange habt ihr denn an dem Spiel gearbeitet?

Christian: ”Das Spiel hat eigentlich einen sehr, sehr langen Prozess hinter sich. Das hat noch in Hagenberg als Studentenprojekt begonnen, rein mit Objective-C, sprich für iOS und nur für das iPhone. Für das iPad hätten wir dann also erst recht wieder eine eigene, angepasste Version machen müssen. Das hat sich dann aber verlaufen, wie es bei Studentenprojekten eben so ist. Wir haben das dann für die Engine wieder aufgegriffen. Vom ursprünglichen Team waren dann auch noch Leute dabei, die uns geholfen haben – für das Level-Design und Balancing zum Beispiel.”
Alex: ”Im Endeffekt ist das Spiel mit drei verschiedenen Technologien umgesetzt worden. Und für uns ist es auf jeden Fall ein guter Showcase.”
Christian: ”Genau, weil es sehr viele unserer Komponenten nutzt: Es kommen Partikel-Systeme vor, Sounds, Physik-System zum Kollisionen testen…”
Alex: ”… Animation, Pfadfindung etc.”
Christian: ”Und das sind alles Komponenten, die man als Spielentwickler auch verwenden kann. Im Falle der Pfadfindung, haben wir also sozusagen ein Need für das Game dann auch in die Engine integriert.”
Alex: ”Es ist schwierig zu sagen, wie lange wir netto an dem Spiel gearbeitet haben, nachdem es uns wirklich schon das ganze Projekt hindurch verfolgt – von Anfang an.”
Christian: ”Reine Programmierzeit waren vielleicht zwei bis drei Wochen. Das beste Beispiel für die Zeitersparnis mit V-Play ist eigentlich das zweite Spiel, das wir noch in den Stores haben, das war nämlich ein Wochenend-Projekt. Wir haben uns gedacht, wir brauchen noch ein anderes Game, das wir noch in den Store reinstellen können und in kurzer Zeit machbar ist. Wir sind dann drüben gesessen beim Gockel, das ist ein Hendl-Imbiss, und haben gedacht, machen wir etwas mit einem Hendl. Im Endeffekt ist es dann das Game ‘Chicken Outbreak’ geworden. Da spielt man ein Huhn, das aus dem Hühnerstall ausbrechen will. Das Spiel war in zwei Tagen fertig – mit allen Grafiken und mit in den Store stellen für iPhone, iPad, Android-Devices, Desktop – alle Plattformen.”
Alex: ”Das Spiel war quasi schneller fertig als der Prototyp (lacht).”

in-ga.me: Und wie laufen die Spiele in den Stores?

Christian: ”Da wir dafür eigentlich null Marketing gemacht haben, dümpeln sie halt ein wenig dahin. Aber die Reviews sind durch die Bank positiv. Wir haben nur vier oder fünf Sterne für die beiden Games bekommen. Mit Squaby waren wir in 30 Ländern unter den Top 100, bei Chicken Outbreak war’s in acht Ländern.”
Alex: ”Trotz des wenigen Contents, der enthalten ist.”
Christian: ”Was aber bei Games generell derzeit ein Problem ist, ist die User Retention. Das heißt, die Leute sehen sich das Spiel an, spielen es ein oder zwei Mal und verlassen es wieder, wenn es nicht ständig neue Updates dazu gibt. Gerade für dieses Problem haben wir jetzt eine ziemlich coole Lösung gefunden. Wir bieten an, dass die Spieler selbst am Device den Content erstellen können. Für unser Tower Defense Spiel Squaby zum Beispiel wird es mit einem der nächsten Releases möglich sein, dass die Spieler selbst die Levels, den Pfad, die Hindernisse definieren und das Balancing von dem Level einstellen und das Ganze dann mit anderen sharen können. Das heißt, man kann das Level dann über Facebook sharen und bewerten lassen. Das ist ein Zusatzservice, das wir mit der Engine anbieten, weil das sehr einfach in alle Spiele integrierbar ist, die mit V-Play gemacht wurden. Im Endeffekt definiert man nur, wie es grafisch aussehen soll, wenn der User Levels erstellen kann – das ganze Technische dahinter, sprich wie geht die Speicherung im Web, wie funktioniert das Reinziehen der Entitäten zum Beispiel; das alles übernimmt die Engine. Das ist das nächste große Update, das noch kommt. Sobald das dann integriert ist, wird es auch die finale Version der Engine sein. Wir nennen das ‘Game Creation as a Game’. Man kann sogar noch einen Schritt weiter gehen und eine Art Little Big Planet für Mobiles machen: Man kann die Games selbst am Device zusammenstellen und mit anderen austauschen. Das ist nicht rein auf Content fokussiert, man kann damit auch die Spiellogik am Gerät hineinverknüpfen. Das ist natürlich auch in der Entwicklung sehr, sehr praktisch, weil es eben auch da möglich ist, einen Level direkt am Gerät zu entwerfen und direkt zu testen. Ein Game-Designer kann das dann eben direkt am Gerät designen, über das Web mit dem Entwicklerteam sharen und man kann sogar das ganze Balancing am Gerät vornehmen.”
Alex: ”Das ist dann ein wirklicher Push, weil du brauchst nicht immer neu kompilieren nach jedem Wert, den du geändert hast. Man hat wirklich nur mehr das Gerät und kann es direkt ausprobieren.”
Christian: ”Rapid Balancing sozusagen – mit dem Vorteil eben, dass man es seinen Usern auch erlauben kann; man muss nicht, man kann! Das nimmt einem den mühsamen Punkt ab, ständig neuen Content produzieren zu müssen, weil das dann eben die User machen können. Das heißt, die User haben etwas davon, weil sie mehr damit anfangen können, wenn ihnen das Spiel gefällt. Als Entwickler hat man natürlich auch etwas davon, weil man nicht den ganzen Content selbst produzieren muss und man eine Community um das Spiel aufbauen kann.”

in-ga.me: Wie funktioniert das mit der Speicherung von solchen Levels?

Christian: ”Entweder lokal – man muss es nicht sharen –, oder man shared es über das Web. Das heißt es gibt eine Art Level-Browser, in dem man sich die Levels von anderen mitsamt den Bewertungen und Kommentaren dazu anschauen kann. Das ist dann noch in Kategorien unterteilt wie zum Beispiel bereits im Spiel mitgelieferte Levels oder von mir erstellte Levels oder User-Levels.”
Alex: ”Das ganze Level-Sharing ist von uns auch serverseitig schon zur Verfügung gestellt. Im besten Fall sage ich als Entwickler dann nur mehr im Javascript, dass das am Server gespeichert werden soll.”

in-ga.me: Wie seid ihr eigentlich auf die Idee gekommen, einen Level-Editor anzubieten?

Alex: ”Ursprünglich war es die Idee, dass die komplette Game-Entwicklung ausschließlich über einen grafischen Editor ohne eine einzige Zeile Code passiert. Wir haben dann aber gemerkt, dass das die wenigsten Entwickler wirklich wollen, weil man einfach auch nicht mehr so flexibel ist. Im Endeffekt haben wir uns dafür entschieden, weil es einerseits jeder cool findet, dem man davon erzählt, und es gerne in sein Spiel einbauen würde.”
Christian: ”Und es war auch aus Eigeninteresse, weil wir selbst Levels designen mussten und man da nicht glücklich ist, wenn man das im Code machen muss. Wenn man das also grafisch machen kann und dann auch gleich noch am Device, dann ist der Level-Designer happy hoch zehn. Dann haben wir angefangen, das technisch zu abstrahieren – und im Endeffekt hat es uns jetzt auch schon Zeit gespart für das Erstellen von Levels.”
Alex: ”Aus dem Need der Game-Designer und uns selbst heraus, genau. Der nächste logische Schritt ist es dann eben, das auch den Spielern anzubieten. Am PC gibt es ja auch oft Communities von zig-tausenden Spielern bei Games, die schon lange gar nicht mehr unterstützt werden. Und die machen dann weiterhin Content oder Levels. Und wir wollen das eben auch für Mobile Games anbieten.”

in-ga.me: Kauft man eure Engine, kann man damit ja so viele Spiele machen, wie man will. Wie sieht denn das für euch aus, ihr wollt ja bestimmt davon leben!?

Alex: ”Das ist eine jährliche Lizenz, die etwa 500 Euro kostet und auf Einzelentwickler und kleinere Teams zugeschnitten ist. Darauf haben wir jetzt einmal den Fokus liegen.”
Christian: ”Genau, der erste Fokus sind jetzt einmal Indie-Entwickler und kleinere Studios. Für größere Studios würde es dann andere Lizenzen geben, weil die in der Regel andere Anforderungen haben. Die haben erstens mehrere Entwickler dran sitzen und auch meistens Interesse daran, den Source Code zu bekommen. Dafür würde es dann eine andere Lizenz geben. Das ist auch das Feedback, das wir auf der GDC von Studios bekommen haben. Die erste ist jetzt aber eben nur für Einzelentwickler und kleine Teams.”
Alex: ”Da kommt es dann natürlich auch darauf an, wie man wachsen will. Zu zweit geht sich das finanziell natürlich relativ schnell einmal aus. Wir haben aber vor, dass wir unser Team erweitern. Das heißt, wir werden dieses Jahr noch zwei Entwickler suchen und sind auch aktuell gerade auf der Suche (Anmerkung der Redaktion: hier findet ihr alle Details zur offenen Stelle bei V-Play). Und nächstes Jahr werden wir das dann natürlich auch noch weiter pushen.”

in-ga.me: Wie macht ihr denn eure Buchhaltung – alles selber?

Alex: ”Ich bin ja Wirtschaftsinformatiker, die einfachen Sachen machen wir prinzipiell selber. Für Teile der Buchhaltung der GmbH braucht man aber schon einen externen Buchhalter, spätestens wenn es zum Jahresabschluss kommt. Wir sind Startup im INiTS Inkubator in Wien, das heißt, da gibt es auch tolle Angebote für Buchhaltung oder Rechtsanwälte für die ersten zwei Jahre nach der Gründung.”
Christian: ”Dazu haben wir vor zwei Monaten die Förderung bekommen.”
Alex: ”Seit Juli sind wir offiziell ein INiTS-Projekt.”
Christian: ”Der Alex, der ja seit 2008 ein Einzelunternehmen hat, mit dem er App-Entwicklung angeboten hat, hat das bis jetzt gemacht. Da wir aber im Moment in der Gründungsphase einer GmbH sind, brauchen wir dann sowieso jemanden.”

in-ga.me: Warum keine OG?

Christian: ”Davon wurde uns abgeraten. Wir haben einige Meinungen – auch von anderen Studios – eingeholt und uns wurde die GmbH geraten, wenn man das Grundkapital aufbringen kann. Es kommt auch darauf an, ob man schnell wachsen will oder nicht.”
Alex: ”Die einzige Überlegung wäre, wenn dann, aus steuerlichen Gründen gewesen, weil man bei einer OG bis zu einem gewissen Umsatz weniger Steuern bezahlt als mit einer GmbH. Die GmbH hat aber einfach viel mehr Vorteile gegenüber einer Personengesellschaft.”
Christian: ”Und es zeigt auch ein anderes Commitment nach außen.”

in.ga.me: Was habt ihr denn marketingtechnisch geplant, um eure Engine bekannt zu machen?

Christian: ”Für unsere derzeitigen Zielgruppen – hier vor allem anfangs die Gruppe der Nokia Qt/Entwickler, da es V-Play ihnen ermöglicht, ihre Games nahezu ohne Mehraufwand auf iOS und Android zu bringen – betreiben wir neben den Pflichtaufgaben von Twitter, Mailing-Listen, Foren und Events/Conferences auch Content-Marketing, d.h. wir veröffentlichen sowohl in unserem Blog, als auch in anderen Blogs in Form von Gastartikeln Beiträge, nicht nur zu V-Play, sondern allgemein zu Themen rund um Mobile, Gaming und Entwicklung. Weiters stehen wir seit dieser Woche in enger Kooperation mit einer internationalen Agentur, die als Partner ihr Know-How für die künftige Marketingstrategie einbringt.”
Alex: ”Ansonsten dienen natürlich unsere eigenen Games und auch die unserer User als Marketinginstrument. Zum jetztigen Zeitpunkt haben wir eine dreistellige Anzahl an registrierten Beta-Usern erreicht, und es kommen ständig welche dazu.”

in-ga.me: Wie sehen denn eure Pläne für die Zukunft aus?

Alex: ”Wir wollen uns eben auf das Feature ‘Game Creation as a Game’ konzentrieren und das als USP von der Engine hervorheben und werden selbst noch ein paar Games damit umsetzen.”
Christian: ”Genau, wir machen auch eigene Games zum weiteren Push der Engine. Aber auch Kundenaufträge für Games, wo wir eben anbieten, dass die Engine verwendet wird. Wir haben dafür auch Kontakt mit Drittentwicklern, auf die wir bei Bedarf zurückgreifen können. Und das Kernteam, das an der Engine arbeitet, wollen wir eben vergrößern – und auch die Anzahl an Plattformen, die wir unterstützen. So wird zum Beispiel der Windows 8 Store sehr interessant werden, wo wir dann das ganze Payment abstrahieren werden; und auch Windows Phone 8! Auf der GDC haben wir ein Blackberry Playbook in die Hand gedrückt bekommen, das ist natürlich auch interessant.”

in-ga.me: Und Windows Phone war bisher kein Thema für euch?

Alex: ”Aus dem Grund, weil dort bisher der native Zugriff nicht erlaubt war. Das hätte für uns einfach keinen Sinn gemacht.”
Christian: ”Technisch wäre es vor Windows Phone 8 nicht gegangen, ja.”
Alex: ”Wenn die Performance nicht passt, braucht man gleich gar nicht anzufangen. Und wir hätten dann komplizierte Bridges in das bestehende Framework von Windows Phone 7 bauen müssen. Und nachdem es auch keine Updates von Windows Phone 7 auf 8 geben wird, war das bisher nicht in unserem Fokus.”
Christian: ”Windows Phone 8 wird aber auf jeden Fall interessant!”

in-ga.me: Was bedeutet das eigentlich für euch als Game Engine-Entwickler, dass sich die Betriebssysteme von mobilen Devices ständig weiterentwickeln?

Alex: ”Sie funktioniert ganz normal weiter. Das, was sich wirklich weiterentwickelt, sind die SDKs, mit denen man die Apps erstellt. Das heißt, unsere Abstraktion bleibt so, wie sie ist. Wenn es neue Features gibt, die unsere Engine nicht unterstützt, dann werden wir das natürlich nachziehen. Sollte das für einen Entwickler nicht schnell genug gehen, haben die Entwickler natürlich auch selbst die Chance, dass sie das nachziehen, indem sie es mit C++ selbst hinein programmieren – wenn jetzt zum Beispiel ein neues iPhone käme mit neuen NFC-Features und der Entwickler das sofort in sein Game einbauen will, kann er das selbst dazuprogrammieren und kann das verwenden.”
Christian: ”Dafür ist die Engine eben auch geöffnet. Sie ist also nicht geschlossen, sondern man kann seine eigenen Plattform-Plug-ins dazuhängen. Das heißt, man kann seine Android Java-Sources genau so verwenden wie Objective-C Code vom iOS. Das war eben auch etwas, was uns wichtig war, dass man als Entwickler etwas nachreichen kann, was die Engine (noch) nicht unterstützt.”
Alex: ”Was auch noch am Plan steht, ist, dass man die erstellten Komponenten für die Engine anschließend mit anderen Entwicklern über einen Komponenten-Store teilen kann. Und das wäre dann auch noch eine andere Monetarisierungs-Art für die Entwickler.”
Christian: ”Langfristig haben wir auch noch geplant, nachdem unsere Engine auf 2D ausgelegt ist und man damit sehr einfach und schnell GUIs erstellen kann, dass man nicht nur Games sondern auch normale Apps unterstützt. Nur gerade bei normalen Apps ist das eigentlich noch viel schlimmer, dass sich das SDK ständig verändert. Weil es hier fast schon normal ist, dass man die neuesten Features von einem Telefon unterstützt. Bei den Games hat man vielleicht den Beschleunigungssensor drin oder den Kompass, wenn’s was exotisches ist, und das war es dann aber. Der große Unterschied zwischen Games und Apps ist eben der, dass Games eine eigene UI haben. Das heißt, man hat keinen Button, der aussieht wie ein nativer iOS Button oder ein nativer Android Button, sondern man ist immer in seinem eigenen Grafikstil. Aus dem Grund bieten sich Games für unser Tool eben auch so gut an, weil man die 2D GUI-Elemente sehr einfach austauschen und customizen kann. Dazu liefern wir Komponenten, wie man seine Elemente anordnen will, ob man es beispielsweise in einer Spalte macht oder in einer Liste oder in einer seitlich swipe-able Liste; das nehmen wir dem Entwickler alles ab. Das sind alles Dinge, die normale Apps auch brauchen, aber die haben eben noch mehr native Sachen drin, die so aussehen wie vom Betriebssystem gewohnt.”

in-ga.me: Wie würdet ihr das lösen?

Christian: ”Wir werden dafür vorgefertigte Skins anbieten, die so aussehen wie das jeweilige GUI. Das heißt wir setzen auf die selbe Technologie von uns und stylen die Buttons so, damit sie aussehen wie echte Buttons. Derzeit haben wir es so gelöst, dass wirklich der native Dialog aufgeht, was man jetzt aber auch schon über Java Script ansprechen kann. Man sagt also einfach: Öffne das Eingabefeld mit folgendem Text und diesen Buttons… In der späteren Version kann man dann zwischen diesen beiden Varianten wählen. “

in-ga.me: Vielen Dank für das interessante Gespräch!