Tag Archives: Datenbank

KI Testumgebung: Ereignisse einplanen

Wie im Artikel Testumgebung KI eingeführt, ist der momentane Plan die Erstellung einer Testumgebung für die KI. Hier soll der NSC sich in einer weitgehend vom User kontrollierten Welt behaupten. In diesem ersten fachlichen / inhaltlichen Artikel dazu will ich kurz einen Teil der Datenbankstruktur vorstellen, genauer gesagt geht es darum, wie der Spieler die Umwelt kontrolliert. Dies wird (wie in der Simulation) über Ereignisse geschehen. Der User plant Ereignisse und deren Folgen ein, der NSC wird (aufgrund der über eine SOM definierten KI) sich an diese Ereignisse anpassen.

KI: Auszug aus der ERM

KI: Auszug aus der ERM

Die Tabelle EventType enthält eine Liste möglicher Ereignisse. Zu jedem möglichen Ereignis sind in den Tabellen EventTypeItemClass, EventTypePlace und EventTypeNeed die dazu gehörenden Auswirkungen auf Aufenthaltsort, Inventar und Bedürfnisse hinterlegt, jeweils mit Bereichen für Werte und Zeitabständen. Plant der User dann ein mögliches Ereignis für einen NSC ein, so wird er für jede hinterlegte Auswirkung nach Wert und Zeitabstand (innerhalb der gegebenen Grenzen) gefragt. Das explizite Ereignis landet in der Tabelle Event, seine Auswirkungen mit konkreten Werten und Zeiten in den Tabellen EffectItemClass, EffectPlace, EffectNeed.

Posted in Code-O-Matic. Tagged with , , .

Ordnung schaffen: eine Datenbank Handlerklasse

Eigentlich wollte ich am Wochenende dafür sorgen, dass endlich mal ein paar Screenshots von einem ganzen Wald (noch ohne schöne Texturen, aber immerhin..) online kommen. Dafür notwendig waren ein paar Änderungen, die das Langzeitverhalten der Wuchsform der Bäume betreffen. Uneigentlich.. ist mir mein stiefmütterliches Behandeln der Datenbankzugriffe auf den Kopf gefallen.. Irgendwo schreibt eine Methode Werte auf die Datenbank, die ich zu dem Zeitpunkt da noch nicht drin haben will. Aber wo? Es war immer geplant, dass ich das Coding nochmal aufräume, aber ich hatte gehofft es verschieben zu können bis alle Grundfunktionalitäten stehen. Und dann gründlich aufzuräumen, ohne die Funktionsweise zu schädigen. Aber statt mich durch den Code zu wühlen und den “schuldigen” Datenbankzugriff händisch rauszusuchen, ziehe ich zu mindestens dieses Schritt des Aufräumens vor und implementiere ein zentrales Handling der Datenbankzugriffe.

Folgende Anforderungen an das Handling habe ich mir gestellt:

  • Sämtliche Datenbankzugriffe laufen über die Methoden der Handlerklasse, außerhalb von dieser ist die Verbindung zu Datenbank nicht bekannt.
  • Die Handlerklasse ist verantwortlich für die Datenkonsistenz innerhalb des Programmaufrufs und für die Verwaltung entsprechender Sperreinträge auf der Datenbank.
  • Die Handlerklasse dient als Puffer zwischen Datenbank und Programm.
  • Programmteile brauchen die Berechtigung, um Datensätze des Puffers auslesen oder schreiben zu dürfen.
  • Alle Datenbankzugriffe werden mitgeloggt.
UML Buffer

UML Buffer

Nebenstehend ein Diagramm, das den groben Ablauf des Handlings der Datenbankabfragen zeigt. Jede Datenanfrage der Umweltsimulation wird an den Datenbankhandler gestellt. Dieser prüft, ob die Berechtigung vorhanden ist, ansonsten wird abgebrochen. Wenn diese Daten noch nicht geladen wurden, werden sie aus der Datenbank geladen. Es wird geprüft, ob die Daten einen Sperrvermerk haben, ansonsten werden die entsprechenden Datensätze ausgelesen und mit einem Sperrvermerk versehen. Die ermittelten Daten werden in die benötigten Strukturen überführt und in den Puffer geschrieben. In beiden Fällen werden die Informationen aus dem Puffer an die Simulation zurück gegeben. Jede Änderungsanfrage der Umweltsimulation wird ebenfalls an den Datenbankhandler gestellt. Dieser prüft, ob die Berechtigung vorhanden ist, ansonsten wird abgebrochen. Wenn die Berechtigung vorhanden ist, werden die Daten im Puffer geändert. Zusätzlich können aus der Simulation heraus das Committen oder Verwerfen der Änderungen angestoßen werden.

Posted in Code-O-Matic. Tagged with , , , .