UGamela Blog

Bevor ich meinen neuen Entwurf erkläre, der übrigens auf Entwurf Nr. 2 basiert – ich habe also nicht wieder alles verworfen -, möchte ich eine Analogie voranstellen:

Anfängliches Programmieren ist wie Gartenhäuschen bauen

Gutes Pogrammieren ist wie schöne, verzierte Gartenhäuschen bauen

Professionelles Programmieren ist wie Hochhäuser bauen

Dies habe ich am Mittwoch, als ich den Uni für Einsteiger Tag in Karlruhe besucht habe, bei einem Professor für Informatik in einer Präsentation gesehen und es gefällt mir sehr gut, weil es bestens auf das Problem hinweist:

Hochhäuser sind keine großen Gartenhäuschen!

Beim Hochbau muss man noch viel mehr Statik und weitere Probleme beachten und beim Programmieren ist das nicht anders. Man kann – selbst mit gutem Code – nicht so einfach große Projekte aufziehen.

Ich lerne momentan den Hochbau und hoffe mit diesen Kenntnissen ein ansehnliches Haus hochziehen zu können. Sobald das steht, wird es wieder einfacher, die Verzierung eines Hochhauses wird wohl nicht schwieriger als das eines Gartenhäuschens und ich werde Hilfe brauchen, denn es wird viel zu tun geben.

Nun zu meinen neuen Entwurf

Wer noch den zweiten Entwurf kennt wird sich wundern, weil ich ein paar Sachen umbenannt habe. DataHandler heißt nun Service und Model Phlame, Sub oder Modul.

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/

Diagramm zum dritten Entwurf

Der Requester (mir fällt kein besserer Name ein) führt die Abfragen gegen die Datenbank aus. Zwischen den Requester und den Service wird ein Cachemechanismus mit der Session gebaut (der Requester wird dekoriert). Das sollte einige Queries einsparen. Auch das Datenbankupdate wird selbständig und querysparend vom Requester übernommen. Pro Tabelle gibt es einen Requester.  Modul-, Sub- und Phlamerequester unterscheiden sich wahrscheinlich an ein paar Stellen. Gleichzeitig dient der Requester als Spiecher für Queryschablonen für die jeweilige Tabelle. Wahrscheinlich lässt sich auch durch austauschen der Requester die Datenbank wechseln (auf PostgreSQL zB), aber vorerst habe ich nur MySQL mit mysqli vorgesehen.

Der Service wird – im Gegensatz zum Requester – vom Programmierer direkt angesprochen und ist einmalig überall verfügbar (Singleton). Er verwaltet die Instanzen eines Objektes, die im Umlauf sind, und ruft den Requester auf. Das packen der Datenarrays in Objekte geschieht im Service bzw. in der Fabrik, mit der Phlame, Sub, Modul oder einer entsprechenden abgeleiteten Klasse.

Phlame (Flamme oder Flämmchen zu deutsch^^, nicht von Belang) ist eine Vorlage für diverse Objektformen, die von dieser Klasse abgeleitet werden können. Das bedeutet sie enthält ein paar Vorgaben, wie ein solches Spielobjekt auszusehen hat. Vorgesehene Ableitungen sind Sonnensystem (auch bekannt als Planeten..) und Flotte.

Sub ist eine Untergruppierung von Phlame. Der Aufbau ist der selbe wie beim Phlame selbst, nur das der Service vom Phlame-Service oder der Fabrik aufgerufen wird, der die Subs in das Phlame schachtelt. Vorgesehene Ableitungen sind Schiffe und Gebäude.

Modul ist Sub sehr ähnlich, stellt aber nur einzelne Eigeschaften von Sub oder (weniger) Phlame dar (die Verbindung zu Phlame ist im Diagramm nicht angezeigt). Der Service wird also vom übergeordneten Service oder der übergeordneten Fabrik aufgerufen und die Module werden in das übergeordnete Objekt geschachtelt.

Resultat sollte ein ORM Schema sein. Phlames sind Objekte mit Unterobjekten, die automatisch (ohne Serialisierung) in der Datenbank gespeichert werden. Dadurch lässt sich übrigens auch weiterhin ohne die Objekte arbeiten, vor allem MySQL intern.

Benötigen tue ich dieses Schema vor allem für sehr variable Kämpfe, also Objektinteraktion und einfach freiere Modellierung der Objekte selbst und ihren Beziehungen zu anderen im Spiel.