Der Tag der Entscheidung rückt näher, Bestia Vs. Deepwood Engine, der Showdown am Wochenende in München rückt näher.

In der letzten Woche hab ich einige Sachen in Bestia zum Laufen bekommen vor allem das Mapsystem ist jetzt voll funktionsfähig. Nachher werde ich noch die letzten Scripte einbauen um auf alle im Spiel befindlichen Maps zu gelangen. Und danach die Onlineversion von Bestia löschen, die Datenbank an die neue Version anpassen und die neue Software auf den Server laden. Das Spiel wird allerdings nur zur Demonstration in München eingesetzt werden. Also kein allgemeiner Zugang. (keine Sorge alte Accounts bleiben erhalten).

Ja denn dummerweise habe ich mir gerade letzte Woche ein Buch über Objektorientierte Analyse und Design gekauft (vom O’Reilly Verlag, Objektorientierte Analyse und Design von Kopf bis Fuß, gibt auf der HP auch ein Probekapitel). Das Buch war zwar recht teuer aber ziemlich gut geschrieben und ich bin frohen Mutes auch ein paar (ok alle :D ) Anregungen aus dem Buch auf mein Projekt zu übertragen. Dummerweise steht damit ein sog. refactoring der Software an… Teilweise kann ich den Code ja noch wieder verwenden (so viel wurde eh noch nicht geschrieben ^^*).

Bestia UML Diagramm

So sieht das momentane Klassendiagramm für die nächste Bestia Version an (Alpha 2 wird dann übersprungen und wir gehen über zur Alpha 3 =P). Sie wird in PHP 5 geschrieben sein und somit muss ich meinen Webspace umstellen lassen. Den Blog sollte das nicht beeinflussen. Evtl aber meine Abi-Homepage. Ich werde darum erst noch einige Tests machen ob ich die Abiseite anpassen muss. Wenn es soweit ist wird es noch rechtzeitig eine Ankündigung geben. ^^

 Aber das ist noch bei weitem Nicht die Endfassung (wobei euch noch viele Klassen fehlen).

Ich werde versuchen die Klassen zu entschlacken (eine Bestia ist zum Beispiel für ihren Tot verantwortlich, aber wohl nicht dafür wie viel Schaden sie in einem Kampf verursacht.) Eine Menge Methoden werden in neue Klassen ausgelagert (Battle, Dealer, BestiaAdder usw.)

Ein SEHR zentrales Objekt ist eigentlich das DataTransfer Objekt. Es wird durch den (nicht im Diagramm enthaltenen) Datenbank-Layer (ein DAO-Pattern an dem ich gerade arbeite) mit Daten befüllt. Diese Datenobjekte sind durch den Einsatz eines assoziativen Arrays als Speicher recht flexibel (ja nicht die Hände vor den Kopf schlagen, 1. wurde das in dem Buch sogar für Java mit einer Map empfohlen bei gleichen Methoden und unterschiedlichen Eigenschaften das ganze „im Objekt zu kapseln“ durch den Einsatz einer Map). Dadurch wird dieses DataTransfer Objekt natürlich hoch flexibel. Evtl. fällt dann auch das PlayerBestiaData und NPCBestiaData Objekt weg, wenn ich einfach die Map mit unterschiedlichen Daten befülle. Ein BestiaData Objekt werde ich wohl dennoch machen, weil es mit dem hinzufügen von Equipment etwas hakelig werden kann (wenn ich auch fast alle auf dem UML-Diagramm zu sehenden Eigenschaften entfernen werde ^^*).

Beim Statusobjekt bin ich mir noch nicht sicher ob ich das wirklich als abstrakte Klasse belasse und mein Equipment und Statuseffect davon ableite. Ich tendiere eher dazu aus Status ein Interface zu machen wenn mir PHP 5 schon die Möglichkeit dazu bietet.

Lange Rede kurzer Sinn, das ganze wird erstmal gut durchdacht. Ich schreibe auch langsamer Code, im Moment arbeite ich am DAO-Layer für die Datenbank der mir aber etwas zu aufgebläht im Moment erscheint, vielleicht kann ich den noch entschlacken, dann füge ich noch ein Diagram zur Verständnis bei.

Einer der wichtigsten Teile von Bestia die Kommunikation zum Server mit des JavaScript Frontends ist zum Glück schon OOP durch den Einsatz des Front-Controller Patterns. Da werde ich relativ wenig ändern müssen. Nur eine Umrüstung auf eine neue Klasse zur Erzeugung von JSON da muss ich mal sehen wie ich das am besten Einfüge, sollte aber weniger Probleme geben.

Aber auch das JS-Frontent kann Veränderungen vertragen. JS ist eine ziemlich geniale Sprache hab ich in einem Video Tutorial erfahren. Sie geht zwar dank Prototyping einen recht eigensinnigen Weg, statt Objekte aus Klassen zu erzeugen wie die meisten anderen Sprachen. Auch einem Objekt zur Laufzeit neue Methoden und Eigenschaften hinzuzufügen ist recht „lustig.“ Jedenfalls hab ich JEDE Menge doppelten Code in meinem JS-Backend zu Gesicht bekommen. Das ist ja schon eine richtige GUI Anwendung. Gerade kam mir die Idee das Kampfmenü einmal Testweise durch ein OOP-Designansatz zu schreiben und evtl ein. Subject/Observer einsetzen den ich an die GUI Elemente anhaften werde und sobald die Kernkomponente über eine Änderung (Bestia nimm Schaden o.Ä.) informiert wird, aktualisieren sich die Observer-Objekte das wäre ziemlich cool. Wird noch ein paar Tests in der Richtung geben denke ich. ^^

So genug der technischen Details, daber damit ihr mal bescheid wisst was ich so den ganzen Tag mache. ;)