Dev-Talk (PSI)

<root> <div class='right_side_navigation' style='width:156px;position:fixed;bottom:50px;background-color:#efefef;border-color:#bbbbbb;border-width:1pt;border-style:solid;padding:1px 2px;font-size:8pt;text-align:center;filter:alpha(opacity=90);-moz-opacity: 0.9;opacity: 0.9;'> Navigation (PSI)<br> Hauptseite (alt)<br> Hauptseite (Endspurt)<br> recent changes<br> Alle Seiten

Development<br> Endspurt<br> Dev-Talk<br> ChangeLog<br> Repository<br> Global Mindset V4<br /> Szenariosammlung<br /> Projekt-Präsentation

</div><ignore><includeonly></ignore><ignore></includeonly></ignore></root>

Arbeitsteilung

schlage vor, dass wir, um Bearbeitungskonflikten weitgehend aus dem Weg zu gehen, unsere Arbeit hier ein bisschen koordinieren - wer arbeitet gerade an welchen Abschnitten und zu welchem Zeitpunkt? --Thai 18:56, 1. Jun. 2009 (UTC)

Thai derzeit noch keine konkreten Kapitel werde mich um die regelmäßige Aktualisierung von Volume 0 (Topographie) kümmern möchte mich vor allem mit den Conversation Extensions auseinandersetzen Cheatsheet dafür bereits in Arbeit... Implementierung der Junge/Wächterin-Szene evtl. Zentralisierung von Actions? Weiterentwicklung des Eingabe-Interfaces

H.A.L. momentan nix konkretes Intoxication (Book 2) verfeinern, aber erst wenn Book 4 / 5 stehen

Andyk Arbeite an Book 4 und 5 (Crowd und Menü; wie gehabt)

who else? ...

Vielleicht könnten wir auch das hier revitalisieren, wenn jemand Lust hat.--Andyk 22:04, 1. Jun. 2009 (UTC)

Wäre eine Idee, aber dann müßten wir es mal überarbeiten (an die tatsächliche Arbeitsteilung anpassen).

Sollte man unbedingt machen - ich glaube, wir verlieren auch gerade wertvolle Zeit, weil die Nicht-Geeks nicht so recht wissen, wie sie sich einbringen können. Da wären klare Arbeitsaufträge und -einteilungen sinnvoll. Obige Tabelle ist dafür gedacht, dass die Programmierer sich (intern) darüber am Laufenden halten, woran sie gerade arbeiten (oder noch arbeiten wollen)... --Thai 20:38, 2. Jun. 2009 (UTC)

Build 33

• Code
• Diff

Habe die dynamische Veränderung der Tabellengröße nun vermieden und beginne einfach mit einer großen Tabelle die ich bei jeder Mengenänderung lösche und neu auffülle. Dynamisch die Größe von Tabellen zu ändern ist in Inform mit viel Berechnungaufwand verbunden. Jetzt kommt man mit dem klassisch reservierten Speicherbereich (von Z5 ab Build 41: Z8) aus.

Als nächstes werde ich die Sicht von Gyges auf die Tabelle einschränken, je nachdem, welche Fähigkeit er hat. Die Fähigkeit hängt von der Punktezahl (also von bereits erfolgreichen Diebstahl-Aktionen,etc.) ab. (Ansatz kann man bereits durch die Table of Abilities sehen oder wenn man den Text von x crowd genauer anschaut; dort findet sich auch ein God-Mode, vielleicht kann an irgendwo ein EasterEgg einbauen, wo dieser aktiviert wird. Wennn man fleißig ist, kann man aber auch 999 Punkte schaffen ^^). Bugs bitte melden oder gleich korrigieren - jetzt weiß ich ja, dass ich mit Updates rechnen kann.

Also doch der Ring :-) - Ich hab mal eine kleine Vorlage fürs Generieren von Personen reingestellt, sind die Parameter da so richtig?Die Ring-Option als streng geheimes undokumentiertes feature, genau ^^. --Andyk 14:38, 29. Mai 2009 (UTC)

Was dann kommt, ist wahrscheinlich ein Menübasierter Ansatz, wo man basierend auf der beobachtenden Menge versucht, sich auf ein bestimmtes "Opfer" zu konzentrieren und bestimmte Tätigkeiten versuchen kann (Betteln, Rucksack aufschneiden, Ablenkungsmanöver, Drängen und Geldbörse schnappen, ...). Interessant werden noch die gestohlenen Gegenstände selbst werden, da sie zu Spielbeginn nicht erstellt sind und nur in Form von Beschreibungen in den Tabellen enthalten sind. Das heißt, ich muss sie dynamisch erstellen. Rechenaufwand wird wenig dahinter stecken, da man ja immer nur ein "Opfer" bestiehlt, bedroht, anbettelt, etc. Aber Dynamic Object benötigt GLULX und ich weiß nicht, ob Parchment das unterstützt. --Andyk 23:13, 28. Mai 2009 (UTC)

