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>

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

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