Ganja-Manager

Es geht gut voran...

...meine Datenbankklasse läuft und ich hab das Grundgerüst um das Spiel herum soweit lauffähig:

Startbildschirm mit Optionen (Account erstellen, Account auswählen, Spieloptionen)

Hab mich auch etwas mit Exceptions beschäftigt, sodass meine Accountklasse bei Aufruf mit

Accounts.addAccount("Florian");

eine UserExistException auslösen kann.

Wer sich übrigens die Mindmap mal genauer angesehen hat, dem ist bestimmt aufgefallen, dass die Zweige Grundstücke, Gewächshäuser und Autos nach dem gleichen Schema aufgebaut sind. Jedes dieser Objekte hat Eigenschaften, einen Satz Optionen sowie Unterobjekte (Grundstück hat Gewächshäuser, Gewächshäuser haben Pflanzen, Auto hat Ladung).

Das läd natürlich dazu ein, die Anzeige dieser Objekte über ein einziges View laufen zu lassen, was Arbeit ersparen und die Bedienung vereinheitlichen dürfte.

Der nächste Schritt wird sein, die Datenbank zu entwerfen, wobei ich große Teile davon schon im Kopf habe und auch aus dem Browsergame übernehmen kann.
Wenn Interesse besteht, kann ich das ER-Model ja zur öffentlichen Diskussion stellen...

Mit Abstrakten Klassen hab ich noch so gut wie nie gearbeitet, wofür würdest du sie genau einsetzen?

Ich schätze, sie werden mir helfen, wenn ich später verschiedene Objekte als Ladung deklarieren möchte. So soll es möglich sein, ganze Pflanzen, gebrauchsfertiges Dope, aber auch Lampen, Klimaanlagen und Artefakte (so nenn ich mal analog zu Rollenspielen Objekte die Fähigkeiten des Besitzers beeinflussen, zB. die goldene Schaufen die Fähigkeit grüner Daumen) auf dem Abstellplatz das Grundstückes zu lagern, in ein Auto zu verladen oder auf dem Markt zu verkaufen.
Ladung hat dann unter Anderem Eigenschaften wie Volumen und Gewicht, welche beim Einladen in ein Fahrzeug berücksichtigt werden müssen.

Außerdem, kann ich mir jezze auch langsam Gedanken um die Präsentation und Spielercharakter machen. So soll man beim Erstellen eines Account grob zwischen Gärtner, Dealer, Kiffer auswählen können, die verschiedene Starteigenschaften mitbrigen:

Gärtner
- Grüner Daumen +3
- Geschäftssinn +1
- Charisma +1

Dealer
- Grüner Daumen +1
- Geschäftssinn +4
- Charisma +0

Kiffer
- Grüner Daumen +2
- Geschäftssinn +0
- Charisma +3

Je nach Spielerfolg bekommt man Erfahrungspunkte, die man in Gewissen Abständen in verschiedene Fähigkeiten investieren kann.
Das ganze Erfahrungssystem soll sehr Dynamisch sein, daher darf die Datenbankstruktur entsprechend auch komplexer werden.

Ich bitte hiermit ausdrücklich um Anregungen...

Da das Spiel im Laufe seiner Entwicklung eine Vielzahl von Objekten enthalten wird, deren Objektzustände in der Datenbank verwaltet werden sollen, hab ich mir jetzt doch ein System zurechtgezimmert, welches man ansatzweise als DAO bezeichnen könnte.

Und zwar wird in jeder Klasse, die ein solches Objekt darstellt (Grundstück, Plfanze, Gewächshaus, Auto, usw.) ein Array mit seiner Datenbankstruktur definiert:

private static String tbName 	= "spieler";
private static String struct[][] = {
                            {"sp_id", "integer", "primary key", "autoincrement"},
                            {"sp_name", "varchat(32)"},
                            {"sp_geld", "integer(6)"},
                            {"sp_pass", "varchar(32)"},
                            {"sp_email", "varchar(64)"},
                            {"sp_stadt", "integer(3)"}
                            };

Dieses Array kann an meine DAO-Klasse tableHelper übergeben werden, welche daraus SQL-Abfragen generieren kann. Desweiteren kann die DB-Klasse per statischer Methode von jedem Objekt eine Instanz der tableHelper-Klasse anfordern, welche bereits die Strukturdaten des jeweiligen Objektes enthält. So kann die DB-Klasse automatisch fehlende Tabellen anlegen oder bestehende ändern, falls im Array der Klasse neue Felder hinzugefügt oder geändert wurden.

Auf diese Weise kann ich jederzeit neue Objekte in mein Spiel einbauen, ohne mich groß um die Datenbankstruktur zu kümmern.
Natürlich ist das keine Umfassende Lösung, da die relationalen Beziehungen zwischen den Objekten immer noch von Hand hergestellt werden und auch Verbindungstabellen werd ich noch von Hand verwalten müssen.