Also, ich hab mich eben an einer originelleren Erfolgsmeldung versucht, da könnte es ein Problem geben: Wenn die Rückmeldung beschreibt, was geschieht, müßte die Meldung unterschiedlich sein, je nachdem, ob ich den Rucksack aufschneide oder nach der Börse greife. Die Meldungen müßten also weniger von der Person abhängen als von der Tätigkeit - bzw. überhaupt dynamisch generiert werden. --H.A.L. 12:05, 29. Mai 2009 (UTC)

Ich habe befürchtet, dass so etwas passieren wird, da die Implementierung noch nicht fertig ist und es schwer ist konkrete Anweisungen zu geben, wenn der Diebstahl-Mechanismus noch nicht feststeht. Ich hoffe, ich kann bald eine Demonstration liefern. Die allgemeine Frage ist, ob wir mehrere Tätigkeiten zulassen, oder ob es nur eine Tätigkeit gibt "Diebstahl". Wenn es mehrere Tätigkeiten gibt, dann brauchen wir pro Tätigkeit zwei Rückmeldungen (Erfolg und Nicht-Erfolg), was leicht komplex werden kann, wenn man die Rückmeldung in Bezug auf die konkreten Personenbeschreibungen formuliert. Drei Möglichkeiten, die mir unmittelbar einfallen:

• Vielleicht, da der Schwerpunkt der Story nicht nur im Diebstahl liegt, können wir uns mit einer Tätigkeit zufrieden geben, dafür die Rückmeldungen konkret zur Personenbeschreibung verfassen. (Dann müsste man die Formulierungen deiner Vorlage entsprechend machen).
• Oder man führt noch ein paar "Opfer"-Typen (also nicht nur ShyVictim, AggressiveVictim, ...) ein und bindet die Rückmeldungen an den Typen UND der konkreten Tätigkeit. In diesem Fall würde man eine Tabelle mit den Spalten (VictimType, Tätigkeitstyp, Erfolgsmeldung, Misserfolgsmeldung) haben und eine Tabelle mit den konkreten Personenbeschreibungen. Hier verliert man aber ein bisschen den Fun-Faktor, weil man bei der Rückmeldung nicht mit den inhaltlichen Personenbeschreibungen spielen kann, sondern seine Formulierung auf abstrakte Opfer-Typen beziehen muss.
• Die inhaltlich aufwändigste Methode ist, pro mögliche Tätigkeit, die man auf die konkrete Person anwenden kann, die Rückmeldungen zu formulieren. Dazu müsste man eine Personen-Identifiaktionsnummer einführen. Das bedeutet, man hat drei Tabellen:

Person_ID - Personen_Beschreibung

und dann:

Person_ID - Tätigkeitstyp - Erfolgsmeldung - Misserfolgsmeldung

und eventuell die Tabelle, unter welchen Umständen eine Tätigkeit ausgeführt werden kann:

Tätigkeitstyp - Fähigkeit (von Gyges) - benötigt_Gegenstand_im_Inventar

Je nachdem, wie viele verschiedene Tätigkeiten man für seine konkrete Person vorsehen will, muss man auch die Erfolgs- und Misserfolgsmeldungen formulieren. (Es sollte technisch übrigens möglich sein, bestimmte Tätigkeiten für alle Opfertypen zuzulassen, dann kann man die Personen-ID freilassen und muss für diese nur allgemeine Erfolgs- und Misserfolgsmeldungen schreiben.)

• Als 4. Option könnten die Rückmeldungen überhaupt in Bezug auf den Tätigkeitstyp formuliert werden, wobei man auch hier den Fun-Faktor verlieren würde, dass sich die Rückmeldungen nicht auf die konkrete Personenbeschreibung beziehen.

Mir gefällt die dritte (also die inhaltlich aufwändigste) Alternative am Besten, auch wenn dadurch die Tabelle ziemlich groß wird (aber reiner Text ist technisch normalerweise kein Problem). Würde die Sache gerne so abändern, wenn ihr einverstanden seid? (außer es fällt jemanden noch etwas ein, wie man es noch flexibler haben könnte...). Die Situation ist im Moment etwas blöd, da ja einige von uns schon die Aufgabe haben, bestimmte Beschreibungen für die Diebstähle zu formulieren. Werde mich bemühen, meinen Vorschlag baldigst zu implementieren um zu sehen, was für mich möglich bzw. zu zeitaufwändig ist. --Andyk 14:38, 29. Mai 2009 (UTC)

Build 43

• Code
• Diff mit 33

