ORM wird größtenteils den Kern meines Frameworks darstellen.

Nur, was ist ORM? [Ich meine hier übrigens nicht Objekt Role Modeling, das auch ORM abgekürzt wird]

Ich muss vorwarnen, das wird jetzt wahrscheinlich für den Großteil der Blogleser unverständlich. Es gehört wohl zu den Tiefen des Programmierens, neben den Entwurfsmuster. Oft wird hier mit Fremdwörtern nur so um sich geschmissen. Ich habe immernoch so meine Probleme, so lange mache ich das ja noch nicht. Ich werde mich trotzdem bemühen es einfach auszudrücken.

Relationale Datenbanken, wie MySQL, legen Daten in Tabellen ab. OOP arbeitet aber mit Objektinstanzen. ORM soll nun das Zwischenstück bilden, das die Objekte in der Datenbank abbildet. Ich möchte mittlerweile nurnoch mit Objekten arbeiten, es vereinfacht das Programmieren ungemein. Ich möchte vor allem Spielelemente wie Flotten als Objekte verwalten, um besser Interaktionen zu überblicken. Doch bevor man sich bei jedem Objekt mit dem Speichern in der Datenbank herumschlagen muss, möchte ich das lieber in verschiedenen (Abstraktions-)Schichten verstecken. Für die „Community-Entwickler“, die hoffentlich nach Fertigstellung des Frameworks tatkräftig mithelfen ein Spiel zustande zu bringen, bedeutet dies, dass ein Haufen Arbeit wegfällt. Dafür müssen sie sich halt mit (relativ einfachen) Klassen herumschlagen, was sie vielleicht von PHP noch nicht gewöhnt sind.

Ganz nebenbei wird dann übrigens gecacht und Race Conditions umschifft, ohne dass man etwas davon mitbekommt. OOP hat den großen Vorteil, dass man anderen Code nicht kennen muss, man muss nur wissen was er tut, und dafür gibt es die Dokumentation.

Vor ein-zwei Monaten habe ich Entwurfsmuster – in PHP – kennengelernt, obwohl ich davor schon viel früher über sie gestolpert war, hatte ich sie irgendwie nie richtig wahrgenommen oder einfach nicht verstanden.

Wenn Programmieren abstrakt ist, dann sind es Entwurfsmuster erst recht. Die Beschreibungen der Muster sind gar so abstrakt, dass man umbedingt Beispiele für die Anwendung braucht.

Auch wenn man sie leicht übersieht, stehen bereits im PHP Handbuch zwei Entwurfsmuster. Singleton und Fabrik. Ich möchte auf Singleton eingehen, hole aber noch etwas weiter aus.

Ich habe mich, als ich OOP anfing, gewundert wofür die public, protected und private Deklarationen sind und denn Sinn einfach nicht verstanden. In PHP dienen sie größtenteils gar nicht dem Programmierer selbst, sondern anderen Programmierern, die am selben Projekt schreiben. Sie schließen einfach die falsche Verwendung aus und kapseln Funktionen und Eigenschaften durch die Zugriffkontrolle. Für die Codefunktionalität sind sie somit unwichtig. Man könnte auch einfach alles public deklarieren, wenn man es trotzdem richtig verwendet (PHP4 ist noch alles public).

Singleton geht auf diesem Weg weiter, er erlaubt nur eine Instanz eines bestimmten Objektes, auf welche gleichzeitig global zugegriffen werden kann.

Das benötigt man zum Beispiel bei der Datenbank, die meist nur eine einzige Verbindung umfasst.

http://docs.php.net/manual/de/language.oop5.patterns.php

Es gibt aber noch viele andere komplexere Entwurfsmuster. Ich werde demnächst nochmal das neue Schema für mein Projekt erklären.

Entwurfsmuster zählen definitiv zur Professionellen Programmierung, das Niveau ist deutlich anders, als das simple Programmieren von einfachen Websites.

