Tag Archives: KI

Zeit für Nägel mit Köpfen!

Wie das? Das erste Mal in der Geschichte der Science-O-Matics *zu einer ausladenen Rede anheb* Nicht? Ok, dann nicht.. Euch kommt es vielleicht nicht gar so episch vor, aber ich freue mich riesig – in Kürze, sprich im Mai (genaues Datum folgt) wird die KI als erste meiner Prototypen den Schritt ins freie, nein, soweit noch nicht, ins geschlossene wagen. Als eigenständiges Spiel aufgesetzt wird die KI mit schicker (mobile-fähiger) Weboberfläche in die Closed Beta gehen, um euch (hoffentlich) ein paar nette Stunden zu bescheren und sich (als klitzekleiner Hintergedanke meinerseits) sich von euch auf Herz und Nieren testen zu lassen :) In der nächsten Zeit wird es viele Updates dazu gehen und in ca. zwei Wochen wird dann die Anmeldung zur Closed Beta online geschaltet :) Ich freue mich auf viel Input eurerseits *klatsch*

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

Programmablauf: Option auswählen

Nachdem ich letzte Woche den allgemeinen Ablauf der Optionsebene im Coding besprochen habe, wollte ich nun nacheinander die (interessanten) Teile im Ablauf man genauer besprechen. Und starten möchte ich dabei mit der Auswahl der Option, also dem Baustein decide on option.

Auswahl Option

Auswahl Option

Der Ablauf findet (fast) komplett innerhalb der entsprechenden Instanz  der Klasse NPC statt. Einzige Ausnahme ist der Teil “get list of options”, hier wird vom DBHandler eine Liste mit allen Optionen angefordert. Ansonsten sind die folgenden Teile wichtig:

    • compute weights – aus den Bedürfnissen jeweils multipliziert mit der Gewichtung der jeweiligen Motivationsklasse werden die empfundenen Bedürfnisse ermittelt. Nun haben wir also einen Vektor, der genau dem vom NSC erhofften Resultat entspricht. Wir suchen im folgenden also die Option, die der NSC nun ausführen kann und deren erwartetes Resultat dem gefundenen Vektor am besten entspricht.
    • get list of all options – vom DBHandler wird die (ungefilterte) Liste aller Optionen angefordert. Diese enthält (später) mindestens die Nulloption (warten), ist also nicht leer.
    • evaluate (first) option (in list) – Die jeweils oberste Option wird ausgewertet, dabei werden als erstes die Voraussetzungen für die Option geprüft. An jede Option können Bedingungen geknüpft werden, momentan sind mögliche Bedingungen benötigte Items oder ein bestimmter Aufenthaltsort, das lässt sich aber später noch erweitern. Im ersten Schritt der Evaluation wird also geprüft, ob alle benötigten Gegenstände in der benötigten Menge im Inventar sind und ob der NPC am richtigen Ort ist. Dann wird die Wertung der Option ermittelt, diese Wertung ist der Abstand zwischen dem SOM Vektor (der die erwartete Bedürfniserfüllung durch diese Option ausdrückt) und dem im ersten Schritt ermittelten Bedürfnisvektor des NSCs. Ist dieser Wert größer als der Wert der bisher besten gefundenen Option, ist dies Option die bisher beste gefundene Option und wird sich gemerkt. Ist der Wert echt kleiner, wird die Option verworfen. Bei Gleichheit (dies kommt vor Allem / eigentlich nur in der Initialisierungsphase vor), wird die Option mit einer gewissen Wahrscheinlichkeit verworfen, sonst übernommen.
Posted in Code-O-Matic. Tagged with , .

Programmablauf: Optionsebene

Dieses Wochenende war endlich mal wieder Zeit, um mal ein paar Stunden am Stück zu proggen :) Erstens hat das sehr viel Spaß gemacht und zweitens bin ich gut voran gekommen :) So grob funktioniert nun alles, aber viele, viele, viele (viele, viele, viele.. :P ) Kleinigkeiten fehlen noch. Folgend seht ihr ein Ablaufdiagramm, das den groben Ablauf der Optionsebene (in der jetzigen Umsetzung) beschreibt.