Die Sicht von Gyges auf die Tabelle ist nun eingeschränkt und der examine crowd-Befehl von Debug-Meldungen befreit und verschönert. Ein paar Bugs zwischen den beiden Builds sind auch behoben (eher ein Work-Around bei der Endlosschleife, wenn es zu wenig Beschreibungen gibt; für einen soliden Code muss am Auswahlverfahren und der Zuordnung der Personenbeschreibung zu den Opfertypen noch etwas geändert werden.) Die Tabellen sind nun entsprechend Option 3 gestaltet. Ich werde eventuell noch eine Seite machen, wo man die Beschreibungen direkt eintragen kann, wenn ich 100% sicher bin, dass die dynamische Erstellung der Gegenstände wie gewünscht funktioniert. (Es wäre schön ca. 50 - 70 Personenbeschreibungen zu haben. Pro Person mindestens eine Tätigkeit und dann pro Tätigkeit 2 Rückmeldungen.) Ich habe auch begonnen, den Menübasierten Ansatz zu implementieren. Hilfreich war mir dabei auch der Extension-Code Menus von Emily-Short.

In nächster Folge werde ich die Menüeinträge dynamisch erstellen, sobald die beobachtenden Individuen der Menge feststehen. Genauso wird das für die Tätigkeits-Einträge gehen. Es ist wieder ein God-Mode vorgesehen (wobei die Freischaltung noch nicht klar ist), wo man explizit die Erfolgs-Wahrscheinlichkeit sieht, die eine bestimmte Tätigkeit (z.B. Rücksack aufschneiden) für eine bestimmte Person hat.

Wenn das funktioniert, geht es an das Herzaubern der Objekte, damit sie bei Erfolgreichem Diebstahl / Betteln ins Inventar von Gyges gelangen. Wenn das nicht geht, wird das Standard-Inventar dran glauben müssen, was ich nicht hoffe.

Bug-Report, Vorschläge, Änderungen erwünscht. --Andyk 18:32, 30. Mai 2009 (UTC)

Den VictimType finde ich jetzt ein wenig konfus, da er einerseits für die Erfolgswahrscheinlichkeit da ist und andererseits als Beschreibung konkreter Personen.

Mit dem VictimType bin ich momentan auch noch überhaupt nicht zufrieden. Er wird ja zur Zeit einfach zufällig an die konkreten Personen verteilt, was ein bisschen damit crashed, dass die Bewältigung eines schwierigen Gegeners mit wertvollen Items belohnt wird, wie du sagst. Die Definition eines schwierigen Gegners: Mit wenig Fähigkeiten (oder zusätzlichen Gegenständen) ist es höchst unwahrscheinlich, dass der Diebstahl oder eine andere Tätigkeit fehlschlägt. ---Andyk 18:29, 31. Mai 2009 (UTC)

Ahja... Ich dachte, das ist dafür da, daß Beschreibungen zufällig mit Schwierigkeitsgraden kombiniert werden, um der Abwechslung willen. Einer Person einen Schwierigkeitsgrad fix zuteilen wäre eine Alternative. Der Erfolg könnte definiert werden durch Schwierigkeitsgrad des Opfers (VictimType) + Fähigkeitsgrad von Gyges + Erfolgswahrscheinlichkeit einer Handlung (bzw. könnten verschiedene Handlungen bei verschiedenen Opfern unterschiedlich schwer sein) + Zufallsfaktor. Also (victim_difficulty + experience + action_difficulty + random_number)/4 oder (action_difficulty_for_victim + experience + random_number)/3.

Zum zufälligen Kombinieren gibt es ein Beispiel im Inform-Manual, No. 165 "Uptown Girls". Dort wird jeweils eine einzelne Person generiert, indem zufällige Werte für drei Properties (Haarfarbe, Größe, Frisur) generiert werden. Allerdings ist jeder Kombination von Werten ein Tabelleneintrag zugeordnet, also müssen im Prinzip alle Leute im Voraus beschrieben werden. (Das ist nicht anders, als wenn man 27 distinkte Personen definiert, von denen jede mit einer Wahrscheinlichkeit von 1:26 auftritt.)

Meine Vorstellung war eigentlich: Auf der einen Seite ist eine Liste mit Personenbeschreibungen, denen Gegenstände, Erfolgs/Mißerfolgsmeldungen und z.T. mögliche Handlungen fix zugeschrieben werden (ob die Handtasche aus pinkem Plastik oder aus braunem Leder ist, hängt davon ab, ob es eine ältere Dame oder ein hipper Student in ausgefallenen Klamotten ist; verschiedene Leute reagieren unterschiedlich auf Diebstahlsversuche, und die Handtasche kann ich nur aufschneiden, wenn die Person eine trägt), auf der anderen Seite die Erfolgswahrscheinlichkeit - ich habe an attentiveness gedacht - als numerische Variable, die bei der crowd-generation zufällig zugewiesen wird.

Momentan habe ich die Tabellen so angelegt, dass die Erfolgswahrscheinlichkeit hauptsächlich von der Tätigkeit abhängt. Sie wird aber moduliert von dem Einfluss, den der "Opfer"-Typ ausübt (in der VictimType-Table die Spalte impact).---Andyk 18:29, 31. Mai 2009 (UTC)

