Tag Archives: !∃2.0

Anmeldung zur Closed Beta

logo_p2

Ab sofort kann man sich für eine Closed Beta zum Testen der Künstlichen Instelligenz (KI) registrieren.

beta.scimats.de

Ihr erhaltet rechtzeitig vor dem Start der Closed Beta am 01.06. eine Mail sowie weitere Informationen rund um das Spielen mit der Künstlichen Intelligenz.

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

Das User Interface zur Künstlichen Intelligenz

Das zweite bereits umgesetzte Feature ist eine KI für das Verhalten der NSCe. Dabei geht es nicht um sehr kurzfristige Entscheidungen wie Entscheidungen auf dem Kampffeld, sondern um überlegte Entscheidungen. Darum, dass jeder NSC ein Leben hat, Gründe, morgens aufzustehen, Gründe, sich zu verhalten wie er es tut. Um das zu erreichen braucht ein NSC wohl erst einmal Ziele, und diese werden ermittelt mit Hilfe der Maslowschen Bedürfnispyramide. Aus offenen Bedürfnissen und ihren Gewichtungen ermittelt sich die empfundene Bedürfnisse. Mit Hilfe einer SOM ermittelt er dann die Handlungsoption, die ihm der Erfüllung dieser Bedürnisse am nächsten bringt. Das Ganze tut sich schon ganz gut aus – und bald freut es sich auf Tester von außerhalb :)

Dieser Auszug aus der Projektbeschreibung trifft kurz und bündig sehr gut, was die Künstliches Intelligenz aus unserer Sicht leisten muss, um wahrlich als künstlich intelligent bezeichnet werden zu können. Keine Scripts, welche durch ihren Umfang bestechen, sondern ein selbsständig agierender NPC.

ui_ki_overview

Die Übersicht der Anwendung

Nun gab es bei dem ersten Feature “Generierung der Umwelt” bereits in Bild und Ton die Ergebnisse präsentiert. Bei der KI bedarf es dann doch eher etwas mehr Interaktivität als nur Bild und Ton. Zumal die KI erst einmal lernen muss, und jeder NPC seinen eigenen Charakter bilden soll. Daher bedarf es auch Hilfe von “außerhalb” und somit auch einem User Interface, kurz UI, zur “Kontrolle des NPC”. Wie das Ganze aussieht und welche Rolle ihr dabei spielen werdet möchte ich kurz zeigen. Denn direkt kontrollieren könnt ihr den NPC nicht.
Ihr habt euren eigenen Schützling in Form eines NPC. Dieser NPC lebt momentan an einem bestimmten Tag zur einer bestimmten Stunde an einem Ort mit seinem Inventar. Eingefroren. Das heißt die Zeit steht still und wartet darauf für die nächsten Tage oder Stunden weiterzulaufen.

ui_ki_events

Die Planungsübersicht

Hier kommt ihr ins Spiel. Der NPC hat in der Vergangenheit bereits Aktionen bzw. Handlungsoptionen (Options) ausgeführt und Ereignisse (Events) haben stattgefunden. Alles hatte bereits Einfluss auf euren kleinen Schützling bis zum oben genannten Zeitpunkt. Wo es eine Vergangenheit gibt, gibt es auch eine Zukunft. Und auch diese wurde bereits minutiös geplant, mit Aktionen und Ereignissen. Nun gibt es aber die Umwelt, und das die nicht immer läuft wie geplant liegt an euch ;)

So liegt es nun an euch für die Zukunft Events zu streichen, zu planen und zuzuschauen, wie reagiert euer Schützling darauf? Und wie entwickelt er sicht erkennbar in seinen Options? Seid ihr eine grausame Umwelt, die das tägliche Training durch Hagelschauer ruiniert und eventuell euer Schützling zwingt doch Sticken zu lernen anstatt ein Krieger zu werden?

Dies könnt und sollt ihr aktiv mit der UI steuern, um so euren eigenen Charakter zu bekommen, individuell und garantiert unterschiedlich zu jedem anderen Charakter :)