Ablauf Optionsebene

Ablauf Optionsebene

Drei zentrale Mitspieler sind hier Instanzen der Klassen DBHandler (Schnittstelle zur Datenbank und Puffer), NPC (selbsterklärend) und AISimulation (simuliert das Umfeld).

  • get data: Aus dem Puffer (bzw. ultimativ aus der Datenbank) werden alle KI / NSC-relevanten Daten (Bedürfnisse, Gewichte der Motivationsklassen, Optionen, SOM, Inventar und Aufenthaltsort des NSCs). Aus diesen Daten wird dann eine Instanz der Klasse NPC erstellt. Dort wird dann erst die aktuelle Periode “durchlebt”, und dann die kommende Periode geplant.
  • decide on next option: Die Option, deren SOM-Werte den Bedürfnissen des NSCs am besten entspricht wird gewählt und eingeplant. Wenn wir uns in der live-Periode befinden, werden die dazu gehörenden Events aus dem Puffer geholt (get events) und in die Liste der kommenden Events einsortiert (sort events by date).
  • update time: Die Zeit wird upgedated auf den Zeitpunkt nach Ausführung der Option.
  • execute next event: Alle Events, deren Ausführungszeitpunkt vorm aktuellen Zeitpunkt liegt, werden nun ausgeführt. Die daraus resultierenden Änderungen in den Bedürfnissen, dem Inventar und dem Aufenthaltsort des NSCs (adjust inventory, location & needs) werden zusammen mit dem Event in den Puffer geschrieben.
  • In der Planungsperiode soll der NSC die nächste Periode nur planen, ohne zu wissen, welche Events wirklich eintreten werden. Dieser Vorgang findet also rein in der Instanz der Klasse NSC statt. Wieder wird die Option gewählt, deren SOM-Werte den Bedürfnissen des NSCs am besten entspricht. Sowohl die die Änderung in der Zeit als auch die Änderungen in den Bedürfnissen, dem Inventar und dem Aufenthaltsort des NSCs werden aus den Erwartungen des NSCs ermittelt und durchgeführt. Es werden dann Optionen ermittelt, bis die Planungsperiode komplett beplant ist. Die in der Planungsperiode getätigten Änderungen in den Bedürfnissen, dem Inventar und dem Aufenthaltsort des NSCs werden nicht in den Puffer übernommen, lediglich die Liste der Optionen landet ultimativ auf der Datenbank.
Posted in Code-O-Matic. Tagged with , .

Ablauf Kaufangebot

Nachdem ich in den letzten Artikeln einige Tools / Änderungen (Zeitreihenanalyse, Nutzen von Gegenständen, Geld.., Sekretärinnenproblem mit Lösungsansätzen) zur Evaluation von Kaufangeboten zusammen getragen habe, ist es wohl mal an der Zeit, die Ergebnisse des Brainstormings zu ordnen. Unten seht ihr ein Ablaufdiagramm, wie ich mir momentan die Kaufentscheidung vorstelle.

Der Plan ist also folgender: Der NSC erhält ein Kaufangebot, hierdurch wird der ganze Prozess getriggert. Der Erhalt des Kaufangebots kann natürlich einmal wirklich ein “spontan” erhaltenes Angebot sein, aber auch ein eingeholtes Kaufangebot, weil sich für die Option “Item xy kaufen” entschieden wurde. Der NSC ermittelt dann (aus der SOM) einerseits den Nutzen des Gutes bzw. der Güter und andererseits den Nutzen des zu zahlenden Geldes. Wenn der Nutzen des Geldes überwiegt, brauchen keine weiteren Überlegungen angestellt werden -> das Angebot ist für den NSC unattraktiv und kann abgelehnt werden. Überwiegt der Nutzen des Gutes / der Güter den Nutzen des Geldes, dann ist das Angebot generell attraktiv für den NSC. Statt das Gut aber sofort zu kaufen, muss der NSC nun entscheiden, ob er das Angebot annimmt, oder (woanders) ein anderes Angebot einholt. Entsprechend wird das vorliegende Angebot dann angenommen oder abgelehnt.