Momentan gibt es irgendwie einen Victim_Type "eating" und eine Beschreibung einer Pizza, und die sind syntaktisch völlig voneinander unabhängig. Obwohl es andererseits natürlich Sinn macht, daß die wertvollen Dinge (Macbook) an die schweren VictimTypes gebunden sind. Das Dumme ist wohl, daß hier der Aufstieg von billigen zu teuren Items mit dem Zufallsprinzip nicht recht vereinbar ist.

Dafür müsste man zur Personenbeschreibung den VictimType fix angeben. Wenn man für eine Personenbeschreibung findet, dass sie für mehrere Victim-Types passt, lässt man Victim-Type frei (also --) und er wird zufällig gewählt. ---Andyk 18:29, 31. Mai 2009 (UTC)

Dazu könnte man eine range angeben, also eine min_difficulty und eine max_difficulty, für den eigentlichen diebstahl wird eine Zufallszahl zwischen den beiden Werten erwürfelt.

Was die Brieftasche angeht, so kann man ihr Aussehen an die Person_ID und den Inhalt an die Erfolgswahrscheinlichkeit koppeln. An den Anfang einen Essensdiebstahl zu setzen, ist nicht unbedingt nötig (Gyges weiß ja auch, wenn er hungrig ist, daß man für Geld Essen kaufen kann).

Beim Essensdiebstahl war mir wichtig, dass eine Person, die wirklichen Hunger leidet, ihre Wahrnehmung nicht auf Wertgegenstände oder das Aussehen von Personen richtet, sondern schaut, wo es was zu essen gibt. Da geht es gar nicht so sehr ums Stehlen, sondern eher ums Betteln. ---Andyk 18:29, 31. Mai 2009 (UTC)

Gut, so kann man das natürlich auch sehen.

Was die Beutestücke angeht, so kann man nie wissen, welches Großmütterchen zum Clan gehört oder mit einem Macbook in der Tasche herumläuft. Das kann man als Schönheitsfehler betrachten oder als chaotisches Element. Ansonsten bräuchte man eine Tabelle aus verschiedenen Preisstufen kombiniert mit verschiedenen Kategorien von Wertgegenständen, wobei ersteres von der Erfolgswahrscheinlichkeit abhängt und zweiteres von der Charakterisierung des Opfers (die eine hat Notebooks verschiedener Preislagen, der andere vielleicht Familienschmuck). Das hieße, daß wir die Personenbeschreibungen in Kategorien einteilen müßten.

Durch Victim-Type sind die Personen ja prinzipiell in Kategorien eingeteilt, oder meinst du das anders? ---Andyk 18:29, 31. Mai 2009 (UTC)

Im wesentlichen meinte ich, daß - statt der Table of Spoil Articles - der Article_Name mit der Beschreibung verknüpft wird und der Money_Value mit dem VictimType. (Welche Sachen jemand mit sich herumträgt, gehört zur Charakterisierung einer Person - ein MacBook paßt nicht zu allen -, der Wert dagegen eher zur Schwierigkeit.) Dann müßten wir aber die Beschreibungen in Gruppen fassen, wenn wir nicht so viele Beutestücke wie Leute erfinden wollen. Einige haben ein Notebook, andere ein Juwel, andere eine Münze,... Wenn wir den VictimType fest mit der Beschreibung verbinden, ist das aber auch hinfällig.

Ich würde ja ein einfaches und gleichmäßiges Schema vorziehen, Sonderfeatures - Aktionen, für die man bestimmte Gegenstände braucht oder Kooperation - könnte man in einzelne Personen zusätzlich implementieren.

Bei Kooperation stimme ich dir zu, das ist schwer automatisierbar und so viele Diebstahl-Akte wollen wir nun auch wieder nicht produzieren (Es tut mir leid, der vorliegende Code ist eh schon viel zu viel auf Diebstahl konzentriert - wir haben ja noch viele andere Dinge, die zu implementieren sind. )---Andyk 18:29, 31. Mai 2009 (UTC)

Ich tendiere ja auch dazu, den zeitungslesenden Gast als einen Sonderfall von Victim zu sehen, dessen Erfolgswahrscheinlichkeit zunächst fast null ist (ausnahmsweise nicht zufällig zugewiesen, sondern hardcoded), der aber ein Zusatzfeature eingebaut hat (die Property drunk/sober und das Arrangement mit den Getränken), mit der man die attentiveness und damit die Erfolgswahrscheinlichkeit manipulieren kann. Der Gast wäre sozusagen seine eigene Unterklasse von VictimType.

Übrigens ist in #37 (Z. 324) ein Fehler wieder aufgetaucht, den ich in #36 korrigiert hatte (habe ich in #44 wieder ausgebessert). --H.A.L. 16:57, 31. Mai 2009 (UTC)

Hm, ganz funktioniert das mit dem Mergen anscheinend noch nicht, oder ich hab es einfach übersehen. ---Andyk 18:29, 31. Mai 2009 (UTC)

Eigenartig. --H.A.L. 22:12, 31. Mai 2009 (UTC)

Build 46

