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 .

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

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

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

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