Dieser Ablauf lässt sich natürlich noch verfeinern, für die Zukunft schwebt mir als erste kleine Erweiterung vor, dass der NSC handelt. Sowohl im Falle der Ablehnung eines unattraktiven Angebots, als auch im Falle eines attraktiven Angebots kann der NSC die vorhandenen Info als sehr gute Verhandlungsgrundlage nutzen. Aber das ist mal wieder Zukunftsmusik.. Aber Musik ist schließlich was Feines..

Ablauf Kaufangebot

Ablauf Kaufangebot

 

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

mehr zum Sekretärinnenproblem

Nachdem das Sekretärinnenproblem in seiner Grundform unseren Anforderungen nicht gerecht wurde, will ich in diesem zweiten Artikel ein paar Erweiterungen aus der Literatur vorstellen. Vier (erste) Kritikpunkte wurden schon erwähnt, mal sehen was die Literatur dazu sagt:

Der Zielfunktionwert ist im Standardproblem entweder 1 (bester Kandidat gewählt) oder 0 (sonst).  Bei uns ist der Zielfunktionswert der Nutzen des angenommenen Kaufangebots (abzüglich der Evaluationskosten). Allgemeine Nutzenfunktionen wurden schon 1973 von Mucci vorgestellt. Diese sind (mit einigen Voraussetzungen, die bei uns gelten) wie die Grundform lösbar [1].

Im Standardproblem kommen die Kandidaten zum Entscheider, der NSC nachher muss den nächsten Händler (wahrscheinlich) aufsuchen. Dadurch entstehen Evaluationskosten (also Wegezeit). Auch Evaluationskosten wurden bereits in der Literatur behandelt, zuerst von Lorenzen in 1978 [4]. Mit allgemeiner Nutzenfunktion (ohne die Möglichkeit, zurück zu gehen und eine abgelehnte Option anzunehmen) lässt sich auch diese Aufgabe (unter gewissen Voraussetzungen) geschlossen lösen [5].

In der Grundform des Sekretärinnenproblems ist eine einmal abgelehnte Option dauerhaft verloren. Dem NSC wird es möglich sein, den Händler eines abgelehnten Angebots noch einmal zu besuchen und das Angebot (so der Händler es noch anbietet) doch noch anzunehmen. Schon 1974 wurde diese Erweiterung von Yang vorgestellt [2], gelöst wird auch diese Form mit dynamischer Programmierung [1].

Auch eine unbekannte Anzahl an Kandidaten wurde in der Literatur schon behandelt [1]. Doch diesen Punkt können wir uns eigentlich schenken – man kann leicht abschätzen, wie viele Händler besuchen ob der Evaluationskosten überhaupt Sinn macht und darüber lässt sich die Anzahl der Kandidaten schon gleich ab Anfang beschränken.

Soo, soweit zu den einzelnen Punkten.. Aber wir brauchen ja alle Punkte zusammen.. Das dann demnächst mit eigenem Hirnschmalz.

[1] P.R. Freeman. (1983). The Secretary Problem and its Extensions: A Review. International Statistical Review, 51 (1983), pp. 189-206.
[2] Smith, M.H. (1975). A secretary problem with uncertain employment. J. Appl. Prob. 12, pp. 620-624.
[3] Mucci, A.G. (1973). Differential equations and optimal choice problems. Ann. Statist. 1, pp. 104-113.
[4] Lorenzen, T. J. (1978). Generalising the secretary problem. Adv. Appl. Prob. 11, pp. 384-396.
[5] Lorenzen, T. J. (1981). Optimal stopping with sampling cost: the secretary problem. Ann. Prob. 9, pp. 167-172.

Posted in Inspiration-O-Matic, Theory-O-Matic. Tagged with , , .

Progg Sonntag :)