--Thai 21:23, 1. Jun. 2009 (UTC)

Wie angekündigt habe ich mich am Wochenende hingesetzt und meinen bescheidenen Versuche von zuvor, nunja, ähm, etwas erweitert. Ich denke, das Ergebnis kann uns nützlich sein. Ob es uns jemals so viel Zeit ersparen wird, wie von mir investiert wurde, ist zwar fraglich, aber dafür bin ich jetzt mit der großartigen Semantic MediaWiki-Extension einigermaßen vertraut. Am besten, ihr seht euch das ganze einmal an, die vorläufige Version findet sich hier

Ihr könnt dort erkennen, dass ich die gesamte Topographie (und unter diesen Begriff habe ich frech auch Personen subsumiert) des bisher vorhandenen Source-Codes in Wiki-Pages übersetzt habe, wobei jeder Gegenstand (und jeder Abschnitt und das Spiel selbst) eine eigene Seite hat und der inform-code automatisch durch Vorlagen generiert wird, aus Daten - und das ist das Tollste - die über Formulare eingegeben werden können. Mit SMW kann man aus einem wiki also eine richtige Datenbank machen. Ich werde versuchen, das ganze Ding im Laufe der Woche ins philo-wiki zu importieren, einstweilen müsst ihr euch zum Ausprobieren in meinem wiki registrieren, aber das geht schnell und tut nicht weh.

Wozu die ganze Arbeit? Erstens kann es die Entwicklung erleichtern, weil man sich die Befehle nicht zu merken braucht, manche Zusammenhänge und alle möglichen Parameter für ein Objekt sofort ersichtlich sind, Namen von Objekten automatisch ergänzt werden, ... Außerdem aber - und wichtiger: es simplifiziert die Zusammenarbeit von Codierern und Content-Erstellern und verhindert diverse Bearbeitungskonflikte schon im Vorfeld. Die Entwickler kennzeichnen Objekte, denen noch eine Beschreibung fehlt, oder die noch geändert werden sollten, die Textarbeiter führen diese Änderungen durch, wann immer es ihnen gefällt. In regelmäßigen Abständen wird einfach das gesamte Book 0 (in dem alle topographischen Informationen zentral gespeichert sind) durch den aktualisierten code aus dem wiki ersetzt, ein mühsames copy&paste mit einzelnen neu zur Verfügung gestellten Textstücken wird damit überflüssig.

Find ich toll, vor allem wissen dann die Content-Ersteller gleich, welches Objekt welche Eigenschaften haben soll, ohne sich mit der Technik herumschlagen zu müssen.

Ausblick: vielleicht ist auch eine Erweiterung auf andere Code-Bestandteile möglich und sinnvoll? Eventuell für Actions, und ganz bestimmt für Konversationen, denn insbesondere da steckt viel kreative Textarbeit drin...

Hm. Eine menübasierte Konversation funktioniert ja anders als ein Objekt, sie hat eine Baumstruktur und nicht ein fixes Set von properties. - Man müßte ein Formular für jeden Node anlegen, mit einem Haupttext (die Aussage des Gegenübers) und 1-n Antwortmöglichkeiten, von denen jede einen Text und die Verbindung zum nächsten Node hat. Bei Actions bin ich mir jetzt nicht sicher, ich denke, das geht nur im Übergang von freier Beschreibung zum Programmieren.

In Bezug auf die Actions ginge es einerseits wieder darum, den Entwicklern die Arbeit zu erleichtern (weil man im Formular alle nötigen Informationen über Action-Definitionen unterbringen kann). Natürlich können die Content-Ersteller hier nicht selbst Actions erstellen, weil man dafür inform sprechen muss, aber andererseits können sie beispielsweise den Text in say-Phrasen ergänzen, kleine Fehler ausbessern oder Todos für die Entwickler erstellen, wenn ihnen beim Testen auffällt, dass etwas nicht klappt oder fehlt. Eine Einschränkung ist allerdings, dass es im wiki keine Tabulatoren gibt - wir müssten uns also das explizite Programmieren mit begin und end angewöhnen. Was die Konversationen anbelangt, bin ich recht zuversichtlich, das irgendwie hinzukriegen. Obwohl das Conversation Package (mit der Möglichkeit, Gesprächsknoten und jeweils Standardantworten und Themenvorschläge für sie bzw. für Personen zu definieren), das ich gerne verwende möchte, noch mal komplexer ist als bloße menübasierte Konversation.

Freue mich über Kommentare, ich kann das Ganze ja dann am Donnerstag ausführlicher vorführen.

übrigens: Diese Seite hat jetzt dank magic word oben ein "+" neben "Bearbeiten" - ganz wie eine "echte" Talk-Page. Damit kann man automatisch einen neuen Abschnitt am Ende der Seite erzeugen

Das ist ja fein, das könnten wir für das ganze Wiki brauchen. Läßt sich die Funktion generell in das Seiten-Template einbauen, oder zumindest in die Vorlage? --H.A.L. 15:25, 2. Jun. 2009 (UTC)