Das System ließe sich sicher noch weiterspinnen, allerdings will ich ein Spiel programmieren und kein umfassenden DAO-Framework für Android. Falls dies aber jemand tun will, stelle ich ihm gerne die entsprechenden Klassen und Informationen zur Verfügung.

Soo, es ging doch etwas mehr Zeit für Planung und Schaffung eines (weitestgehend) sauberen Frameworks drauf. Außerdem hat sich mir nun auch der Nutzen von Interfaces erschlossen, mit denen ich nun Objekte als beladbar oder Ladung deklarieren kann. Bei der OOP unter PHP hatte ich auf Vererbung und Interfaces weitgehend verzichtet, da schon das bloße Benutzen von einfachen Objekten einen exorbitanten Fortschritt gegenüber dem alten Spaghetticode darstellte...

Desweiteren hab ich nun auch ein vorläufiges ER-Model entworfen, bei dem ich jedoch einige schmutzige Tricks anwenden musste. Für Tips zur Vermeidung oder für etwas weniger schmutzige Varianten bin ich offen. Mit Themen wie DAO / JPA / Hibernate bin ich allerdings durch. Lieber schutzig und klein als sauber und overkill...

Auf dem ER-Model fehlen allerdings noch eine ganze Reihe von Feldern, da ich erstmal nur die Schlüsselfelder berücksichtigt habe. Außerdem kommen noch weitere Tabellen für den Handel/Verkauf von Gütern als auch für die Kunden/Absatz. Auch hier bin ich für Vorschläge offen.

[Blockierte Grafik: http://www.buschmann-edv.de/tausch/ER_Model_komm.png]

Ein (weiteres) Danke an Florian...

Das Ur-Objekt das du meinst, habe ich ja schon eingebaut, und zwar ist das die extTableManager-Klasse, von dem ich bereits alle anderen Objekte ableite. Bin nun auch am Überlegen ich auch das Lagerort-Objekt davon ableite. Eine "DirtyTrick" - Klasse wäre natürlich auch eine Idee, quasi als Schnittstelle zum sauberen Code und für den Fall, dass ich diesen Mechanismus noch an einer anderen Stelle einsetzen muss.

Das mit dem Controller zwischen Logik und GUI entspricht wohl einem MVC-Patttern, wobei mir da noch nicht ganz klar ist, wie eine Implementierung aussehen könnte. Ich hatte vor, in den Listenern der GUI-Elemente die jeweiligen Aktionen per Methoden der betreffenden Objekte auszuführen.

Allerdings hatte ich schon gegrübelt, ob ich für jeden Bildschirm ein XML-Layout mache, oder öfters benutzte Gruppen von Steuerelementen per Code einfüge, was wesentlich flexibler wäre, wovon in den einschlägigen Android Tutorials zwecks Übersicht aber immer abgeraten wird.

Hier mal einen ersten GUI-Entwurf :

[Blockierte Grafik: http://www.buschmann-edv.de/tausch/GUI_Entwurf.png]

Wie zu sehen ist, wiederholt sich das Element zum Auswählen eines Objektes auf fast jeder Seite des Programms. Hab auch schon eine Klasse, sowie ein Interface "Switchable" dafür implementiert. Wie würdest du vorgehen, um solche Elemente einfach wiederzuverwenden, bzw. vom restlichen Code zu trennen?

Jaaa, GanjaManager macht große Fortschritte, nicht zuletzt wegen Florians produktiver Ratschläge. Die Entwicklung der GUI hab ich jedoch erstmal zurück gestellt (will erst das MVC-Pattern komplett verstehen und dann muss mir Florian nochmal sein Template-Konzept genauer erklären) und konzenteriere mich erstmal auf die Plattformunabhängigen Klassen.
Das eigentlich Framework ist soweit fertig, daher hab ich mir zwischenzeitlich Gedanken darum gemacht, wie der Spieleserver für den Online-Modus funktionieren soll.

Mir ist dabei aufgefallen, dass lustigerweise meine PHP-Denke die Datenstruktur und das Vorgehen hinsichtlich der Persintenz stark beeinflusst hat. In der Praxis bedeutet dies, dass der Spielserver im Prinzip nur aus einer Datenbank bestehen muss, da die Spielklassen bei jeder Aktion sofort die entsprechenden Änderungen in der DB vornehmen.

Leider ist mir dabei aufgefallen, dass ich in meinen Klassen intensiven Gebrauch des ContenValues-Objektes gemacht habe, was eigentlich dazu dienen sollte, über das Projekt verstreute SQL-Abfragen im Code zu vermeiden. Hätte ich jedoch die uneleganten SQL-Strings im Code gelassen, hätte meine DB-Klasse diese lediglich an einen MySQL-Server, statt an SQLite weiterleiten brauchen.

Gibt es eine Möglichkeit den daraus generierten SQL-String auszugeben, bevor er durch getWritableDatabase().insert(table, null, ContentValues); ausgeführt wird?