Ich weiß den genauen Geburstag nicht mehr, aber irgendwann dieser Tage hab ich mit Sascha am frisch gebackenen deutschen UGamela Forum herumgebastelt und die ersten User haben sich registriert. Zu dieser Zeit kamen auch die Versionen 0.3 und 0.3a heraus. Beide fürchterlich verbuggt und größtenteils unvollständig. Das ist nun ein Jahr her, seitdem ist viel geschehen!

Anfang Dezember habe ich das Forum neu aufgesetzt, weil ich dachte, dass wir kein PHPBBplus mit User-Sternzeichen brauchen^^. [Phlegmas Registrierungsdatum: 7.12.2007]

Danach kam noch die Version 0.4(a) raus, die Chlorel Anfang 2008 für sein XNova verwendet hat. Ich habe noch vor Jahrende den Downloadbereich gesperrt, weil 0.4a schon damals schlecht war und es nur so Bugmeldungen hagelte.

In der nachfolgenden Zeit habe ich das Release der Version 0.5 immer weiter verschoben und sehr viel dazu gelernt.

Anfang des Sommers gab es mal intern eine Version 0.4++, die irgendwie geleakt ist. Später habe ich dann „meine“ 0.5 an Sascha übergeben, der sie immernoch vertreibt, wenn auch mit wenig Andrang.

Zur Feier des Jahres habe ich eine Reihe von Themen für den Blog vorbereitet, die meine jüngsten Erkenntnisse dokumentieren und die Blogleser teilhaben lassen. Erwartet nicht zuviel, aber freuen dürft ihr euch drauf! ;D

Wieviele XNova Spiele geistern da draußen im Netz herum? Keiner außer Google weiß das genau, aber die haben ja ganz andere Probleme. Jedenfalls sind es jede Menge, täglich kommen neue dazu, täglich brechen welche zusammen.

Ich möchte das nun einmal analysieren. Dazu versuche ich mich in die Lage eines der „Kiddies“ zu versetzen, die den Großteil der vermeintlichen Spieladmins darstellen.
Danach werde ich versuchen dem Problem auf den Grund zu gehen! Weiterlesen „Ein Haufen UGamelas / XNovas“

MySQL Events gibt es schon seit MySQL 5.1, aber ich habe sie erst diese Woche entdeckt.

Meiner Meinung nach eine geniale Erfindung, weil sie mit ein wenig MySQL Kenntnissen Cronjobs ersetzen kann. Die anstehenden Änderungen müssen zwar vollständig innerhalb des MySQL und damit in der Datenbank ablaufen, sind dafür aber deutlich flexibler und verlässlicher als Cronjobs. Für mich ist die Handhabung sogar einfacher.

Diese Events eignen sich auch um einen Daemon auf MySQL Basis zu schreiben, der sehr datenbanknah arbeitet. Events werden dadurch in Echtzeit ausgeführt, anstatt, wie beim klassischen Eventhandler, bei jedem Aufruf durchgeführt und zurückberechnet. Das macht einiges deutlich einfacher.

Unheimlich.

Mein Forum scheint ausgestorben und doch wird es täglich von treuen Mitgliedern besucht. In Saschas verbleibendem Forum ist auch nicht viel los. Auf meinem Blog ist dies nun etwas Neues seit Wochen.

Gefällt mir natürlich genauso wenig wie euch! Wir haben schon November und ich bin immernoch nicht sonderlich weiter, so kommt es mir jedenfalls vor. Stattdessen denke ich darüber nach die Sprache zu wechseln (PHP+PgSQL/Python+PgSQL/Java+PgSQL), möchte aber nicht schon wieder aufgeben, was ich bereits geschafft habe.

XNova ist so aktiv wie immer, kann aber die Ruhe um UGamela nicht nutzen um einmal etwas wirklich Gescheites zustande zu bringen. Stattdessen gibt es diverse Kleinkriege zwischen Membern oder Großkriege um Copyrights – wie üblich.

