Sprung ins Plattform-Chaos

 

Einleitung

Ein Geheimnis ist es sicher nicht, dass jedes Computerspiel irgendwelche Computer-Hardware (HW) braucht, um gespielt werden zu können. Die meisten Spiele benötigen darüber hinaus auch noch eine gewisse Basis-Software (SW) wie ein Betriebssystem (BS), dass auf dieser HW oder ihrem Medium vorinstalliert ist. Und dennoch besteht das traditionelle Plattform-Modell nahezu aller Videospiel-Webseiten da draußen aus einem wilden Mix von HW und SW. Man kann Konsolen wie die PlayStation direkt neben BSen wie Linux oder Windows finden, Seite an Seite mit "plattformunabhängiger" SW wie einem Browser oder gar Arcade-Boards, alle zusammengeführt zu einer einzigen Ebene von Plattformdaten. Diese Zusammenkunft der verschiedenen technischen Ansätze an einer Stelle bringt eine Reihe von Problemen mit sich, wenn es an die Dokumentation von Spieleveröffentlichungen geht.

Spieledatenbanken-News 01/2015

Dieser Blogbeitrag ist der erste in einer neuen Serie von News-Einträgen, die kurz und knackig die aktuellen Entwicklungen in der Datenbanklandschaft für Videospiele zusammenfassen sollen. Wir beobachten einige Projekte da draußen, und da erscheint es nur logisch, die ganzen Neuigkeiten an einer Stelle zu sammeln.

In den letzten Monaten haben gleich drei Datenbanken neue Meilensteine bei den "Spieleeinträgen" vermeldet: MobyGames hat 50.000 "unique games" erreicht, das taufrische Projekt IGDB vermeldete 10.000 Spiele in seiner Datenbank und die italienische Seite UVL feierte sogar 100.000 Spieleinträge mit einer kurzen Notiz. Aber bedeutet das jetzt, dass MobyGames fünfmal so erfolgreich ist wie die IGDB, und dass die UVL dafür doppelt so gut ist wie MobyGames? Natürlich nicht.

Software bei Oregami

Wir beim Oregami-Projekt setzen eine Menge Software-Produkte ein - klassische Open-Source-Tools genauso wie kommerzielle, die für Open-Source-Projekte wie uns kostenlos verfügbar sind. Dieser Blogbeitrag zeigt euch, was wir einsetzen!

Software für die Entwicklung

 

IntelliJ IDEA

Du programmierst mit Java? Dann kennst du natürlich die Eclipse IDE, die unter einer freien Lizenz verfügbar ist. Ich nutze Eclipse nun schon seit mehreren Jahren und habe mich ganz gut daran gewöhnt.

Aber irgendwie stieß ich auf IntelliJ IDEA von der Firma Jetbrains, was dort als "Die intelligenteste Java IDE" bezeichnet wird, und bin dabei hängen geblieben. Diese Entwicklungsumgebung ist zunächst nicht wirklich kostenlos erhältlich, es gibt zwar eine kostenlose "Community Edition", aber sehr viele nützliche Features sind nur in der "Ultimate Edition" verfügbar. Wer jedoch wie wir ein Open-Source-Projekt betreibt, der bekommt die Ultimate Edition kostenlos! IntelliJ IDEA gibt es für Mac, Linux und Windows.

Open Source REST Server-Anwendung (Dropwizard - Google Guice - JPA Hibernate)

Vor ziemlich genau einem Jahr habe ich mich dazu entschieden, das Java-Webframework Dropwizard für unsere Server-Anwendung einzusetzen. Seitdem habe ich viel gelesen, viel gelernt und auch Einiges in unserer Server-Anwendung implementiert. Nun stand eine Umstellung auf die neueste Dropwizard-Version an. Diese Gelegenheit habe ich dafür genutzt, Alles nochmal "von vorne" zu entwickeln, um meine Erkenntnisse über die Anwendung zu festigen. Ich möchte die komplette Implementierung dauerhaft überblicken, verstehen und gescheit dokumentieren. Das wird anderen dabei helfen, in die Entwicklung mit einzusteigen und den Code langfristig wartbar zu halten.

Um die ganzen technischen Features der Server-Anwendung für die Allgemeinheit zur Verfügung zu stellen, habe ich eine neue Anwendung erstellt, die alleinstehend und außerhalb des Oregami-Kontextes lauffähig und sinnvoll ist und eine klassische "ToDo-Applikation" darstellt. Ihr wisst schon: eine Liste von Dingen (Name, Beschreibung, Status, ...), die man noch erledigen muss.

Die Anwendung enthält momentan die folgenden technischen Features:

• REST-Anwendung basierend auf Dropwizard Version 0.7.0
• Dependency Injection mit Google Guice
• Hibernate / JPA 2.1 als Persistenz-Framework
• HSQLDB als (In-Memory-)Datenbank
• "Transaction-per-HTTP-request" mit Guice PersistentFilter
• Unterstützung für cross-origin resource sharing
• JPA Entitäten mit UUIDs als Identifikator
• Ein Muster für den Zugriff und die Manipulation von Entitäten über REST Aufrufe
  (Ressource => Service => DataAccessObject)
• Ein Muster für Service-Aufruf-Ergebnisse, welche Fehlermeldungen enthalten können, inkl. der Information, bei welchem Feld der Anwendung der Fehler aufgetreten ist. Auf diese Weise kann später in der Weboberfläche die Fehlermeldung an der richtigen Stelle eingeblendet werden.
• Durchgehende JUnit-Tests zur Absicherung der korrekten Funktionalität