Zusätzlich bekommen wir durch eure verschiedenen Handlungsanweisungen Informationen über die KI, können diese verbessern und letztlich eventuell auch als Charakter in das Spiel setzen.

Geplante Closed Beta Features

  • Gestaltet bereits zu Beginn das Aussehen eures Schützlings.
  • Plant und entfernt Ereignisse (Events), welche sich direkt auf das Verhalten (Options) eures Schützlings auswirken.
  • Gebt eure Planung frei indem ihr die Zeit für x Tage oder Stunden ausführt.
  • Euer hungernder Schützling findet zufällig ein Brot in seinem Inventar? Seht am Inventar direkt Auswirkungen und Änderungen.
Posted in News-O-Matic. Tagged with , , .

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

Das Sekretärinnenproblem

Der NSC kann nun nicht nur mit Hilfe der Zeitreihenanalyse ermitteln, welchen Preis er für das angebotene Gut für fair hält,  sondern kann über die Nutzendifferenz von Gut und Geld auch genau den erwarteten Nutzen ermitteln (siehe auch Geld und Nutzen). Doch wie entscheidet er nun, ob er das Kaufangebot annimmt oder in der Hoffnung nach einem besseren Angebot (vorerst) ablehnt und weitersucht? Ein erster Schritt zur Antwort könnte das Sekretärinnenproblem sein, dessen Grundform ich in diesem Artikel vorstellen möchte.

In der Grundform des Sekretärinnenproblems werden nacheinander n Bewerber(innen) vorgestellt und nach der Evaluation des jeweils aktuellen Bewerbers muss sofort entschieden werden, ob die Bewerbung angenommen oder abgelehnt wird. Es darf nur genau eine Bewerbung angenommen werden (also wenn eine Bewerbung angenommen wird, gehen alle vielleicht noch kommenden besseren Bewerber verloren) und eine einmal abgelehnte Bewerber(in) ist dauerhaft verloren. Es gibt nur zwei Ausgänge: Sieg (die beste Bewerbung wurde angenommen, Zielfunktionswert 1) oder Niederlage (die beste Bewerbung wurde nicht angenommen, Zielfunktionswert 0). Die Aufgabe ist es, eine optimale Annehm- / Ablehnstrategie zu finden, also eine Strategie, in der die Chance, die beste Bewerbung anzunehmen, maximal ist. [1]

In dieser einfachen Version gibt es für das Sekretärinnenproblems geschlossene Lösungen [1]. Doch die Situation mit unserem NSC wird von den Annahmen der Grundform nicht abgedeckt, so zum Beispiel:

  • Der Zielfunktionwert entspricht dem Nutzen des angenommenen Kaufangebots (abzüglich der Evaluationskosten) und wird nicht 0, wenn es eine bessere Option gegeben hätte.
  • Die Evaluation einer weiteren Option kostet Zeit (Weg zum nächsten Händler..).
  • Es ist möglich, eine abgelehnte Option noch einmal zu evaluieren, dies verursacht erneut Evaluationskosten (Weg zurück zum Händler) und eventuell ist das Angebot nicht mehr gültig.
  • Die Anzahl der möglichen Kaufangebote ist a priori nicht notwendigerweise bekannt.

[1] P.R. Freeman. 1983. The Secretary Problem and its Extensions: A Review. International Statistical Review, 51 (1983), pp. 189-206.

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

Handwerksmaterialien: Federn

Vogelpärchen

Vogelpärchen

Ein weiteres tolles Material für Schmuck und Kleidung sind fremde Federn. Von einfachen, heimischen Tieren bis zu exotischen und seltenen Vögel lassen sich Federn zur Zierde (aber auch mit Nutzen wie zum Beispiel für Decken und Kissen) gewinnen. Je auffallender, seltener, schwerer zu bekommen, desto wertvoller werden sie sicherlich gehandelt werden.

eine Auswahl schöner Federn..

eine Auswahl schöner Federn..

Posted in Inspiration-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 , .