Es ist Sonntagmorgen, kurz vor neun, ich sitze mit dem ersten Kaffee des Tages am Rechner und überlege, was den Tag über geplant ist. Der grobe Plan steht bereits: Heute ist nur proggen geplant :) Endlich mal wieder :D Proggen für die zweite Version meiner KI. Doch was ist der Plan, wie weit möchte ich heute kommen? Ich möchte, dass heute Abend eine lauffähige Version der KI vorliegt, die

  • alle Funktionalitäten enthält, die bereits in der ersten Version der KI liefen,
  • aber dabei die mit Chro abgesprochene Schnittstelle für das User Interface der Testanwendung bereit stellt
  • und im geänderten (Klassen-…) Design ist.

Auch durch das dazu geänderte Design werden Anpassungen möglich, die ebenfalls heute Abend laufen sollen:

  • Der NSC merkt sich bei Optionen nicht nur, welche Änderungen in seinen Bedürfnissen er durch sie hatte (in der SOM), sondern auch welche Änderungen in Inventar und Aufenthaltsort sich dadurch (wahrscheinlich) ergeben.
  • Mit diesem Wissen entscheidet sich der NSC nicht nur immer für die nächte Aktion, sondern entwickelt Pläne für die gesamte nächste Zeit.
  • Wie angesprochen sollen auch Gegenstände, Orte und sie Zeit SOM Einträge bekommen.

Na dann mal auf auf :) Es gibt viel zu tun, packen wir’s an :)

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

Geld und Nutzen

Wenn der NSC nun mit Hilfe der Zeitreihenanalyse festgestellt hat, welchen Preis er momentan für fair hält, muss er entscheiden, ob der das Gut kauft oder eben nicht. Klar, zu einem guten Preis, der nah am ermittelten aktuellen “Marktpreis” oder sogar darunter liegt, wird der NSC das gewünschte Gut kaufen. Doch je nach subjektiver Wichtigkeit des Gutes, wird er vielleicht auch zu einem höheren Preis kaufen. Wenn er Hunger leidet, sollte er in Betracht ziehen, auch überteuerte Lebensmittel zu kaufen, nicht in jeder Situation und nicht um jeden Preis, aber es sollte nicht kategorisch abgelehnt werden.

Also werde ich wohl nicht umhin kommen, eine für wesentlich später geplante Erweiterung vorzuziehen: Momentan haben lediglich Optionen einen (erwarteten) Nutzen, also einen sich verändernden Eintrag in der SOM. Die Optionen lauten dann zum Beispiel “Brot essen”. Für später war geplant, dass es sowohl elementare Optionen als auch zusammengesetzte Optionen (z.B. [kaufen, Preis, Item], [laufen, Aufenthaltsort, Zielort], [anheuern, Art der Arbeit, Lohn], [essen, Item]) geben wird. Die elementaren Optionen haben jeweils einen SOM Wert. Bei den zusammengesetzten Optionen ist dem NPC bekannt, welche Änderung in Aufenthaltsort und Inventar (inklusive Geld) sich aus der Option (evtl. mit welcher Wahrscheinlichkeit) ergeben werden. Für jedes Item (inklusive Geld), jeden Ort und jede Wegstrecke wird je ein SOM Eintrag für Besitz (bzw. Nichtbesitz), Aufenthalt und Nutzungsmöglichkeiten (z.B. essen, passieren) gespeichert. Aus diesen Werten ermittelt der NSC dann den Nutzen für diese Option, also zum Beispiel bei einem Kaufangebot für ein Item x zum Preis y wird nachgesehen, welcher Nutzen u(Item x) für den Besitz für Item x eingetragen ist, wie viel Nutzen u(Geld) er pro Besitz von einer Einheit Geld erwartet und der Nutzen der Kaufoption ist dann u(Item x) – y * u(Geld).

