
Seit einigen Jahren ist die Welt der Computer*-Spiele um eine Nische reicher. Es handelt sich dabei um Spiele, die im Browser gespielt werden und daher auch den Namen „Browserspiele“ tragen. Es gibt wahrscheinlich kaum einen Internet*-Nutzer, der nicht wenigstens kurz eines dieser Spiele ausprobiert hat und somit eine ungefähre Ahnung davon hat, wie sie aussehen. In diesem Beitrag geht es jedoch nicht um das, was jeder sieht, sondern um das „Verborgene“: die Serverseite der Browserspiele.
Am Beispiel des Browserspiels „FMO“, das die Welt der Fussball Manager simuliert, stelle ich einen möglichen Systemaufbau der Browserspiele dar und gehe dabei auch auf die jeweils eingesetzten Java-Technologien ein. Auf der Client-Seite stellen die Browserspiele keine großen Anforderungen an die Hardware und Software der User. Jeder
Rechner, der über einen Browser verfügt, und das sind so gut wie alle, kann zum Spielen eingesetzt werden.
Auf der Serverseite muss das System jedoch etwas ernsteren Anforderungen genügen. Es muss mit Tausenden gleichzeitig laufenden Sitzungen umgehen können und stets eine gute Performance abliefern. Erreicht wird dies durch die Skalierung.
Die Skalierung
Die FMO-User gehören jeweils einer bestimmten Spielwelt an, die über eine eigene Hardware verfügt und auf der jeweils eine Instanz der Spiellogik, bestehend aus mehreren Modulen, läuft. Kommt eine Spielwelt an die Grenzen ihrer Leistung, so wird eine neue Spielwelt gestartet, die wiederum über ihre eigene Hardware mit der
entsprechenden Logik darauf verfügt. Auf diese Weise kann das System horizontal uneingeschränkt skalieren. Einige bestimmte Anforderungen trüben jedoch dieses perfekte Bild. Dazu gehören
- der zentral organisierte Authentifizierungsdienst
- der zentral organisierte Bezahldienst
- die Anforderung der Suchmaschinenfreundlichkeit
Um diesen Anforderungen gerecht zu werden wird ein zusätzlicher zentraler Server eingesetzt, der seine spezifischen Aufgaben mittels der entsprechenden Module erfüllt und ansonsten die ankommenden Anfragen an den jeweils zuständigen Server, für User völlig transparent, weiterleitet. Leider stellt der zentraler Server auf diese Weise einen Flaschenhals dar. Um dieses Problem zu
mildern kann jedoch ein Loadbalancer eingesetzt werden.
Die Schichten-Architektur
Das FMO-System basiert auf einer Vier-Schichten-Architektur. Die Geschäftslogik des Spiels wird in mehreren eigenständigen Komponenten abgebildet. Diese laufen als eigenständige Prozesse und
können von der Präsentationsschicht sowie anderen Geschäftskomponenten angesprochen werden. Zur Datenspeicherung nutzen sie die darunter liegende Persistenzschicht. Oberhalb der Geschäftslogik ist die WebApp-Schicht angesiedelt. Die Web-Apps bedienen die Anfragen der Web-Clients (Browser) und greift während der Verarbeitung der Anfragen auf die Dienste der Geschäftskomponenten zurück.
Schließlich ist im Browser der Spieler die vierte Schicht des Systems angesiedelt. Sie ist für die grafische Repräsentation verantwortlich und besteht aus den JavaScript- und HTML-Modulen, die
mittels der AJAX-Anfragen über HTTP mit den Web-Apps kommunizieren.
Die Java-Technologien
Die Geschäftslogik und weite Teile der Präsentations-Logik bilden den Kern des FMO-Systems. Beide Schichten sind mittels der Java-Technologien, -Frameworks und -Bibliotheken aufgebaut.
Die Komponenten der Geschäftslogik sind reine Java-Komponenten. Hier werden z.B. die Fussball-Spiele berechnet, das Training simuliert und die finanztechnischen Prozesse abgewickelt. Die nach fachlichen Gesichtspunkten gebildete Komponenten laufen als eigenständige Prozesse, nehmen Anfragen per RMI entgegen und lassen ihre Daten von der Persistenzschicht verwalten.
Die Persistenzschicht arbeitet sowohl mit dem Dateisystem als auch mit einem relationalen Datenbanksystem. Im ersten Fall werden die Daten im XML-Format gespeichert. Zur Umwandlung der in XML vorliegenden Daten zu Java-Objekten und vice versa wird die Java-Bibliothek XStream eingesetzt. Der Zugriff auf die Datenbank erfolgt per JDBC. Zur Abbildung der relationalen Daten auf der Objektebene wird außerdem auf das O/R-Tool Hibernate zurückgegriffen.
Die Web-Apps des Systems basieren auf der Servlet-Technologie* und laufen in einem Servlet-Container (Tomcat). Der Datenaustausch zwischen den beiden Teilen der Präsentationsschicht (Browser- und Web-Apps) erfolgt mittels der AJAX-Technologie. Dabei wird auf die Hilfe der JSON-RPC Bibliothek jabsorb zurückgegriffen.
Fazit
Java als Programmiersprache mit den entsprechenden Frameworks und Bibliotheken hat sich bei der Entwicklung* des Browserspiels „FMO Fussball Manager“ als eine sehr gute Wahl erwiesen. Sowohl in der Entwicklungs- als auch in der Betriebsphase konnten die Anforderungen problemlos erfüllt werden. Java kann daher zum Einsatz in den Projekten zur Entwicklung von browserbasierten Spielen bedingungslos empfohlen werden.
Steckbrief des Autors: Alexander Zent ist selbständiger Software-Entwickler. Er entwickelt und betreibt das Browserspiel FMO Fussball Manager.
Interessanter Einblick in die Browserspiele-Welt. Was mir fehlt ist eine Aussage bezüglich PHP. Werden die Browserspiele nicht hauptsächlich in PHP entwickelt. Ist Java da nicht ein wenig „overacted“?
Also ich denke die einfachen kann man auch in PHP halten, es wird mit steigender Komplexität aber sicher einfacher, auf eine Sprache wie Java umzusteigen, die mehr Möglichkeiten bietet als PHP.
Am Ende entscheidet vermutlich auch die persönliche Präferenz und das eigene Können.
Ansonsten sehe ich keine Nachteile die gegen Java sprechen würden…