Entwicklung eines Social Games auf Facebook
comment
Feature

Entwicklung eines Social Games auf Facebook

Wie das Social Game Funfari bei Gameforge entstand und welchen Herausforderungen sich Entwickler für die Plattform Facebook stellen müssen.

Making Games

@ Facebook

Making Games

@ Twitter

Die Herausforderungen an den Entwickler und Publisher bei der Entwicklung eines Facebook-Spiels sind vielfältig. Anhand des bei Gameforge entwickelten Facebook-Spiels Funfari möchten wir einige dieser Herausforderungen aufzeigen.
Funfari ist ein Aufbauspiel im Safari-Setting, bei dem der Spieler durch das Anlegen von Äckern, das Pflanzen von Bäumen und die Pflege der Tiere Erfahrungspunkte sammelt und durch Stufenaufstiege immer mehr Flora und Fauna im Shop freischaltet. Zusätzlich kann der Spieler durch Gebäude und Objekte sein Grundstück verschönern.

Das Projektmanagement
Bei der Wahl der Projektmanagement-Methode sollten Entwickler besonders auf die Art der Mitarbeiter und auf deren Wünsche achten. Wir haben Scrum auf die Gegebenheiten unseres Projekts angepasst, die für uns sinnvollsten Punkte der Methode übernommen und ein paar Aspekte an unsere Bedürfnisse angepasst. Wichtig bei der Arbeit mit einer agilen Methode ist vor allem, dass die Mitarbeiter im Team vergleichsweise eigenständig arbeiten und handeln müssen, damit eine transparente und schnelle Kommunikation gewährleistet ist und die Entwicklung ohne Reibungsverluste verlaufen kann.
Ein weiterer wichtiger Punkt -- besonders bei der Anwendung einer agilen Projektmanagement-Methode -- ist die Festlegung des Zeitraums, in dem die Sprints absolviert werden sollen. Bei Funfari haben wir die Sprintdauer auf eine Woche terminiert, was unter anderem die Flexibilität erhöhte. Während der Produktion gab es zwei Zwischen-Milestones, die den groben Entwicklungsverlauf beschrieben. Entgegen der gängigsten Methode, den Multiplayer eines Spiels zuerst zu entwickeln, wurde bei Funfari zunächst die komplette Spielwelt geschaffen und erst im zweiten Schritt die soziale Interaktion implementiert.

Tasks wurden bei der Produktion von Funfari in einem Backlog aufgeführt und nach der Sprintplanung Woche für Woche entnommen und an ein Task Board geheftet.

Das Team
Die Teamgröße und dessen Zusammensetzung sind bei der Entwicklung eines Facebook-Spiels besonders wichtig. Meistens wird bei einer Produktion auf einem sozialen Netzwerk ein großes Team sowohl für die Entwicklung als auch für den Live-Betrieb bevorzugt, damit eine schnelle Entwicklungszeit erreicht werden kann.
Im Kern-Team von Funfari befanden sich ein Product Owner, ein Scrum Master, ein Game Designer und insgesamt fünf Frontend- und Backend-Programmierer. Im Vergleich zu Angaben anderer Social Games Entwickler aus den USA, die mit 20 bis 30 Mitarbeitern ein Spiel produzieren und deren Live-Team ebenfalls in dieser Größenordnung liegt, war das Funfari Team eher überschaubar. Da alle Teammitglieder jedoch sehr erfahren und ein eingespieltes Team waren, diente die geringe Größe zum einen dem Teamgeist und zum anderen der Produktivität bei der Entwicklung. Herausforderungen und auftretende Risiken konnten dadurch schnell gelöst werden.
Die Gameforge-eigene Grafikabteilung fungierte wie ein klassischer Outsourcing Partner. Die Kommunikation für die Bestellung ganzer Grafikpakete sowie deren Abnahmen liefen dabei über den Producer, kleinere Änderungen fanden in direkter Absprache zwischen dem Game Designer und dem betreffenden Grafiker statt. Für die Soundeffekte und die Musik von Funfari wurde Dynamedion als Outsourcing-Partner gewählt.
Am Team selbst wurden während der Produktion keine Änderungen vorgenommen. Um kurze Kommunikationswege zu gewährleisten, saßen alle Beteiligten nah beieinander. Der eingesetzte Scrum Master war für die Einhaltung unseres angepassten Scrum-Prozesses verantwortlich. Darüber hinaus musste er sicherstellen, dass das Team alle benötigten Arbeitsmittel zur Verfügung hatte und vor externen Einflüssen geschützt war. Hierzu zählte vor allem, dass keine Mitarbeiter im laufenden Sprint durch weitere Anfragen abgelenkt wurden. Der Producer stellte bei der Entwicklung die einzige Schnittstelle vom Team nach außen dar und sicherte es dadurch zusätzlich ab. Die komplette Kommunikation, sowie die Überwachung und das Reporting des Projektstandes lagen in seiner Zuständigkeit. Anfragen aus dem Team an andere Abteilungen und umgekehrt liefen stets über seinen Schreibtisch, so dass der Producer immer auf dem aktuellen Wissenstand war.
Bei der Entwicklung eines Facebook-Spiels ist immer zu bedenken, dass dieses vor allem durch Updates in kleinen Zyklen nach Release weiterlebt. Aus diesem Grund wurde das während der Entwicklung eher kleine Team von Funfari nach Release aufgestockt, um wöchentliche Updates und den Live-Betrieb sicherstellen zu können.