Vor lauter XNova, XNova, XNOVA hört man gar nichts mehr von UGamela; kaum einer weiß überhaupt noch, dass XNova auf UGamela basiert.

Damit muss man leben.  Ich bin über meine Ruhe froh ;D

Eigentlich schreib ich ja alle paar Tage was, aber gerade passiert einfach nichts.

Ich bin schulisch sehr beschäftigt, werde aber ab Ende dieser Woche wieder etwas Zeit haben und hoffentlich ein gutes Stück weiterkommen, in einer Woche Ferien lässt sich doch einiges machen hoffe ich.

Der Entwurf der Engine steht nun, ich muss ihn nurnoch verwirklichen. Dann kommt auch noch mal ein ausführlicher Artikel und später sogar ein Tutorial wie man mit der Engine als Basis ein BG schreiben kann.

Die Phlame Engine wird natürlich weiterentwickelt, auch wenn ich dieser Tage besonders wenig Zeit habe, diese Woche schreibe ich zB zwei Arbeiten und zwei Tests in der Schule, da bleibt nicht viel Zeit für Programmieren.

Ich muss das Schema, das ich aufgestellt hatte, revidieren. Das Datahandler verliert eine seiner Rollen, das Erstellen der Models. Diese werden direkt in den Requestern gebildet um ein paar Schleifen zu sparen, und haben dadurch auch eine Bindung zu diesen, die ich nicht Cachen möchte, da die Requester eigentlich eine Erweiterung der Datenbankverwaltung darstellen, welche eine Resource ist (Resourcen kann man nicht serialisieren/cachen).

Ich habe kürzlich ein neues Forum entdeckt, das mir gefällt: http://www.galaxy-news.de

Dort habe ich ein paar ähnlich gesinnte Entwickler gefunden. Hier die erste teils „geklaute“ Idee:

Die Models erhalten Module, die entweder selbst Models (zB im Falle einer Flotte Schiffe) oder eben bestimmte Module, mehr dazu gleich.

Ich habe überlegt den Techtree in Models abzubilden, dadurch hätte man optimale Möglichkeiten an den einzelnen Einheiten herumzubasteln. Für Basisfähigkeiten oder oft Genutztes kann man in Module, wie oben beschrieben verpacken. Für die Basisfähigkeiten gibt es zudem noch eine (abstrakte) Basisklasse (zB Ship) die bestimmte Fähigkeiten bereits vorgibt oder vorraussetzt. Der Vorteil an den Modulen wäre allerdings auch noch, dass man sie vllt sogar über ein grafisches Interface im Adminbereich in bestimmte Einheiten einbauen könnte. Diese Module wären tatsächlich auch von außen modular, das heißt man könnte die Dateien einfach auch (de)installieren.

Die Idee ist gerade im Anfangsstadium, kann gut sein, dass ich dies die Tage nochmal umdenke und editiere.

Ich komme nicht umhin mich etwas lustig zu machen.

Bei XNova ist wirklich einiges los. Immerwieder kommt oder geht jemand, ein Forum stürtzt ab und/oder wird neu aufgesetzt. Andrang ist trotzdem da, weil sie immernoch den alten Müll zum Download bereitstellen. Kann ich auch verstehen, es gibt ja (noch) nichts Besseres.

Diesmal geht Dr. Isaacs, der bisher sein Forum am erfolgreichsten gehalten hatte, auch wenn ihn früher einmal ein Hackerangriff entmutigt hatte (Das bestehende WBB xnova-germany.de Forum ist schon sein zweites). Auf Wiedersehn! Fürs Erste ein Legastheniker weniger.

Ich bin gespannt, ob der Rest des Teams zusammenhält oder ob das Forum mal wieder zusammenbricht.

Ich hatte heute einen Chat mit Flousedid (hat die neue französische Seite aufgesetzt), weil ich mal wissen wollte was aus meinen Kumpel Chlorel geworden ist. Ich hatte von ihm lange nichts gehört, wahrscheinlich hat er mich blockiert weil ich ihm nicht nützlich war, keine Ahnung. Jedenfalls hat er woanders zutun und verunstaltet nichtmehr altneuen XNova-UGamela Code.