Welche Objekte bekommen dann jeweils einen SOM Eintrag? Meine momentane Auflistung enthält:

  • elementare Optionen
  • jedes Item für jede mögliche, definierte Nutzung von eben diesem (z.B. [(Brot, 100g), essen]), inklusive der Spezialfälle
    • [Item, besitzen] und
    • [Geld, besitzen],
  • jeder Ort (jede Art Ort?) für den Aufenthalt (z.B. ),
  • jeder Weg zwischen zwei benachbarten Orten mit der Aktivität laufen (z.B. [laufen, Taverne, Marktplatz]) und
  • Zeit.
Posted in Code-O-Matic. Tagged with , , .

KI und Preisentwicklung

Während die Testumgebung für die erste Version der KI für unsere NSCe noch im Bau ist, kann man ja schon einmal über erste Erweiterungen nachdenken :) Der momentan größte Dorn in meinem Auge ist das fehlende Preisgefühl der NSCe. Momentan ist es so, dass der NPC Dinge kauft (weil sich das als gut erwiesen hat) und zwar unabhängig vom Preis, zu dem das Gut gerade angeboten wird. Das ist für die spätere Integration in ein größeres System mit einem Wirtschaftssystem natürlich fatal. Zum einen ist es geradezu eine Aufforderung zum Exploit an alle Spieler. Zum anderen macht es das Wirtschaftssystem unberechenbar, wenn eine nicht vernachlässigbare Anzahl an Teilnehmernsich eben nicht rational verhält. Das erste neue Ziel ist also die Antizipation des NSCs von Preisentwicklungen.

Als Mittel der Wahl, um Preisentwicklungen mathematisch zu berücksichtigen, ist die Zeitreihenanalyse. Genauer gesagt war mein erster Gedanke ein in den Wirtschaftswissenschaften gängiger Ansatz der Zeitreihenanamyse, das Trend-Saison-Modell. Hier werden Preisdaten über die Zeit erhoben und in Trend-, Saison- und Rauschkomponente unterteilt. Die Trendkomponente beinhaltet die langfristige, nicht periodische Entwicklung des Preises. Die Saisonkomponente enthält saisonal periodisch wiederkehrende Effekte. Die Rauschkomponente enthält nicht erklärbare, unregelmäßige Effekte. Momentan ist nicht absehbar, dass wir überhaupt Saisoneffekte haben werden, also können wir wohl auf die Saisonkomponenete verzichten. Plan?

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

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 , , .

Testumgebung KI

So, mittlerweile ist der Plan für den nächsten Schritt für meinen KI Prototypen genug gereift, um ein paar Worte dazu zu verlieren. Zum momentanen Stand habe ich ja im letzten Artikel zur KI schon viel gesagt, zusammengefasst liefert die KI in der behüteten simulierten Umgebung bei geringer Unsicherheit gute Ergebnisse. Damit sich die Mühe auch gelohnt hat, muss sich die KI aber auch besonders in unsicheren und wechselhaften Umgebungen trotzdem vernünftig entwickeln. Da das im momentanen Setup schwer zu testen ist, ist der nächste Schritt der Entwurf und die Umsetzung einer möglichst flexiblen Testumgebung für die KI.

Der momentane Plan sieht folgendermaßen aus: In dieser Testumgebung soll der User die Simulation des Umfelds übernehmen. Der / die NSC werden also in eine Welt gesetzt, in der das Umfeld nur in ganz rudimentären Zügen vom Programm simuliert wird und alle Ereignisse vom User bestimmt werden. Dadurch kann getestet werden, ob der NSC sich den vom User frei gestaltbaren Welten korrekt anpasst.

So, und wie ist da der momentane Stand? Wir haben die Grobkonzeption schon recht weit fertig, der grobe Ablauf ist klar, momentan sind wir an der Tabellenstruktur dran :) Danach folgt die Neugestaltung des bereits bestehenden C++ Codes für die Ausführung der KI und das Planen und Erstellen des UIs. Es gibt viel zu tun, packen wir’s an :) Ich freu mich jedenfalls drauf :)

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

Der NPC entwickelt sich