Risiken bei der Entwicklung
Bei einer Entwicklung auf Facebook müssen zwei große Themengebiete beachtet werden: die rechtlichen und die technischen Vorgaben der Plattform. Dadurch, dass diese jederzeit vom Plattform-Betreiber (sprich: von Facebook) geändert werden können, muss hierauf besonderes Augenmerk gerichtet werden. Es bedarf also einer großen Flexibilität.
Während der Entwicklung von Funfari musste sich eine Person des Teams ständig über die aktuellen Änderungen auf der Plattform auf dem Laufenden halten, eventuelle Änderungen evaluieren und diese in die Planung mit einbeziehen.
Dies stellte eine große Herausforderung für uns dar, weil Facebook nach Abschluss unserer Pre-Production und der Festlegung unseres Zeitplans bekannt gab, dass bis Mitte 2010 einige gravierende Änderungen am Social Network vorgenommen werden sollten. Die geplanten Modifikationen waren für die Entwickler in einer Roadmap sichtbar und betrafen zum Beispiel die Benachrichtigungen. Diese wurden dahingehend umgestellt, dass der User nur noch eine Nachricht erhielt, wenn Freunde in Facebook auf eigene Kommentare antworteten -- nicht mehr aber, wenn diese dem User in einem seiner Spiele geholfen hatten. Der virale Faktor der Spiele wurde damit eingeschränkt, zugunsten einer Minderung der als Spam empfundenen Mitteilungen.
Es können aber auch technische Ausfälle seitens Facebook dafür sorgen, dass der Zeitplan durcheinander gerät. Wenn Facebook etwa gerade etwas an der API -- der Entwicklungsumgebung der Plattform -- ändert, funktionieren eventuell gewisse Features im Spiel nicht mehr oder die Applikation kann gar nicht erst erreicht werden. So kam es nach dem Release von Funfari mehrfach vor, dass die Applikation nicht aufgerufen werden konnte, was natürlich zu Unmut bei den Spielern führte.
Ein aktuell noch bei Facebook bestehendes Problem: Es können keine unterschiedlichen Berechtigungsstufen in einer Applikation bei Accounts mit Developer Status eingerichtet werden. Jeder Developer Account hat dadurch alle Rechte, womit er unter anderem die Applikation verändern, sie löschen und sie auch veröffentlichen kann. Wenn später mehrere Abteilungen an einer Applikation arbeiten, entsteht dadurch ein erhöhtes Risiko, dass ungewollt Veränderungen an der Applikation vorgenommen werden.

Testen der Applikation
Bereits nach eineinhalb Wochen der Entwicklung wurden bei Funfari Tests an der ersten existierenden Version durchgeführt. Kurz darauf wurde auch die Quality Assurance in das Testen des Spiels einbezogen. Diese Vorgehensweise hat sich als extrem hilfreich erwiesen, um die Features direkt nach der Implementierung überprüfen und eventuelle Bugs frühzeitig beheben zu können.

Zwei Konzeptzeichnungen für eine Bar und eine Maispflanze sowie die fertige Ausgestaltung der Assets.Zwei Konzeptzeichnungen für eine Bar und eine Maispflanze sowie die fertige Ausgestaltung der Assets.