Ob und wie sich die Funktion für das ganze Wiki einstellen lässt, weiß ich leider auch nicht - Seiten, die die Vorlage PSI einbinden haben jedenfalls ab sofort das gewisse Plus.

Beeindruckend

Ich bin erstaunt von der Schönheit dieser Konstruktion! Ich hab es mir bis jetzt nur kurz angesehen, bin aber schon voll begeistert; das ist die ideale Verbindungsbrücke zwischen Content und Code. Es freut mich außerdem doppelt, weil die Rahmenstruktur-Tabellen dadurch nicht gänzlich unnötig sind ^^. (Bitte meine Testtür löschen; wollte nichts kaputt machen, indem ich die Einträge aus den Formularfeldern entferne, also hab ich sie mal drinnen gelassen). Freu mich auf die Demonstration am Donnerstag und hoffe, dass es fleißig verwendet wird. THX für die Mühe!

Achja, ich habe eine theoretische Frage: Wenn wir den Topographie-Source-Code direkt in der Entwicklungsumgebung ändern müssten, können wir den anschließend ins SMW reinspielen? Oder muss man dazu bestimmte Kennzeichnungen im Source-Code vornehmen, damit die Ontologie erkannt wird? --Andyk 22:39, 1. Jun. 2009 (UTC)

Wie wir das im Detail regeln, müssen wir uns noch ansehen. Mein Vorschlag wäre ein eigenes Book 0.1 einzurichten, in dem ad hoc Änderungen an der Topographie durchgeführt werden können. Diese würde ich dann vor jedem Update ins wiki übertragen (todos können dabei einfach als Kommentare angemerkt werden). Alles, was in Book 0 steht, wird jeweils rücksichtslos mit dem code aus dem wiki überschrieben. Um vollkommen neue Objekte zu erstellen, wäre sinnvoll, das jeweilige wiki-Formular zu verwenden, und nur den Code der Objektseite ins Book 0 zu kopieren (egal wohin - die Ordnung wird beim nächsten Update wiederhergestellt). --Thai 07:33, 2. Jun. 2009 (UTC)

Hey, Thai. Wie ich sehe, hast du am SVN-Repository was committed; ich vermute, die source.ni-Datei hätte sich auch verändern sollen, was sie aber nicht hat. Kannst du das nochmal gegenprüfen und neu committen. Ich warte so lange mit meinen Änderungen. --Andyk 18:25, 2. Jun. 2009 (UTC)

Danke für den Hinweis! Es scheint so, als würde die mac-Version der inform-Entwicklungsumgebung die .svn-Dateien in einigen Unterverzeichnissen der inform-Datei beschädigen, diese erscheinen dann als nicht versioniert und werden nicht mehr upgedatet. Ist aber nicht weiter tragisch, zweimal copy&paste (aus story.ni in die lokale inform-Datei und wieder zurück) und alles ist in Butter. Werde halt in Zukunft nichts mehr zum Skein beitragen, aber damit wird man wohl leben können ;)

WIRKLICH TOLL! anna 14:40, 2. Jun. 2009 (UTC)

Build 50

• So, ich habe schonmal angefangen zu arbeiten. Nurmal so, weil ich es grad instruktiv fand ein Output der Debug-Meldungen, wie der Algorithmus arbeitet, wenn er die Personen für die Menge erstellt:

DEBUG: Add Person #1 with type EatingVictim (VTID: 1).
DEBUG: Add Person #2 with type EatingVictim (VTID: 1).
DEBUG: Add Person #3 with type EatingVictim (VTID: 1).
DEBUG: Add Person #4 with type EatingVictim (VTID: 1).
DEBUG: Add Person #5 with type EatingVictim (VTID: 1).
DEBUG: Add Person #6 with type EatingVictim (VTID: 1).
DEBUG: Add Person #7 with type EatingVictim (VTID: 1).
DEBUG: Add Person #8 with type EatingVictim (VTID: 1).
DEBUG: Add Person #9 with type EatingVictim (VTID: 1).
DEBUG: Add Person #10 with type EatingVictim (VTID: 1).
DEBUG: Add Person #11 with type EatingVictim (VTID: 1).
DEBUG: Add Person #12 with type EatingVictim (VTID: 1).
DEBUG: Add Person #13 with type EatingVictim (VTID: 1).
DEBUG: Add Person #14 with type EatingVictim (VTID: 1).
DEBUG: Add Person #15 with type EatingVictim (VTID: 1).
DEBUG: Add Person #16 with type EatingVictim (VTID: 1).
DEBUG: Add Person #17 with type EatingVictim (VTID: 1).
DEBUG: Add Person #18 with type EatingVictim (VTID: 1).
DEBUG: Add Person #19 with type EatingVictim (VTID: 1).
DEBUG: Add Person #20 with type EatingVictim (VTID: 1).
DEBUG: Add Person #21 with type EatingVictim (VTID: 1).
DEBUG: Add Person #22 with type EatingVictim (VTID: 1).
DEBUG: Add Person #23 with type EatingVictim (VTID: 1).
DEBUG: Add Person #24 with type EatingVictim (VTID: 1).
DEBUG: Add Person #25 with type EatingVictim (VTID: 1).
DEBUG: Add Person #26 with type EatingVictim (VTID: 1).
DEBUG: Add Person #1 with type ShyVictim (VTID: 2).
DEBUG: Add Person #2 with type ShyVictim (VTID: 2).
DEBUG: Add Person #3 with type ShyVictim (VTID: 2).
DEBUG: Add Person #4 with type ShyVictim (VTID: 2).
DEBUG: Add Person #5 with type ShyVictim (VTID: 2).
DEBUG: Add Person #6 with type ShyVictim (VTID: 2).
DEBUG: Add Person #7 with type ShyVictim (VTID: 2).
DEBUG: Add Person #8 with type ShyVictim (VTID: 2).
DEBUG: Add Person #9 with type ShyVictim (VTID: 2).
DEBUG: Add Person #10 with type ShyVictim (VTID: 2).
DEBUG: Add Person #11 with type ShyVictim (VTID: 2).
DEBUG: Add Person #12 with type ShyVictim (VTID: 2).
DEBUG: Add Person #13 with type ShyVictim (VTID: 2).
DEBUG: Add Person #14 with type ShyVictim (VTID: 2).
DEBUG: Add Person #15 with type ShyVictim (VTID: 2).
DEBUG: Add Person #16 with type ShyVictim (VTID: 2).
DEBUG: Add Person #17 with type ShyVictim (VTID: 2).
DEBUG: Add Person #18 with type ShyVictim (VTID: 2).
DEBUG: Add Person #19 with type ShyVictim (VTID: 2).
DEBUG: Add Person #20 with type ShyVictim (VTID: 2).
DEBUG: Add Person #21 with type ShyVictim (VTID: 2).
DEBUG: Add Person #22 with type ShyVictim (VTID: 2).
DEBUG: Add Person #23 with type ShyVictim (VTID: 2).
DEBUG: Add Person #24 with type ShyVictim (VTID: 2).
DEBUG: Add Person #25 with type ShyVictim (VTID: 2).
DEBUG: Add Person #26 with type ShyVictim (VTID: 2).
DEBUG: Add Person #27 with type ShyVictim (VTID: 2).
DEBUG: Add Person #28 with type ShyVictim (VTID: 2).
DEBUG: Add Person #29 with type ShyVictim (VTID: 2).
DEBUG: Add Person #30 with type ShyVictim (VTID: 2).
DEBUG: Add Person #31 with type ShyVictim (VTID: 2).
DEBUG: Add Person #32 with type ShyVictim (VTID: 2).
DEBUG: Add Person #33 with type ShyVictim (VTID: 2).
DEBUG: Add Person #34 with type ShyVictim (VTID: 2).
DEBUG: Add Person #35 with type ShyVictim (VTID: 2).
DEBUG: Add Person #36 with type ShyVictim (VTID: 2).
DEBUG: Add Person #1 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #2 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #3 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #4 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #5 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #6 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #7 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #8 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #1 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #2 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #3 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #4 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #5 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #6 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #7 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #1 with type BusyStudent (VTID: 5).
DEBUG: Add Person #2 with type BusyStudent (VTID: 5).
DEBUG: Add Person #3 with type BusyStudent (VTID: 5).
DEBUG: Add Person #4 with type BusyStudent (VTID: 5).
DEBUG: Add Person #5 with type BusyStudent (VTID: 5).
DEBUG: Add Person #6 with type BusyStudent (VTID: 5).
DEBUG: Add Person #7 with type BusyStudent (VTID: 5).
DEBUG: Add Person #8 with type BusyStudent (VTID: 5).
DEBUG: Add Person #9 with type BusyStudent (VTID: 5).
DEBUG: Add Person #10 with type BusyStudent (VTID: 5).
DEBUG: Add Person #11 with type BusyStudent (VTID: 5).
DEBUG: Add Person #12 with type BusyStudent (VTID: 5).
DEBUG: Add Person #13 with type BusyStudent (VTID: 5).
DEBUG: Add Person #14 with type BusyStudent (VTID: 5).
DEBUG: Add Person #15 with type BusyStudent (VTID: 5).
DEBUG: Add Person #16 with type BusyStudent (VTID: 5).
DEBUG: Add Person #17 with type BusyStudent (VTID: 5).
DEBUG: Add Person #18 with type BusyStudent (VTID: 5).
DEBUG: Add Person #1 with type ShyVictim (VTID: 2).
DEBUG: Add Person #2 with type ShyVictim (VTID: 2).
DEBUG: Add Person #3 with type ShyVictim (VTID: 2).
DEBUG: Add Person #4 with type ShyVictim (VTID: 2).
DEBUG: Add Person #5 with type ShyVictim (VTID: 2).
DEBUG: Add Person #6 with type ShyVictim (VTID: 2).
DEBUG: Add Person #7 with type ShyVictim (VTID: 2).
DEBUG: Add Person #8 with type ShyVictim (VTID: 2).
DEBUG: Add Person #9 with type ShyVictim (VTID: 2).
DEBUG: Add Person #10 with type ShyVictim (VTID: 2).
DEBUG: Add Person #11 with type ShyVictim (VTID: 2).
DEBUG: Add Person #12 with type ShyVictim (VTID: 2).
DEBUG: Add Person #1 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #1 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #2 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #1 with type BusyStudent (VTID: 5).
DEBUG: Add Person #2 with type BusyStudent (VTID: 5).
DEBUG: Add Person #3 with type BusyStudent (VTID: 5).
DEBUG: Add Person #4 with type BusyStudent (VTID: 5).
DEBUG: Add Person #5 with type BusyStudent (VTID: 5).
DEBUG: Add Person #6 with type BusyStudent (VTID: 5).
DEBUG: Add Person #7 with type BusyStudent (VTID: 5).
DEBUG: Add Person #8 with type BusyStudent (VTID: 5).
DEBUG: Add Person #1 with type Clanmember (VTID: 7).
DEBUG: Add Person #1 with type ShyVictim (VTID: 2).
DEBUG: Add Person #2 with type ShyVictim (VTID: 2).
DEBUG: Add Person #3 with type ShyVictim (VTID: 2).
DEBUG: Add Person #1 with type IntractableVictim (VTID: 3).
DEBUG: Add Person #1 with type BusyStudent (VTID: 5).
DEBUG: Add Person #2 with type BusyStudent (VTID: 5).
DEBUG: Add Person #3 with type BusyStudent (VTID: 5).
DEBUG: Add Person #4 with type BusyStudent (VTID: 5).
DEBUG: Add Person #5 with type BusyStudent (VTID: 5).
DEBUG: Add Person #1 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #1 with type ShyVictim (VTID: 2).
DEBUG: Add Person #2 with type ShyVictim (VTID: 2).

