Entwicklung eines Social Games auf Facebook

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.

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.

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.

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.