Das Testen der Applikation ist allerdings problematischer als zum Beispiel bei Browserspielen. Die Applikation wird innerhalb einer Developer Umgebung auf Facebook entwickelt und kann auch nur in dieser getestet werden. Sobald die Applikation den Developer-Modus verlässt, kann sie von allen Facebook-Nutzern gefunden und gespielt werden. Dies bringt vor allem den Nachteil mit sich, dass niemals in einer richtigen Live-Umgebung getestet werden kann. Denn selbst, wenn die Applikation auf den Live-Modus umgestellt und die Facebook-Kommunikation ausgeschaltet wird, um eine zu frühe Verbreitung des Spiels zu verhindern, fehlt ein wesentlicher Test-Bestandteil: die Veröffentlichung von Nachrichten.
Bei Gameforge werden üblicherweise drei Testphasen bei der Entwicklung eines Spiels geplant -- die Alpha-Phase, in der allen Mitarbeitern von Gameforge Zugang zum Spiel gewährt wird, die geschlossene Beta-Phase mit ausgesuchten Testern und schließlich die offene Beta-Phase. Aufgrund der oben aufgeführten speziellen Umstände beim Testen einer Facebook-Applikation sowie der Tatsache, dass wir bei Funfari keinen »htaccess« vorschalten und damit allen Testpersonen die Möglichkeit geben konnten, mit einem Login zu testen, wurden sogenannte Developer Test Accounts erstellt. Dadurch haben wir einen geschlossenen Test mit Gameforge-Mitarbeitern vor Release ermöglicht. Die Erstellung ist allerdings mit sehr viel Aufwand für das Team verbunden.
Die Entwickler müssen für jede Testperson einen eigenen Facebook-Account erstellen, ihn dann mit allen anderen verknüpfen und anschließend als Entwickler einladen. Erst dann kann der Account in den Developer Modus umgestellt werden. Auch hier besteht das Risiko, dass die Tester die Applikation aus Versehen veröffentlichen, da sie ebenfalls alle Rechte besitzen.
Um die Spielinhalte und das Balancing bei Funfari ausgiebig zu testen, wären sehr viele dieser Developer Accounts nötig gewesen. Wir haben uns aus diesem Grund dazu entschieden, bereits vier Wochen vor der Alpha und dem geschlossenen Test auf Facebook eine Version für alle Mitarbeiter von Gameforge zur Verfügung zu stellen. Wir haben dies umgesetzt, indem der Client als Stand-Alone Version im Browser eingerichtet und ein htaccess vorgeschaltet wurde.

Der Screenshot eines bebauten Test-Grundstücks während der Entwicklung.

Herausforderung Server-Architektur
Auf Seiten der Technik gibt es ebenfalls einige besondere Anforderungen, die bei der Entwicklung eines Spiels auf Facebook beachtet werden sollten. So muss etwa sichergestellt werden, dass alle Spieler in einer Spielwelt miteinander agieren können. Alle Spielerdaten müssen dafür aber zentral in einer Datenbank liegen. Da eine Datenbank bei einem Spiel mit sehr hoher User-Zahl nicht ausreicht, wird eine Datenbank-Struktur benötigt, bei der mehrere Datenbanken genutzt und später einfach weitere hinzugefügt werden können. Hierfür haben wir bei Funfari den »DBSelector« geschaffen. Er entscheidet, in welcher Datenbank neue User angelegt und bestehende User gespeichert werden, und auch welcher Cache verwendet werden soll.
Wenn der Server nun die Daten eines Users lesen will, fragt er zunächst den DBSelector nach den Zugangsdaten der Datenbank bzw. des Caches. Basierend auf den Zugangsdaten versucht der Server, zunächst die Daten aus dem Cache zu lesen. Wenn diese Anfrage scheitert, befragt er die Datenbank und schreibt die gelesenen Daten für einen späteren Zugriff erneut in den Cache.
Da es nur eine »Einsprungs-URL« pro Applikation bei Facebook gibt, müssen die Anfragen der User über einen Load Balancer auf eine Web-Server-Farm verteilt werden. Aus technischen Grüden kann es nur einen Load Balancer geben und dieser kann auch nur innerhalb seiner Region auf Webserver routen. Aus diesem Grund mussten wir uns im Falle von Funfari für eine Master-Region entscheiden. Dieser Umstand bringt mit sich, dass Nutzer aus der Master-Region eine eher niedrige Latenz zum Load Balancer, zur Webseite und zum Game-Server haben, während Nutzer außerhalb der Master Region eine verhältnismäßig hohe Latenz in Kauf nehmen müssen.
Die hohe Latenz zum Game-Server außerhalb der Master-Region kann allerdings dadurch umgangen werden, dass dem Flash-Client bei Auslieferung an den Nutzer die Adresse eines Game-Servers aus seiner Region mitgegeben wird. Nachdem der Flash-Client das erste Mal beim Aufruf der Webseite ausgeliefert wurde, erfolgt die Kommunikation zwischen dem Flash-Client und dem Web-Server direkt und nicht mehr über den Load Balancer.