In möglichst naher Zukunft sollen die folgende Dinge noch hinzugefügt werden:

• Authentifizierung
• Hypermedia mit HATEOAS
• komplexere Entitäten (1-zu-n-Beziehungen)

Der Sourcecode steht bei Github unter dem Namen dropwizard-guice-jpa-seed für jedermann zur Verfügung.

Disclaimer: Es kann natürlich sein, dass ihr Dinge findet, die man besser machen kann. In diesem Fall helft gerne mit, die Anwendung zu verbessern! Geht bei Github über die üblichen Pull-Requests. Das gilt natürlich auch für neue, noch fehlende Features!

Hinweise für Enwtickler

Die Anwendung kann gestartet werden über die Klasse "ToDoApplication" mit den Parametern "server todo.yml".

Auflisten der aktuell gespeicherten Tasks über:
GET => http://localhost:8080/task

Hinzufügen eines neuen Tasks über:
POST => http://localhost:8080/task
Header:
Content-Type:application/json
JSON-Body z.B. :
{"name" : "task 1", "description" : "This is a description"}

Modifizieren eines Tasks über:
PUT => http://localhost:8080/task/[id]
Header:
Content-Type:application/json
Accept:application/json
JSON-Body z.B.:
{
    "id": "402880944687600101468760d9ea0000",
    "version": "0",
    "name": "task 1 with new name",
    "description": "This is an updated description",
    "finished": "false"
}

Ich empfehle die Chrome-Erweiterung Postman, um solche HTTP-Aufrufe durchzuführen!

Nomen est omen: Spielenamen sind viel mehr als Schall und Rauch

Einer der regelmäßig wiederkehrenden Kritikpunkte an MobyGames - und das erstaunlicherweise  trotz all der anderen ernsthaften Schwächen des dortigen Datenmodells - ist die Bezeichnung der Spieleinträge. MobyGames ist und war natürlich auch immer schon ein US-Projekt, weswegen jedes Spiel nur mit dem Titel seiner US-Veröffentlichung als "Haupttitel" in die Datenbank aufgenommen wird. Falls es keine US-Veröffentlichung des Spieles gab, wird der Titel eines Releases in einem anderen englischsprachigen Land herangezogen. Sollte es auch eine solche Veröffentlichung nicht gegeben haben, wird schlussendlich der Originaltitel benutzt, wobei dann dessen Herkunft nicht mehr von Belang ist. Ist ein Haupttitel für das Spiel gefunden, wird jeder andere Name nur als "alternativ" in die Datenbank aufgenommen.

Es gibt ein großes Problem mit diesem Ansatz: Es könnte nämlich durchaus sein, dass der Rest der Welt sich ganz und gar nicht für den US-Veröffentlichungstitel eines Spieles interessiert. Man stelle sich beispielsweise einen japanischen MobyGames-Besucher vor, der irritiert feststellen muss, dass der vierte Teil der Final-Fantasy-Reihe dort als "Final Fantasy II" geführt wird, weil er schlicht das zweite FF-Spiel war, das in den USA veröffentlicht wurde. Bei näherem Nachdenken muss es doch einen besseren Weg der Spielbezeichnung geben, weshalb ich im folgenden Beitrag untersuchen möchte, wie andere Videospieldatenbanken dieses Problem angehen, um dann die geplante Oregami-Lösung vorzustellen. Zu Referenzzwecken werde ich immer Final Fantasy IV als Beispiel verlinken.

Englisch ist jetzt Standard

Es war schon traurig, den kürzlichen Exodus der MobyGames-Community mitansehen zu müssen, aber er hat auch viele enttäuschte Videospiel-Liebhaber auf der Suche nach einer neuen Heimat in das Oregami-Forum gespült. Wir haben nach bestem Wissen und Gewissen versucht, alle Fragen zu beantworten und alle Bedenken zu zerstreuen, die von diesen Leuten an uns herangetragen wurden. Dabei haben wir auch bemerkt, dass die Zeit für die weitere Internationalisierung von Oregami reif ist.

Vereinsgründung in Sicht

Man mag es kaum glauben, aber die ersten konkreten Überlegungen zu unserer Vereinsgründung haben wir bereits im Januar 2012 begonnen, also vor fast 20 Monaten. Und gegründet ist unser Verein immer noch nicht! Was also haben wir getrieben all diese Zeit? Und warum wollen wir eigentlich einen Verein? Ein kleiner Rückblick soll darüber Auskunft geben, außerdem wollen wir einen Ausblick auf die Zukunft wagen.

MobyGames hat sie, TheLegacy hat sie, thematisch andere Seiten haben sie auch - stets die gleichen Probleme. Aufgrund dieser Erfahrungen mit anderen Datenbankprojekten hatten wir uns relativ früh auf ein zentrales Grundprinzip für das Oregami-Projekt festgelegt: die größtmögliche Unabhängigkeit von einzelnen Personen. Dieses Prinzip sollte unbedingt auch auf die Gestaltung der rechtlichen Grundlagen angewendet werden. Die bisher üblichen rechtlichen Erscheinungsformen von Spieledatenbanken (privat, halbkommerziell, kommerziell) hatten in unseren Augen einen entscheidenden Nachteil: alle diese Projekte wurden rein rechtlich von einer Person oder Firma, höchstens von zweien betrieben, was große Fragezeichen hinter der Zukunftssicherheit der Daten zurückließ. Was würde passieren, wenn diese eine Person das Interesse verlor, wenn diese eine Firma verkauft würde oder insolvent wäre? Was geschähe dann mit diesen Projekten?