Category Archives: Code-O-Matic

neue Kleidung im Avatar Creator

Cookie Kleid (RL)

Cookie Kleid (RL)

Damit die liebenswürdigen LaborNSCs unserer Testanwendung für die Künstliche Intelligenz auch ein Gesicht bekommen, nutzen wir den SVG Avatar Creator, ein sehr schönes Tool für die Charaktererstellung zur Einbindung in (mobile) Webseiten. Mit diesem Tool kann jeder Spieler seinen eigenen kleinen Avatar designen – liebevoll gemacht, schöne Auswahl an Gesichtsfeatures und Accessoires und akzeptable Nutzungsbedingungen und Anpassungsmöglichkeiten.

Und damit sind wir auch schon beim nächsten Punkt: auf dass die entstehenden NSCs in unser Setting passen, wollten wir doch einige Änderungen im SVG Avatar Creator machen. Also einige Gegenstände (Brillen..) aussschließen, einige Farben ausschließen, einige Kleidungsstücke ausschließen und.. einige neue einfügen.. Die Ausschlüsse, kein Problem, netterweise auch alles gestattet und im Coding einfach gemacht. Neue Kleidungsstücke laut FAQ des SVG Avatar Creators.. eher schwierig.

Cookie Kleid (Avatar)

Cookie Kleid (Avatar)

Aber im FAQ klingt es so, als ob es vor Allem schwierig ist, weil man keine .jpg oder .png einbinden kann. Also als erstes Mal eines der mitgelieferten Kleidungsstücke (gegeben in Pfaddarstellung) in Inkscape angeschaut und mein für die RPC gebautes Kleid als Vektorgrapfik nachgebaut. Pfade anzeigen lassen, Pfade als neue Möglichkeit eingebaut und voilá: mein Kleid ist auswählbar :) Momentan ist dies das einzige neue Kleidungsstück, aber mehr wird kommen :) Hoffentlich ^^ Wahrscheinlich.. Wenn der Rest bugfrei läuft ;)

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

How-To: UI für Anfänger – jQuery Mobile (I)

Keep it simple.

mobile_website_vs_appMobile Webanwendungen oder -webseiten sind keine Apps, sondern Webseiten die für die mobile Betrachtung optimiert wurden. So gibt es kleine Skripte, welche die mobile Browser erkennen und einen direkt auf die mobil optimierte Webseite weiterleiten (siehe z.B. IKEA). Die mobilen Webseiten können natürlich auch auf dem heimischen Computer aufgerufen werden, aber der knapp dimensionierte Platz wird bei inzwischen standardmäßigen Auflösungen von 1920×1080 kaum genutzt. Inzwischen gibt es auch “Compiler” (Phonegap), welche die mobile Webseiten in eine native App umwandeln. Hierbei wird der Browser durch ein Framework simuliert und eine gesonderte API ermöglicht die Kommunikation mit der Kamera des Smartphones. Hier tut es uns aber einfach mal eine einfache mobile Webanwendung, denn wir wollen es einfach halten.

Continue reading

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

How-To: UI für Anfänger – Die Einleitung

Seitdem immer mehr Anwendungen in das Internet wandern und zudem das Internet immer mehr auf Smartphones genutzt wird, liegt es nah diesen Trend zu begleiten und eine UI-Unterstützung als Web-Anwendung für mobile Endgeräte zu erstellen. Gelegenheit dazu gibt es unter anderem, um die parallel laufende KI-Entwicklung von Cookie zu unterstützen. So ist es geplant, die KI bequem mehr mobilen Endgerät auf Herz und Nieren zu überprüfen. Eine Web-Anwendung ist im Prinzip nichts anderes als eine Homepage gestaltet als Anwendung im Web, welche damit logischerweise nur im Browser läuft und nicht installiert werden brauch. Passt man das Format auf mobile Endgeräte an, so laufen diese Homepages Smartphone-optimiert auf den jeweiligen Browsern.

Nun gibt es gerade im Umfeld des Internets einige Schlagwörter und Begriffe, welche nicht allen zugänglich sein dürfte. Zudem stehen einem zumeist eine große Bandbreite an (Open-Source) Programme, Frameworks und Standards zur Verfügung. Um vorab alles zu klären und zu erklären werde ich Schritt für Schritt auf die einzelnen Elemente eingehen und beginne in diesem ersten Blogeintrag der Serie erst einmal mit den Dingen, die ich gerne verwenden würde. Natürlich können diese sich noch im Laufe der Zeit ändern, da diese Blogserie laufend zur Entwicklung entsteht.

Continue reading

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

How-To: Python Scripting in Blender: (10) Objekte gruppieren

Outliner Objektgruppe

Outliner Objektgruppe

In diesem Tutorial wollen wir Objekte zu Objektgruppen zusammen fassen. Wie das How-To zum Collada Export wird dieses Tutorial so kurz, dass es eigentlich keinen “weiterlesen” Button braucht. Aber das Gruppieren von Objekten in Blender könnte noch einmal wichtig werden, also behandeln wir es eben :) Am Ende dieses Tutorials könnt ihr

  • Objekte gruppieren und
  • Objektgruppen auflösen.

Continue reading

Posted in Code-O-Matic, Graphic-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 , , .

How-To: Python Scripting in Blender: (9) Rotation mit Eulerkoordinaten

In diesem dritten und letzten Tutorial zur Rotation im dreidimensionalen Raum wollen wir uns die Drehung mittel Eulerkoordinaten ansehen. Am Ende dieses Tutorials könnt ihr

  • Eulersche Winkel berechnen und
  • mit Eulerschen Winkeln Objekte in Blender rotieren.

Continue reading

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

How-To: Python Scripting in Blender: (8) Rotation mit Quaternionen

In diesem zweiten Tutorialteil über die Rotation im dreidimensionalen Raum in Blender mit Python wollen wir uns die Rotation mir Quaternionen ansehen. Am Ende dieses Tutorials könnt ihr

  • Quaternionen berechnen
  • Rotationen in Blender mit Quaternionen durchführen und
  • Quaternionen- und Achse-Winkel-Darstellungen von Drehungen ineinander umformen.

Continue reading

Posted in Code-O-Matic, Graphic-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 , , .

How-To: Python Scripting in Blender: (7) Rotation im Modus “Axis Angle”

So, nach einer längeren Pause finde ich es ist an der Zeit die How-To Reihe zum Python Scripting in Blender wieder aufzunehmen. In den nächsten Tutorialteilen wollen wir uns mit der Rotation von Objekten im dreidimensionalen Raum beschäftigen. In diesem Teil werden wir uns die Drehung um eine Achse mit dem “Axis-Angle”-Modus anschauen, im nächsten Teil betrachten wir dann die Drehung um eine Achse mit dem mit Quaternionen und anschließend die Drehung mit Eulerschen Winkeln. Am Ende dieses Tutorials könnt ihr

  • Drehachsen berechnen,
  • Objekte auswählen und aktiv setzen und
  • Objekte um eine Drehachse um einen Winkel drehen.
Screenshot Rotationsergebnis

Screenshot Rotationsergebnis

Continue reading

Posted in Code-O-Matic, Graphic-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 , .