Feb23
Aktuell entwickle ich für das Zeitgeist-Framework Erweiterungen der Nutzerklassen, damit sich Benutzer nicht nur über ihre internen, von Zeitgeist verwalteten, Nutzeraccounts anmelden können, sondern auch per Facebook oder Twitter. Die Facebook-Klasse gibt es (als Versuchsballon und Proof-of-Concept) schon eine ganze Weile, neu hinzugekommen ist nun Twitter.
Ziel war es, dass der Entwickler die Wahl hat, welche Logins er den Benutzern anbieten kann. Er kann entweder vollständig auf eine Plattform setzen (intern oder Facebook oder Twitter) oder auf mehrere gleichzeitig. Das Login via externer Plattform soll transparent über der internen Nutzerverwaltung liegen, so dass sich an den Nutzerklassen, sowie am Rollen- und Rechtemodell nicht ändert.
Der Ablauf ist dabei für Facebook und Twitter gleich:
- Login des Benutzers auf der externen Plattform. Dabei wird die jeweilige Authentifizierungs-API genutzt
- Wenn der Login erfolgreich war, wird die Unique-ID des Benutzers auf der Plattform ausgelesen
- Falls die Plattform-Id noch nicht im System bekannt ist, wird sie gespeichert und mit einem dazugehörigen Zeitgeist-Nutzer verbunden
- Falls kein zugehöriger Zeitgeist-Nutzer gefunden wird, wird einer automatisch angelegt. Eventuell benötigte Nutzerdaten werden aus der externen Plattform ausgelesen und für den Benutzer gespeichert
- An den Zeitgeist-Nutzer können wie gewohnt Rechte und / oder Rollen gebunden werden
Im Moment funktionieren die beiden Klassen wie gewollt. Allerdings werde ich die “Work in Progress”-Tags erst entfernen, wenn die beiden Klassen in einem echten Projekt getestet wurden.
Feb16
In meinem Artikel über das Zeitgeist Gamesystem-Modul habe ich etwas mehr über die Klasse zur Datenhaltung (gamedata.class.php) geschrieben. Diese ist in Zeitgeist angelehnt an die Datenhaltung eines Entity-Systems. In den Kommentaren wurde mir von Gameplorer folgende Frage zu dem Prinzip gestellt:
Wie gut eignet sich das tatsächlich für Browsergames? Durch die component_data_N – Tabellen ist es ja nicht mehr möglich, effektiv mit Joins zu arbeiten. Dadurch muss ich aber pro Entity zig Queries absetzen (jede component_data – Tabelle) was auf die Performance schlägt. Für z.B. einen Kampf müssten dann auch noch mehrere Entities geladen werden. Das klingt für mich nach einem absoluten NoGo in einem Browsergame.
Mir kam die Artikelreihe daher eher vor, als wäre ES für Clientbasierte-Spiele ausgelegt.
Das ist eine gute Frage, da sie auf einem verbreiten Mißverständnis beruht wie Entity Systeme funktionieren. Es werden (wenn richtig implementiert) kaum Joins benötigt, da keine Notwendigkeit besteht die kompletten Entites zu laden (geschweige denn mehrere). Das Missverständnis beruht wohl auf dem Versuch sich Entity Systeme wie klassisch objektorientierte Systeme vorzustellen, in denen das System über die Objektklassen immer (mehr oder weniger direkten) Zugriff auf alle Daten des Objekts hat. Mir ging es nicht anders und ich brauchte einige Anläufe, um mich davon zu lösen.
Hier also mein Versuch zu erklären, wie ich Entity Systeme verstehe und wie sie in Zeitgeist implementiert wurden.
Weiterlesen »
Feb13
Zeitgeist hatte, obwohl als Framework für Spiele konzipiert, lange Zeit keine eigenen Funktionalitäten die speziell für Spiele ausgelegt sind. Wenn man genauer nachdenkt sind viele Anforderungen an ein PBBG genau die Selben wie für alle anderen Webanwendungen:
- Verwaltung der Nutzer und deren Daten
- Ein Eventhandler zur Ablaufsteuerung
- Konfigurationsmanagement für die Applikation, Sprachen usw.
- Sicherheit und Fehlerbehandlung
Doch welche Eigenschaften und Funktionalitäten brauchen Spiele, die sich nicht aus einem allgemeinen Framework für Webapplikationen ergeben?
Weiterlesen »
