Sep 26
Phlame Engine: Der Entwurf (Nr.2)
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?
September 26th, 2008 at 22:58
„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.“
Widerspricht sich das? In LW setz ich das schon seit Längerem so um und habe damit nicht im geringsten Probleme 😉
mfG Big Mäc
September 27th, 2008 at 01:01
Huhu,
erstmal zum Artikel: Sehr gut geschrieben und nen dicker Pluspunkt für die Grafik. Das du Kenntnisse vorraussetzt ist vollkommen ok. In meinem Blog zum Beispiel schreibe ich allgemein. Wer technisch visiert ist, ist nur bedingt richtig. So soll und kann es hier auch sein!
Zu der Idee: Ich habe mich nicht viel mit OOP beschäftigt, aber da komme ich gerade noch mit. Ich würde eigl fast immer die Serverschonendere Methode wählen, da viele openSource BrowserGames zwar klein sind – Aber auch dementsprechend schlechte (Free)Server haben.
Eine direkte Antwort auf die Frage gebe ich nicht, weil ich es viel spannender finde deiner Entwicklung zuzuschauen. Ich bin gespannt und freue mich auf weitere Ergebnisse 🙂
September 27th, 2008 at 12:36
@Big Mäc:
Der Satz ist nicht eindeutig, aber eig. widerspricht sich das nicht…
Ihr habt Models bei LW? Interessant. Dann muss sich einiges getan haben. Das, was ich damals vom Code gesehn hatte, sah mehr nach nem an WBB angepantschtes UGamela(0.2x) aus.
@Marius:
Hm. Ja deinen bewertenden Stil von deinem Blog hast du mitgebracht. Gefällt mir nicht so, obwohl es nett ist ein bischen Feedback zu bekommen.
Ja das ist klar.. natürlich will man Performance sparen. Nur fragt sich, wie man sie am besten spart..! Wie ich in meinem Artikel über OOP geschrieben habe, musste ich auch dabei abwiegen. Ich gebe einen kleinen Batzen Performance dafür weg, dass es nachher um einiges erweiterbarer ist und sich auch besser von „Laien“ verändern lässt.
Du gibst keine Antwort, weil du keine weißt, aber mitreden willst du..
Gespannt sind viele, seit Anfang des Jahres. Mein Drang dies fertig zu bringen wird auch immer stärker, aber es geht nunmal nicht so schnell – schon gar nicht allein.
—
Ich hoffe das war jetzt nicht zu hart.. Ich warte immernoch auf jemanden der wirklich Ahnung hat von Browsergames und zufällig Lust hat eines OS zu machen … -.-
September 27th, 2008 at 13:39
„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?“
Was spricht dagegen, die Daten direkt in den jeweiligen Objekten abzulegen? So behälst du eine Sinnvolle Struktur (in jedem Objekt das was dazu gehört), ansonsten würde der Datahandler schnell unübersichtlich werden und ist von überall abhängig.
September 27th, 2008 at 13:46
Das hatte ich ja zuerst geplant. Allerdings stört mich daran, dass ich die Daten für ein Objekt einzeln oder unübersichtlich abrufen muss. Beispiel KS: 3 Flotten gegen 2 Flotten und einen Planeten. (3×2)+(2×2)+(1×2)=12 Queries [2Queries für Flotte/Planet siehe Tabellenumstrukturierung]. Mit DataHandler: (1×2)+(1×2)=4 Queries [Und das noch abgesehn von den Schadenssummen Queries].
Dazu wollte ich ein Caching-Organ. Zudem ist nun die Trennung zwischen Datenverwaltung und Spiellogik stärker.
Oder meinst du damit, dass du für die Kopien bist?
September 27th, 2008 at 13:57
Ja, Referenzen sind zu unsauber und zu unkontrollierbar. Aber zu deiner Queryberechnung: Falls du den Objekten einen etwas dynamischeren Konstruktor verpasst, sodass keine Queries mehr gemacht werden müssen sondern direkt die Daten übergeben werden können, könntest du zb. in der Klasse „KS“ ein Query machen und während du es „fetchst“, die jeweiligen Objekte mit den Daten erzeugen.
September 27th, 2008 at 14:06
Jup. Genau das hatte ich vor. Ich hätte halt Referenzen übergeben, aber ich denke es ist sowieso besser die ganzen Objekte auch nochmal im DataHandler zwischenzuspeichern (dann kann er verhindern, dass zwei gleiche Objekte mit den selben Daten erzeugt werden). Die Model Objekte werden dann gekapselt und bekommen eine abstrakte Klasse von der sie abgeleitet werden, die bereits die Vorgaben für die Verbindung mit dem DataHandler enthält.
In etwa:
function __construct(DataHandler $dh, $data)
{
$this->dh = $dh;
$this->data = $data;
// #
}
Ich würde dann noch einzelne (zB Schiffs-)Eigenschaften referenzieren:
#: $this->shield &= $this->data[’shield‘]
Das macht das Anprechen einfacher, zudem sind das ja wirklich die Eigenschaften. $data und $shield etc. sind natürlich protected.
function __destruct()
{
$this->dh->retrivedata($this->data);
}
…
September 27th, 2008 at 14:37
Pleghma, wenn es mir nur ums mitreden gehen würde hätte ich den unteren Abschnitt des Kommentars weg gelassen – Hier schreiben momentan Programmierern von diversen Spielen. Wenn du dich an „uns“ orientierst hast du bald einen Mix aus Ur-Zeit-UGamela und anderen Umsetzungen, aber nichs eigenes. Ist nicht böse gemeint und wie gesagt, ich freu mich auf deine Entscheidung dies bezüglich und hoffe und du schreibst darüber.
Und mein bewertender Stil.. versuch es loszuwerden, wenn einmal angeeignet. Ausserdem hilft es schnell und verständlich auf den Punkt zu kommen..
lg
Marius
September 27th, 2008 at 15:12
Oh nein ich orientiere mich nicht an euch, keine Angst. Aber ich suche immernoch Leute die mir vielleicht helfen können, vielleicht mehr von Programmieren verstehen und mich in die richtigen Bahnen leiten.
nichtwahr meikel? aka unknown^^
Oktober 1st, 2008 at 22:32
*auf neuen Beitrag wart*
und Nein, ich bin nicht Meikel xD
Da Ugamela OpenSource ist könntest du ja mal paar Codeausschnitte zeigen. Ich denke das würde dir am meisten helfen (und mich/uns am meisten interessieren).
Oktober 1st, 2008 at 22:38
Nun. Ich präsentiere ungern halb- oder einfach unfertige Sachen. Wenn ich jetzt Code zeigen würde, müsste ich weitere zusammenhängende Teile zeigen die nicht fertig sind. Das ist zum Großteil alles immernoch nur ein Entwurf. Besonders die Models sind quasi noch gar nicht geschrieben.
Ich habe *einen* (abstrakten) Requester fertig oder zumindest glaube ich zur Zeit, dass er fertig ist. Gerade hantiere ich an den Session für oder im DataHandler selbst.
Oktober 1st, 2008 at 22:46
Grad der Entwurf muss stimmen, damit das Ganze danach auch stimmt. Anfangs kann man Änderungen noch leicht integrieren, im Laufe der Zeit wird dies jedoch immer aufwändiger. Außerdem könntest du dein Blog immer schön „frisch“ halten mit aktuellen Codeausschnitten.
Oktober 1st, 2008 at 23:03
Uh. Zeig mir bitte einen Blog mit Codeausschnitten. Ich hab keine Ahnung, wie ich das machen soll. Trotz Kapselung sind die Classen einfach zu sehr ineinander verflochten. Ich kann höchstens solche Artikel wie den über die Fleetverdoppelung und Race Conditions machen. Aber eigentlich wollte ich sowieso mehr bei einer Konzeptsprache bleiben, verstehen auch einfach mehr Leute. Obwohl ich nicht weiß an wen ich mich eigentlich richten soll/will.
Oktober 1st, 2008 at 23:09
Hast du was dagegen mir mal eine aktuelle Version von deinem Entwurf im ICQ zu schicken (398-154-925)?
November 22nd, 2008 at 14:29
[…] Ich bitte nun die, die nicht den zweiten Entwurf kennen, einen Blick darauf zu werfen, damit ich diesen Teil nicht wiederholen muss. http://ugamela-blog.pheelgood.net/2008/09/26/phlame-engine-der-entwurf-nr2/ […]