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.

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.

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?

Bei einem PHP Apache Server agieren ständig mehrere Threads, Scripte oder System (wie auch immer man sie nennen will) gleichzeitig. Jedes Mal wenn ein User einen Script aufruft (quasi immer wenn er irgendwo draufdrückt), wird ein neuer Thread für ihn gebildet, dieser läuft parallel zu den anderen.

Ein BG (Browsergame) wie UGamela hat – wie Viele gar nicht wissen – eine komplexe Spiellogik im Inneren, welche bei bisherigen Versionen nur hingemurkst wurde. Beispiel siehe Fusionskraftwerkbug.

Ein weiteres Problem stellt die insgesamt schlechte Programmierung und somit unnötig und zu lange Berechnungszeit der Scripte dar, je länger der zeitliche Abstand zwischen dem SQL Select Befehl und dem SQL Update Befehl, desto höher die Wahrscheinlichkeit, dass es zu einem Race Condition bedingten Fehler kommt.

Häufigster bekannter Fehler dieser Art ist das Problem der Flottenverdoppelung!

Problemlösung ist in diesem Fall wirklich nicht so einfach, vor allem wenn man nicht noch längere Berechnungszeiten und somit irgendwann Wartezeiten für die User riskieren will.

MySQL stellt dafür einen Befehl bereit, der eine ganze Tabelle sperrt (“LOCK TABLE `xx`”) – anstehende Queries warten. Für die ganze Tabelle!! Dh letztendlich für alle Threads, dabei ist gar nicht klar, ob sich die Queries überhaupt überschneiden. Bei größeren Userzahlen gleichzeitig wird das dann wirklich spaßig, wenn die Wartezeiten immer länger werden.

Interessanter wäre es doch die einzelnen Einträge zu Sperren. Doch dies ist mit einigem Aufwand verbunden, weil ich aus Performancegründen benötigte Daten in einem Rutsch laden will (zB die Planeten des Spielers gleichzeitig). Dennoch soll es tief im Grundgerüst verankert werden, sodass letztlich der Modder keine Ahnung davon haben muss. Er schreibt höchstens sein spezielles “WHERE” im SQL Select Befehl.

Hier ein kleiner Einblick:

PREPARE wtnu FROM ‘SELECT `used` INTO @used FROM `?pre”.$table.”` WHERE “.$where.” ‘
oder PREPARE wtnu FROM ‘SELECT SUM(`used`) AS @used FROM `?pre”.$table.”` WHERE “.$where.” ‘

CREATE PROCEDURE wtnu ()
COMMENT ‘wait till not used’
BEGIN
wloop: LOOP
EXECUTE wtnu;
IF @used <= 0 THEN
LEAVE wloop;
END IF;
SLEEP(0.3);
ITERATE wloop;
END LOOP wloop;
END|

1. Query vorbereiten (kommt auf ein oder mehrere Einträge an)
2. Die gezeigt Prozedur aufrufen:
2.1. Vorbereitetes Query aufrufen
2.2. Testen, ob der/die Eintrag/Einträge in Benutzung “used” sind.
- wenn ja, warten.. die Schleife beginnt bei 2.1 von neuem.
- wenn nein verlasse die Schleife

Ich muss noch etwas daran feilen, ich weiß noch nicht wie ich das Session Caching miteinbinde und ob die Abfrage für mehrere “used” schon das Wahre ist (ein SUM [Summe] Befehl überprüft ob die Einträge zusammen nicht mehr als 0 sind, “used” kann 0 oder 1 sein).

Zuerst wollte ich ein dreidimensionales System aufbauen, welches von der Berechnung nicht ultimativ schwerer gewesen wäre, aber eindeutig unübersichtlicher und unhandlicher bzw schwierig darzustellen wäre.

Die Wahl fällt so auf ein zweidimensionales System, welches man auch in einem Bild darstellen könnte.