Und weitere wichtige Schritte für den ersten Prototypen der KI sind  getan: Die Bedürfnisse steigen mit der Zeit wieder, so dass der NSC mit der Zeit wieder hungrig, durstig etc. wird. Er findet auch in dieser Welt, auch langfristig spielend seinen Weg, geht arbeiten und damit Geld verdienen, kauft ein, isst, trinkt, schläft. Und die Rückwirkung der Erfüllungsgrade der Bedürfnisse auf die Entwicklung des NSCs, genauer gesagt auf die aus der Motivationsebene übermittelten Gewichtungen der Bedürfnisse der fünf Motivationsklassen ist nun implementiert. Der NPC, der es ja wie gesagt gut schafft, seine physiologischen Bedürnisse auch langfristig gestillt zu halten, arbeitet sich so langsam über die Sicherheitsbedürfnisse zu den sozialen Bedürfnissen (noch nicht umgesetzt) hoch:

Gewichte Motivationsklassen

Gewichte Motivationsklassen

Es ist wohl an der Zeit für eine kurze Zusammenfassung der bisherigen Fortschritte. Also bisher  implementiert ist:

  • Der NSC entscheidet sich für eine jeweils nächste durchzuführende Handlungsoption anhand von empfundenen Bedürfnissen, die sich jeweils zusammen setzen aus dem Erfüllungsgrad des Bedürfnisses und der Gewichtung der Motivationsklasse des Bedürfnisses.
  • Er entscheidet sich dabei immer für die Handlungsoption, von der er die bestmögliche Befriedigung aller empfundenen Bedürfnisse erwartet.
  • Zu Beginn der Simulation sind keinerlei Erwartungen vorgegeben, der NSC formt seine Erwartungen an eine Handlungsoption einzig und allein aus seinen bisherigen Erfahrungen mit der Durchführung der Handlungsoption.
  • Situationsebene und Umfeld werden simuliert. Für jede Handlungsoption sind Events hinterlegt, die mit gewisser Wahrscheinlichkeit durch die Ausführung einre Handlungsoption getriggert werden (der NSC hat natürlich keine Kenntnis dieser Events). Zu jedem Event sind ein Wertebereich und ein zeitlicher Abstand von der Ausführung der Handlungsoption hinterlegt. Das Event wird registriert und zu gegebener Zeit ausgeführt.
  • Wenn ein Event, dass des Erfüllungsgrad eines Bedürfnisses ändert, getriggert wird, wird die SOM (also die Erwartung des NSCs) für alle innerhalb des letzten halben Jahres ausgeführten Handlungsoptionen geändert. Dabei ist die Änderung umso größer je geringer der Zeitabstand zwischen Event und Ausführung der Handlungsoption ist.
  • Werden alle Bedürfnisse einer Motivationsklasse über einen längeren Zeitraum hin weitgehend erfüllt, so ändern sich die Gewichte der Motivationsklassen. Das Gewicht der Motivationsklasse, deren Bedürfnisse weitestgehend erfüllt sind, wird verringert und umgeschichtet auf die nächsthöhere(n) Motivationsklassen. Auch eine Rückentwicklung ist möglich.

Mein Erwartungen an den ersten Prototypen waren:

  • Der NSC soll eigenständig erkennen und nutzen, welche Handlungsoptionen für seine offenen Bedürfnisse passend sind. In anderen Worten, die SOM soll sinnvolle Werte annehmen.
  • Auch Handlungsabfolgen (wie “zum Markt gehen” -> “Brot kaufen” -> “Brot essen”) zur Befriedigung eines Bedürfnisses sollen über die SOM erkannt werden.
  • Der NSC sollte einen Lebensrhytmus finden, in denen alle einfach erfüllbaren Bedürfnisse dauerhaft weitestgehend erfüllt sind.
  • Die Gewichte der Motivationsklassen sollten sich dann entsprechend anpassen

Damit ist alles umgesetzt, was ich mir für den ersten Prototypen, die erste Phase des Teilprojektes “KI”, vorgenommen habe. In der nächsten Phase stehen dann zwei Dinge im Vordergrund: 1) umfangreiches Testing und (damit das keine Qual wird) 2) eine ansprechende und funktionale Testumgebung.

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