Gameforge lokalisiert seine Spiele in mehr als 50 Sprachen und bietet spezielle Bezahlmethoden für alle lokalisierten Länder an.

Tool-Anbindung
Auch die Anbindung an die Gameforge Tools wurde bei Funfari durch die veränderte Server-Architektur beeinträchtigt. Gameforge hat während der Entwicklung seiner Browserspiele eigene Tools für Lokalisierung, Data Tracking und das Payment-System aufgesetzt, an die jedes Spiel angebunden wird. Auf diese Weise können wir einerseits eine möglichst schnelle Lokalisierung eines Spiels in viele unterschiedliche Sprachen gewährleisten und zum anderen die Bereitstellung der regionsspezifischen Bezahl-Methoden in jedem Land sicherstellen. Die Anbindung an Funfari wurde deshalb zunächst mit derselben hausinternen Schnittstelle geplant, die auch schon für die bisherigen internen Projekte genutzt worden war. Dabei trat jedoch das Problem auf, dass durch unsere veränderte Server-Architektur auch Änderungen an dieser Anbindung hätten erfolgen müssen. Für externe Projekte hatte Gameforge aber bereits eine neue zentrale Schnittstelle entwickelt, die wir dann auch bei Funfari einsetzen konnten. So mussten wir die alte nicht mit zusätzlichem Aufwand an unsere Bedürfnisse anpassen.

Die Grafik bei Funfari
Die Grafik ist eine der USPs von Funfari. Dementsprechend hoch wurde sie bei der Entwicklung priorisiert. Schon früh in der Produktion erreichte die Grafik einen finalen Status, und durch wöchentlich abgehaltene Präsentations-Meetings, in denen direktes Feedback vom Team eingeholt wurde, konnten die Iterationszyklen kompakt gehalten werden. Ein Hauptaugenmerk bei der visuellen Gestaltung des Spiels lag auf den »Key-Märkten«, in denen Funfari veröffentlicht werden sollte. Da es sich neben Deutschland dabei vor allem um den US-amerikanischen Markt handelte, wurde hier eng mit Experten in Übersee zusammengearbeitet, die entsprechenden Input zum Look des Spiels beisteuerten. Insbesondere die freundliche, helle, strahlende Farbgebung sowie der Disney-ähnliche Comic-Stil kamen bei den Tests mit den amerikanischen Beratern von Anfang an sehr gut an. Einzig die Augen der Avatare durchliefen mehre Iterationsschritte bis zum finalen Design.

Der Disney-ähnliche Comicstil wurde sehr bewusst gewählt, um neben den deutschen Spielern auch die amerikanischen Facebook-User anzusprechen.

Das Marketing auf Facebook
Eine Marketing-Methode, die sich als sehr erfolgreich herausgestellt hat, ist Cross-Promotion. Sobald der Entwickler oder der Publisher viele seiner Spiele zusammen in einer Leiste nahe des Spielscreens einbindet, ist die Wahrscheinlichkeit sehr hoch, dass sich Spieler der aktiven Applikation auch weitere desselben Anbieters ansehen werden. Daneben sind auch Verlinkungen innerhalb der Spiele erfolgversprechend. Ein Beispiel hierfür ist die Belohnung des Users für eine Leistung, die er in einem anderen Spiel erbracht hat. Wenn der User in Spiel »X« Level 10 erreicht, erhält er in Spiel »Y« den besonderen Gegenstand »Z«. Diese Methode ist allerdings nur möglich, wenn bereits mehrere Spiele erfolgreich auf einer Plattform platziert sind.
Auf einer Plattform wie Facebook ist allerdings problematisch, dass der virale Teil des Spielkonzepts von vielen Usern als Spam angesehen wird. Jede Applikation auf Facebook beinhaltet die »Veröffentlichen«-Funktion, mit der erreichte Spielstände oder die Ergebnisse ausgewerteter Fragebögen auf der Pinnwand platziert werden können. Darüber hinaus ist es in vielen Spielen möglich, Freunde einzuladen oder ihnen Gegenstände zu schenken. Viele User blockieren die Applikationen im Anschluss, um diese von ihnen als Spam empfundene Funktion einzugrenzen. Sobald ein User sich allerdings zu einem solchen Schritt entschließt, ist er für den Entwickler und Publisher quasi nicht mehr erreichbar und damit als Kunde praktisch verloren.
Aus diesem Grund haben wir bei der Entwicklung des Konzepts von Funfari von Beginn an darauf geachtet, Funktionen zur viralen Verbreitung in einem gesunden Maß ins Spiel zu integrieren.