XNova-NextGen ist ja der Codename für die neue Version der Franzosen, die laut Flousedid komplett neu geschrieben wird. Ich habe gar nicht versucht rauszufinden wann sie etwa fertig werden wollen, sondern nur gefragt wieviele „gute“ Programmierer dabei wären. Auf Nachfrage von ihm sagte ich, dass ich Leute meine die besser als Chlorel seien. Darauf kam, Zitat: „mdr, 0“. Wir können also gespannt sein, was aus einem Projekt mit null guten Programmieren wird.

Ich kann leider nicht mit einer neuen Version in die Presche springen, wie ich es gerne würde. Ich bin einfach zu langsam, wenn ich – aus meiner Sicht – guten Code produzieren will. Aber es geht sicher noch viel besser.

Der DataHandler

Mich hatte schon vor dem Sommer der Gedanke interessiert die Daten innerhalb von Models(Dartstellung realer Objekte) zu verwalten. Eine Flotte oder ein Planet würde als ein entsprechendes Objekt dargestellt werden. PHP ist keine reine OOP Sprache und ich habe OOP selbst erst seit April/Mai gelernt, daher fiel mir das nicht besonders leicht.

Ich habe versucht den Artikel verständlich zu halten, setze aber ab jetzt einige Kenntnisse für das Verständnis voraus (PHP, OOP und BG Projekte). Wen das trotzdem interessiert, der muss Wissenslücken schließen. Ich kann Google empfehlen ;D

Im Mittelpunkt stand meikels Idee des Cores der alles wichtige erledigt, doch das erweist sich für mich als nicht die richtige Lösung, da man nicht immer DB, Sessions, Authentification braucht. Genau genommen braucht man Auth nur einmal, beim Login. Auth basiert auf den Sessions, aber die Sessions sind unabhängig von der Datenbank. Daher ist eine Vererbung unsinnig, selbst wenn alle einen Singleton verwenden. Core (die letzte der 4 Klassen) hatte ich dazu missbraucht irgendwelche Funktionen zu lagern, die eigentlich komplett unabhängig wären (zB die Umformatierung von Arrays in einem bestimmten Stil).

Dazu kamen Models, die jeweils selbst ihre Datenbankeinträge kontrollierten, indem sie alle von einer bestimmten Klasse abgeleitet wurden. Das Problem war die Ineffizienz. Teils wollte ich einfach mehrere Flotten mit einem Query aus der Datenbank holen.

Daher habe ich etwas neues mit einem zentralen DataHandler entworfen, der es erlaubt mehrere Flotten (oder ähnliches) gleichzeitig zu laden. Ich habe das Prinzip nirgendwo aus dem Internet abgeschrieben, aber natürlich kann es sein, dass das schonmal jemand erfunden hat…

Ich hoffe nun, dass sich keine weiteren Probleme auftun und arbeite daran das Konzept umzusetzten. Einiger Code des vorigen Konzepts lässt sich zum Glück wiederverwerten [Ich hatte das recht weit entwickelt..]!

Momentan hänge ich an einer kleinen Entscheidung: Der Datahandler verwaltet die DatenArrays und erstellt Zugriffsobjekte (Flotten, Schiffe, Planeten, etc.). Sollten die Zugriffsobjekte (aka Models) mit Referenzen auf die Arrays im DataHandler enthalten oder lieber Kopien und diese bei Zerstörung (spät. bei Scriptende) zurückgeben?

Ich mag Referenzen nicht, aber ich denke ich werde sie verwenden um zu verhindern, dass es Überschreibungen gibt, wenn man zweimal das selbe Objekt aus dem Datahandler holt, sonst müsste dieser die ausgegeben Objekte speichern… Nein das wird mir zu komplex und sonst nur fehleranfällig.

Meinungen?