Update KI: erste Lernerfolge :)

So, heute mal wieder ein wenig Zeit mit meiner KI verbracht, habe Auswirkungen eingepflegt und ein paar “komplexere” Handlungsoptionen. Das und ein paar Stunden Bugfixing später führt der NSC nicht mehr nur wild Aktionen durch, sondern lernt, dass Brot und Fleisch sehr stark sein Bedürfnis 1 (= Hunger) befriedigen, aber auch dass Aktionen wie “zum Marktplatz laufen” und “ein Brot kaufen” in geringerem, aber doch merkbarem Maße zur Befriedigung seines Bedürfnisses 1 beitragen. Also wenn er ein Brot (oder Fleisch) besitzt und Hunger hat, wird er dies essen, wenn nicht, wird er versuchen, Brot oder Fleisch zu erstehen. Morgen schaue ich mal an, wie gut (und damit unter Anderem wie stabil) sich das Ganze auf längere Sicht verhält und ob er darauf kommt, dass er anheuern muss, um wieder neues Geld zu bekommen und so weiter.. Zusätzlich werde ich morgen auch schauen, dass ich Bedürfnisse wieder auffrische, also er über die Zeit wieder hungrig wird und so.. Aber für heute bin ich zufrieden :)

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

Die SOM wird nun angepasst..

Soo, nach langer Zeit mal wieder an die KI gesetzt und ich kann nun einen NSC mit leichtem Hunger, Durst und ein paar anderen offenen Bedürfnissen in meine simulierte Umwelt setzen und zu folgender Erkenntnis kommen lassen: Das bringt doch alles nichts. Stimmt ;) Die Tage dann mal möglichst viele Auswirkungen in die DB einpflegen :) Das hat Spaß gemacht :)

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

Das Umfeld wird simuliert

So.. und hier ein weiteres kurzes Update zum Stand der KI :) Was bereits funktioniert: Die Gewichtung der Motivationsklassen für den NSC wird ermittelt, die Bedürfnisse des NSCs werden ermitteln und der NSC entscheidet sich für die laut aktuellem Stand der SOM optimale Handlungsoption. Eigentlich würde in diesem Moment ja diese Handlungsoption an die Situationsebene weitergegeben, die dann einzelne Elementaroptionen zur Ausführung aussuchen würde. Da sowohl die Situationsebene als auch das Umfeld des NSCs nicht zur Verfügung stehen, wird dieser Teil simuliert. Jede Handlungsoption hat spezifische Wahrscheinlichkeiten für Events (sowohl für sofort eintreffende als auch für zeitversetzte), die dann von der Simulationsumgebung eingeplant und zum eingetragenen Zeitpunkt ausgeführt werden. Was noch fehlt: Die Auswirkungen von Events auf die Bedürfnisse des NSCs, die Änderung der Gewichtung der Motivationsklassen des NSCs, die Zuordnung der auf den NSC einprasselnden Events zu Handlungsoptionen und damit verbunden die entsprechende Änderung der SOM. Das nächste (ansonsten endlich mal wieder unbeplante) Wochenende kann kommen! :D

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

erste Customizing Einträge für die KI

die 5 Motivationsklassen

die 5 Motivationsklassen

So.. noch einmal ein kurzes Update über den aktuellen Stand der KI :) Grundgerüst der beiden oberen Ebenen der KI in C++ steht soweit, vorgestern habe ich nun erste Daten eingetragen um die Tage erste Tests starten zu können :) Also nicht, dass es schon fast fertig klingt: erste Tests sind erst einmal technische Tests. Danach muss erst einmal eine Simulation für die Situationsebene und für das Umfeld (und die Effekte der Entscheidungen) und dann folgen erst erste Tests, ob dieser erste Prototyp tut, was ich mir erhoffe :) Naja, eingetragen sind nun die fünf Motivationsklassen (Bild links), 13 Bedürfnisse aus diesen Motivationsklassen (Bild unten) und 27 Handlungsoptionen.

erste Bedürfnisse

erste Bedürfnisse

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