Distanz im kartesischen X,Y Koordinatensystem nach Pythagoras = Wurzel( (X2-X1)^2 + (Y2-Y1)^2)

Allerdings gibt es im Universum sehr viel leeren Raum, das heißt um ein möglichst realistisches Spiel zu erzeugen müssen die Koordinaten der System auseinander driften, die Zahlen werden schnell sehr groß und unübersichtlich. Dagegen werde ich eine dritte Koordinate verwenden, die die anderen zwei klein hält.

Aus (1005|3009) wird (AC|5|9) [A=1000, ..]. Ob ich noch zusätzlich eine Koordinate für den Planeten im Sonnensystem hinzufüge, bin ich mir noch nicht im Klaren.

Interessant für die kurzen Strecke wäre auch noch die Planetenbewegung, die wohl eine weitere Variable benötigt (wär ja langweilig wenn alle Planeten die selbe Position in ihrer Umlaufbahn hätten…).

Langsam wird mir das zu schwierig schriftlich, Bilder wären nicht schlecht, aber ich bin kein Genie mit Bildbearbeitung (das würde nur peinlich werden…).

Zusammenfassend würde ich sagen werden Koordinaten bald so aussehen: (AB,1,2,3) und vllt wird ein versteckter Faktor die Position in der Umlaufbahn variieren.

Danke an DGLDevil für ein paar Denkanstöße ;D

Update:

Nach längeren Überlegungen rund um die Logik der Distanzen im Universum habe ich mich nun entschieden, mich von den einzelnen Planeten abzuwenden. Es ist einfach unlogisch, dass 15 Planeten in einem Sonnensystem bewohnt sind, vor allem von verschiedenen Spielern bzw Rassen.

Statdessen wird man ganze Sonnensystem bewohnen, die dann noch weitaus mehr Eigenschaftern besitzen als ein Planet könnte (Eine Gasmine auf dem nächstgelegenen Gasplanet?). Das Sonnensystem bekommt drei Koordinaten: X,Y und eine dritte die, wie bereits beschrieben, die beiden anderen etwas reduziert, und gleichzeitig eine Galaxiekennung darstellt

Auch wenn dies einige Rechenarbeit ersparen würde, möchte ich das ändern. Zudem finde ich man sollte Geschwindigkeiten etwas variabler machen.

Beispiel Auto: Autos haben einen variablen Benzinverbrauch, und natürlich sind nicht alle gleich schnell. Am sparsamsten sind Autos wenn man mit ihnen nicht zu schnell und auch nicht zu langsam fährt. Vom sich wiederholenden Anfahren in der Stadt ganz zu schweigen.

Nun sagen wir jedes Schiff besitzt eine “beste” Geschwindigkeit und eine maximale Geschwindigkeit. Ich würde sagen wenn das Schiff nicht “beste” Geschwindigkeit fliegt, dann verändert sich der Treibstoffverbrauch mit einem schwachen Exponenten.

Interessant wird noch der Fall des Kampfes, bei dem möglicherweise mitfliegende Tankschiffe zerstört werden. Was macht dann die verbleibende Flotte, die nicht mehr genug Sprit zum heimfliegen hat (Weil dieser nicht schon komplett am Anfang abgezogen wurde…)? Zuerst mal auf die durchschnittlich “beste” (effizienteste) Geschwindigkeit umschalten. Wenn das nicht reicht werden sie wohl irgendwo im Raum ein anfliegbares Gebilde bilden müssen (könnte man theoretisch mit einer Art Planeten- bzw Objekteintrag realisieren).

Die Geschwindikeit wird übrigens wie Angriffs- und Verteidigungswerte nicht mehr variabel an den zugehörigen Ressourcen hängen (Wieso sollten beim Techen gleichzeitig alle Schiffe ausgebaut werden?). Vielmehr kann man dann bei seiner Flotte auf >Aufrüsten< klicken, und muss dafür wieder Ressourcen zahlen. Sogar ein Bauteillager wäre denkbar.