Lessons learned

  • Eine agile Projektmanagement-Methode bietet Flexibilität und kann individuell angepasst werden. Bei Funfari haben wir Scrum erfolgreich auf die Bedürfnisse des Teams und des Projekts angepasst und damit gute Erfahrungen gemacht.
  • Wenn wir im Laufe der Entwicklung feststellen mussten, dass ein Prozess nicht funktioniert, haben wir ihn angepasst und nicht einfach beibehalten, nur weil er zu Beginn der Produktion einmal festgelegt wurde.
  • Die Größe des Entwicklungs-Teams bei einem Spiel für eine Plattform wie Facebook ist weit weniger relevant als die Größe des Live-Teams. Während ein kleines Entwicklungs-Team ein Spiel wie Funfari in überschaubarer Zeit entwickeln kann, benötigt man unter Umständen ein weit größeres Live-Team, um Feature- und Content-Updates, die das Spiel weiter aufbauen und am Leben halten, in kurzen Zyklen ausliefern zu können.
  • Die Entwicklungszeit ist auf Plattformen wie Facebook meist deutlich geringer als bei anderen Plattformen (Konsolen, PC, Browser). Dies liegt vor allem daran, dass ein Spiel bereits released wird, sobald das Grundgerüst steht. Das Spiel wird danach durch Updates des Entwicklers weiterentwickelt.
  • Ein Producer als einzige Schnittstelle vom Team nach außen gewährleistet die Überwachung während der gesamten Produktion und dient als zentraler Ansprechpartner für beide Seiten. Er erleichtert damit die Kommunikation und hat von allen Seiten Überblick über den Projektstand.
  • Bei der Wahl des Grafikstils haben wir großes Augenmerk darauf gelegt, dass dieser kompatibel mit dem Geschmack der Spieler in den entsprechenden Zielmärkten ist.
  • Es lohnt sich, bereits innerhalb der Pre-Production intensiv über die Server-Architektur nachzudenken und diese schnellstmöglich festzulegen.
  • Die rechtlichen und technischen Vorgaben von Facebook müssen vor der Entwicklung untersucht und mit in die Konzeption einbezogen werden. Sehr wichtig ist, dass sich eine einzelne Person während der gesamten Entwicklung und auch nach Release laufend darüber informiert, ob Änderungen an diesen Vorgaben geplant sind.
  • Der Entwickler muss immer damit rechnen, dass Änderungen an der Plattform vorgenommen werden. Dementsprechend sollte er mehr Pufferzeiten einplanen.
  • Die Möglichkeiten für Marketing sind auf Facebook eingeschränkt. Dieses Manko muss durch Cross-Promotion oder virale Verbreitung des Spiels ausgeglichen werden. Hierbei sollte darauf geachtet werden, dass die virale Verbreitung vom User nicht als Spam empfunden wird.
  • Das Testen einer Applikation in Facebook ist nur mit Einschränkungen möglich. Eine Applikation kann nie ganz unter realen Bedingungen getestet werden, ohne dass sie veröffentlicht wird. Weiterhin muss ein hoher Zeitaufwand für die Erstellung von Test-Accounts eingerechnet werden.



Eine Entwicklung auf Facebook bringt eine gewisse Abhängigkeit von der Plattform mit sich, gepaart mit nicht zu unterschätzende Risiken und Herausforderungen. Diese lassen sich aber von einem gut eingespielten Team lösen, besonders wenn Änderungen an Facebook aufmerksam und konsequent verfolgt werden und die Gesamtplanung entsprechend Spielraum für Flexibilität lässt.
Thomas Rudin, Janette Lipinski

Janette Lipinski
ist Producer bei Gameforge.

Janette ist nach ihrem Abitur als Tester beim Publisher 10Tacle Studios in die Games Branche eingestiegen und hat unter anderem an Jack Keane und Codename: Panzers - Cold War gearbeitet. Danach wechselte sie zu Rocketscience Games Development und war dort als QA Lead und Projektmanager unter anderem an der Entwicklung von Emergency Rescue und Element Girls beteiligt. Seit 2009 arbeitet sie als Producer bei Gameforge und hat Funfari während der Entwicklung in dieser Rolle betreut.

Thomas Rudin
ist Team- und Projektleiter bei Gameforge.

Thomas hat an der Universität Karlsruhe Informatik studiert. Seit 2007 arbeitet er bei Gameforge als Entwickler, Team- und Projektleiter. Er begleitet seit Beginn der Entwicklung von Funfari das Projekt als Projektleiter und ist nach Release für die Weiterentwicklung des Produkts verantwortlich.