Da sich die Erscheinungswahrscheinlichkeiten der einzelnen Typen auf einmalige Ereignisse beziehen (das bedeutet: Wenn ich aus einer Menge von Leuten eine Person raus nehme, wie wahrscheinlich ist es, dass diese Person vom Typ t ist?), wird so vorgegangen:

• 1. Bestimme die Absolute Anzahl der Mitglieder der Menge (csize)
• 3. Fixiere einen Opfer-Typ t und hol dir die Auftrittswahrscheinlichkeit p.
  • 3a. Erstell dir eine binäre Zufallsvariable (JA/NEIN), wobei JA die Wahrscheinlichkeit p zugeordnet wird (daraus folgt, dass NEIN die Wahrscheinlichkeit 100 - p bekommt).
  • 3b. Würfle mit dieser Zufallsvariable, und das csize mal. Du erhältst dadurch die absolute Anzahl der Leute von Typ t in der Menge, nennen wir sie abs_t.
  • 3c. Subtrahiere abs_t von csize, und du erhältst einen neuen Wert von csize.
  • 3d. Such dir in der Tabelle der Personenbeschreibungen zufällig jemanden raus, der als Typ t charakterisiert wird oder dem kein bestimmter Typ zugewiesen ist (Ausnahme: Wenn Personen von Typ "eatingVictim" gesucht werden, dann muss die Personenbeschreibung genau passen. Denn in der Personenbeschreibung wird sowas stehen wie: "Der isst gerade eine Pizza". Natürlich muss man die Personenbeschreibungen von Leuten die essen, genau dem Typ "eatingVictim" zuweisen. Man kann sich auch vorstellen, noch andere Ausnahmen einzutragen). Jetzt hast du eine Person gefunden, die du der Menge zuweist (Eintrag in die Mengentabelle).
  • 3e. Wiederhole das abs_t mal.
• 4. Wiederhole Schritt 3a-e solange, bis csize 0 ist. Das bedeutet, man geht die einzelnen Typen solange durch, bis für jeden Platz in der Menge eine konkrete Personenbeschreibung zugewiesen wurde.

(Ich hatte bis zuletzt übrigens einen Fehler, weil ich Schritt 3e vergessen habe).

Werde mich jetzt mal um die Konsistenz der Versionen kümmern - befürchte Schreckliches. UPDATE: Gelobt sei SVN; Auto-Merge mit einem Mausklick auf Update; das erste Mal, dass es so einfach funktioniert. (Habe im Topographie-Bereich die Reihenfolge zwischen Money und VictimType verändert, hoffe das ist nicht schlimm?) --Andyk 22:19, 2. Jun. 2009 (UTC)

DEBUG: Die Option theft_of_food mit Text 
Stehle dem Opfer das Essen. ist für 
die Person yourself erlaubt, da 
die Person nothing hat und 
im Grad Survival ist.