Mich wundert das noch niemand den Fusionskraftwerkbug bemerkt und ernst genommen hat. Er bedingt einige Funktionalitäten auf die ich nicht verzichten möchte:

Gebäude mit starkem “Resourcendrain” (hoher Verbrauch, höher als die Produktion ist) oder eine sehr knappe Ressource die von bestimmten Gebäuden verbraucht wird.

Beispiele:
AMmine/Ultramine: Verbraucht AntiMaterie (das nur sehr wenig bis gar nicht produziert wird) und produziert große Mengen von Energie und als Abfallprodukt Aluminium und Silicium… (gut noch etwas gesponnen sollte aber nur ein Beispiel sein)

Rohstoffwandler: Dieses Gebäude verwandelt Dunkle Masse (die man nur auf Expeditionen findet) langsam in ein Aluminium/Silicium-Gemisch um (Über einen gewissen Zeitraum).

Betanken eines Schiffes: Man lässt eine Extra-Resssorte den Tank herunterzählen (leichter als ein variables Limit einzurichten)  – Energiebetankung/Laden von Batterien?.

Erklärung des Bugs:
Die Ressberechnung basiert auf dem einfachen Prinzip Produktion (Rohstoff durch Zeit) mal Zeit ergibt Rohstoff. Problematisch wird dies allerdings wenn bestimmte Grenzen erreicht werden. Besonders die untere Grenze wird bisher nicht berücksichtigt, weil die Produktion eigentlich immer positiv ist. Wer den Bug beobachten will, der baue einfach mal das Fusionskraftwerk so weit aus wie möglich, stelle seinen Deutextraktor auf Null und das Kraftwerk auf volle Power. Spannend wird es wenn 0 Deuterium oder weniger erreicht wird (MinusDeut?!).

Um dieses doch etwas komplexere Probleme zu lösen hatte ich zuerst eine Klasse in PHP geschrieben, habe mich dann aber von meikel überzeugen lassen, dass es besser wäre das in SQL zu lösen. Nachdem ich irgendwann mein Argument, dass das mit SQL gar nicht möglich wäre aufgeben musste habe ich es in MySQL geschrieben. Dadurch ist der Script weit statischer (versch. Ress-/Energiesorten), doch man kann den Script ja vor dem speichern in der Datenbank durch PHP jagen, welches dann die vierte und fünfte Resssorte hinzufügt, die der Admin gerne hätte…

Als ich das geschafft hatte habe ich mich an einen SQL Eventhandler und eine Bauliste gemacht, die beide fast fertig sind.

Die Bauliste unterstützt eine Wartefunktion, die es dem Spieler erlaubt eine Liste anzulegen ohne vorher auf die Verfügbarkeit von seinen Ressourcen zu achten. Das ist leider noch nicht ganz fertig und bestimmt nicht bugfrei, aber der Ansatz steht.

PHP bekommt hinter dem SQL Core nurnoch die Aufgabe die Daten des Users zu validieren, zb ob er das überhaupt schon bauen darf…

Resultierend aus dieser Umstrukturierung wird es auch möglich sein dem Spieler eine individuelle Schiffgestaltung zu überlassen. Dh. man könnte es beispielsweise ermöglichen bestimmte Waffen einzubauen. Dies ist vorerst allerdings nur Zukunftsmusik, ich kümmere mich vorerst nur um serverinterne Angelegenheiten und um Performance & Erweiterbarkeit. Das Interface könnten danach auch ein paar Helferlein schreiben können, die nichtmal so viel davon verstehen müssten.

Leider ist mir heute bei einem Windoof Absturz mein SQL Ressourcen- und Eventhandlerscript abhanden gekommen, einen Großteil hatte ich mir zum Glück ausgedruckt, aber die Bauliste muss ich wohl neuschreiben, zudem muss ich einiges abtippen. Das kostet mich Zeit und regt mich auf, aber das wird schon.

PS: Morgen werde ich 18