Dev-Talk Archiv (PSI)

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 #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 #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 #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 #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 #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 #1 with type Clanmember (VTID: 7).
DEBUG: Add Person #1 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 #1 with type AggressiveVictim (VTID: 4).
DEBUG: Add Person #1 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. (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.

Einige Hinweise, wie die crowd-Erstellung vielleicht noch vereinfacht werden könnte (obwohl es vielleicht eh überflüssig ist, weil das javascript-Vorkompilieren den nötigen Geschwindigkeits-Boost bringt):

• erstens: wenn ich recht verstanden habe, errechnest du die gesamte crowd, obwohl der Spieler ohnehin nur einen Teil davon sehen kann und nur mit diesem Teil weitergearbeitet wird

korrekt, das habe ich mir auch schon mal gedacht, dass es nicht unbedingt nötig wäre. War bislang nur zu faul, um es zu ändern. Kleine Erklärung dazu: Die Sache ist damals gewachsen, da ich zunächst nicht vor hatte, die Sicht der Spielerin einzuschränken und habe mir dann gesagt: Das ist halt eine richtige Simulation der Crowd und nicht nur ein Konstrukt für die Spielerin. Wenn die Performance drunter leidet, muss diese Spielerei natürlich weg. --Andyk 20:39, 27. Jun. 2009 (UTC)

• zweitens: wenn die crowd bereits die richtige Zusammensetzung hat (die bei dir in der VictimType-Tabelle explizit gesetzt wird), dann bleibt die Zusammensetzung auch für eine zufällige Auswahl erhalten

Stimmt im Groben - mit einer kleinen, für das Spiel irrelevanten Subtilität: Die Zusammensetzung, also die appearance_probability p beantwortet die Frage: Wie wahrscheinlich ist es, wenn ich eine Person herausnehme, dass die vom VictimType t ist? Dadurch ergibt sich die absolute Zahl der Leute nicht direkt, sondern es entsteht ein kleiner Zufallseffekt (Binomialverteilung: B(c,p,x) c ist die Anzahl der noch zu befüllenden Positionen in der Crowd, die sich natürlich pro Durchlauf in Schritt 3 ändert. x ist dann die Anzahl der zu befüllenden Personen für den VictimType t - also das Ergebnis des Binomialexperiments B, wenn c und p fix sind.) Das ist natürlich ein unnötiger Performance-Fresser, das war mir schon beim programmieren bewusst, aber es hat mir Spaß gemacht zum programmieren ;). Nachdem du das aber jetzt so schön im Wiki visualisiert hast, werd ich die appearance_probability natürlich uminterpretieren und den Algorithmus entsprechend anpassen. --Andyk 20:39, 27. Jun. 2009 (UTC)

• zur Erleichterung gibt es auf IF:Diebstähle im blauen Feld "Diebstahl-Details" jetzt eine Auflistung mit der tatsächlichen Verteilung unter den bisher angelegten Opfern - man kann also im todo darauf hinweisen, Opfer welchen Typs noch angelegt werden sollten

• daraus folgt drittens: sobald die Anzahl der für den Spieler sichtbaren Opfer ermittelt wurde, kann die Opfertabelle mittels

<source lang=inform enclose=div>sort the Table of ConcreteVictims in random order</source>

• ...durcheinandergewürfelt und dann einfach die entsprechende Menge an Opfern vom Anfang der Tabelle ausgewählt werden.

Jup, das ist die straight-forward-Methode, die ich angesichts der aktuellen Lage durchführen werde. --Andyk 20:39, 27. Jun. 2009 (UTC)

nützlich für dich? --Thai 17:09, 27. Jun. 2009 (UTC)

Danke für die Anmerkungen - freut mich, dass sich jemand mit dem Algorithmus beschäftigt und endlich entdeckt, welche Spielereien dort zu finden sind. ^^ --Andyk 20:39, 27. Jun. 2009 (UTC)

Build 54

Menübasierter Ansatz erweitert - man sollte nun entsprechend der Tabelle die Personen und die möglichen Handlungen auswählen können (Details siehe Code). (Bitte meine seltsamen Merging-Versuche kontrollieren; ich glaube die Ursache für meine Probleme ist mein überlagertes Backupsystem - Dropbox -; wenn ich auf zwei Computer arbeite, erkennt Tortoise beim jeweils anderen Computer nicht, dass ich etwas geändert habe und da tauchen dann die Probleme auf.) Ich werde mal bis Donnerstag pausieren. --Andyk 02:10, 3. Jun. 2009 (UTC)

Build 57

Möchte heute den Diebstahl-Algorithmus zum Ende bringen. Dazu ist noch notwendig:

• Dynamisch die Objekte erstellen (oder wenn ich darauf verzichte, dann etwas Anderes einfallen lassen wie einen Gegenstand "Diebesgut", bei dem man nur die Attribute ändert, oder der auf eine Tabelle mit eingesacktem Diebesgut zeigt.
• Die Punktezahlen erhöhen, wenn Diebstahl erfolgreich
• Festlegen, was passieren soll, wenn Diebstahl fehlschlägt (Punktezahl reduzieren, Spiel verloren, ...)
• Automatisches "Aufsteigen" im Rang - basierend auf Punktezahl und ob Gyges das "Theft by Intoxication" schon absolviert hat.

Das reicht. Melde mich wieder, wenn ich fertig bin ;) --Andyk 20:30, 5. Jun. 2009 (UTC)

Da ich mir aufgrund dieser URL keine Sorgen bzgl. Parchment und Glulx-Kompatibilität Sorgen machen brauche, werde ich echte Objekte implementieren, die man ganz normal im Inventar anschauen kann.

Was ich in diesem Zuge noch entdeckt habe: Man kann - wie Anna vermutet hat - den Code tatsächlich bereits offline in Javascript umwandeln, um eine höhere Performance zu erreichen.--Andyk 22:18, 5. Jun. 2009 (UTC)

Prinzipiell sollten die obigen Dinge nun funktionieren. Wenn der Diebstahl fehlschlägt, werden zur Zeit nur Punkte abgezogen; sonst hat es keine Konsequenzen. --Andyk 23:48, 5. Jun. 2009 (UTC)

Die Performance ist auf meinem Rechner (950MHz - Single Core, 768 MB RAM) nicht ganz so flüssig wie bei "normalen" Spielen. Wie sieht das bei euch aus? (Wenn es bei euch auch nicht so gut ausschaut, werde ich auf die Dynamic Objects Extension verzichten und die Items anders generieren)

Läuft bei mir auch sehr langsam. Es wäre wohl besser, auf die dynamic objects zu verzichten. So macht das keinen Spaß mehr.

Es fehlt noch eine Anzeige der angeeigneten Gegenstände. (Ich muss zugeben, ich hab es noch nicht ausführlich getestet). Bei "EatingVictims" habe ich die Tabelle so modifiziert, dass man nur Punkte hinzu bekommt und kein Geld oder keinen Wertgegenstand, da Gyges das (nicht näher beschriebene) Nahrungsmittel sofort zu sich nimmt. Ich könnte das wieder raus nehmen, wenn die Erfolgsmeldungen entsprechend gestaltet werden.

Es gibt einen Bug: Nach einem erfolgreichen Diebstahl wird die Tabelle um die Person, bei der man den Diebstahl durchgeführt hat, bereinigt. Das Menü dürfte aber nicht korrekt upgdated werden, weshalb ein Zugriffsfehler auftaucht.--Andyk 00:00, 6. Jun. 2009 (UTC)

Hab ich glaubich schon erwähnt, aber Hunger und Verhungern ist in Beispiel 140 im Manual implementiert ("Hunger that eventually kills the player, and foodstuffs that can delay the inevitable by different amounts of time").

Angabe der Ausgänge aus den Beschreibungen entfernen?

Wollte dazu noch mal nachfragen: ist es nicht so, dass ExitLister nur die Himmelsrichtungen angibt, in die der Spieler gehen kann? Wäre es nicht durchaus trotzdem sinnvoll, in den Raumbeschreibungen Hinweise darauf zu geben, was wo ist (vermeidet den Frust, ständig in die falsche Richtung zu laufen)? Hab das Todo vorläufig wieder entfernt - wenn ich mich täusche, oder ihr anderer Meinung seid, bitte wieder hinzufügen... --Thai 16:41, 6. Jun. 2009 (UTC)

Soviel ich weiß schon. Man kann aber auf andere Weise den Raum angeben, vgl. etwa Beispiel 331. --H.A.L. 05:53, 10. Jun. 2009 (UTC)

Update: Ich habe mal eine every turn rule eingefügt, die die Ausgänge und die Räume auflistet.

Build 58

Hab die Tabellen für die Diebstähle, die jetzt aus dem Wiki befüllt werden, ins Volume 0 gepackt. Das Original habe ich vorläufig behalten und den Import aus dem wiki auskommentiert, weil inform derzeit beim Kompilieren hängenbleibt (vermutlich weil noch zu wenige Victims definiert sind). @Andyk: Bitte IF:Diebstähle aktualisieren (vor allem die Todos) und dann noch mal eine Aufforderung an alle schreiben, neue Opfer zu basteln... --Thai 19:25, 6. Jun. 2009 (UTC)

Build 64

• Code
• Diff to 62

Bzgl. Exit Listener habe ich HALs Rule ein wenig überarbeitet. Bitte um Kommentare.

Sowas hab ich mir vorgestellt. Ich habe die Regel nochmal modifiziert, jetzt leitet der Text die letzte Möglichkeit mit "or" ein. Dazu habe ich den Code so verändert, daß die Variable runter- statt raufzählt. --H.A.L. 08:02, 12. Jun. 2009 (UTC)

Hoffe, ich kann die Crowd Algorithmen heute abschließen.

Glulx bremst die Performance bei schwachen Rechnern enorm aus, habe ich festgestellt. Konsequenzen: Dynamic Object Extension entfernt. Da die Reaktionszeiten immer noch recht langsam waren, habe ich auf Z8 umgestellt; jetzt läuft das Spiel auch bei meinem Rechner wieder flüssig.

Die Person wird nun richtig entfernt. Was noch fehlt ist, dass - wenn der Diebstahl fehlschlägt, die Person in einen anderen Raum kommt (am besten per Zufall - 2 Räume weiter). Vielleicht mag das jemand implementieren? Das sollte in der activity rollout rule geschehen, und zwar in diesem Bereich, wo ein Punkt abgezogen wird: <source lang="inform"> wait for any key; else; say ftext of planning box; decrease the score by 1; [Festlegung der Einfachheit halber: Man kann im Rang nicht mehr zurückrutschen] if the score < -10 and grade of yourself is Survival begin; end the game saying "You died on starvation."; else if the score < -5 and the grade of yourelf is Single_Amateur begin; end the game saying "Jetzt haben sie dich geschnappt." end if; wait for any key; end if; </source> ( Falls nicht, mach ich es demnächst )

Ich hab einen Code eingefügt, der Gyges um zwei Räume versetzt. Dabei ist zu beachten, daß an der Stelle, an der im Ablauf der neue Code ausgeführt wird, im Spiel eine Raumbeschreibung kommt. Wir könnten noch überlegen, ob diese an einer Stelle besser paßt als an einer anderen. Oder sie ganz unterdrücken, dazu müßte man mW die describe room gone into rule ersetzen. Das würde passen, denn Gyges flieht blindlings und sieht sich zuerst nicht mal um. - Ich habe noch einen Satz eingefügt, der die Flucht beschreibt. Ich dachte mir, das muß nicht unbedingt in der Fail-Message stehen, weil es nicht vom Opfer abhängt. --H.A.L. 08:02, 12. Jun. 2009 (UTC)

--Andyk 15:49, 11. Jun. 2009 (UTC)

Build 65: Code, Changelog

Build 66

Gleichmal zur Dokumentation. Wenn ein Diebstahl erfolgreich war und das Opfer einen Gegenstand und/oder eine Geldbörse bei sich hatte, wandert das Geld der Geldbörse in die Geldbörse des Spielers und der Gegenstand ins Inventar. Da es sich bei den gestohlenen Gegenständen aber nicht um echte Gegenstände handelt, kann man sie nicht näher betrachten und mit ihnen interagieren. Im Spiel sieht das zur Zeit folgendermaßen aus:

>i
You are carrying:
  a jar of liquor
  a PlayerPurse
And here is the list of valuables you have stolen:

Macbook (Leuchtet hell.) is about 5EUR.
Overall you have valuables amounting to 5EUR.

>x purse
You have 50EUR.

Der entsprechende Code dazu ist: <source lang="inform"> After listing contents of yourself: let wholeworth be 0EUR; say "And here is the list of valuables you have stolen:[paragraph break]"; repeat through the Table of Own Valuables begin; say "[bold type][name entry][roman type] ([description entry])

                    is about [italic type][worth entry][roman type].";

now wholeworth is wholeworth + worth entry; end repeat; say "Overall you have valuables amounting to [wholeworth].". </source> Wofür kann man diese Gegenstände brauchen? Zum Eintauschen in Geld? Die Sache könnte einen doppelten Zweck verfolgen, wie man im folgenden Vorschlag sieht: <source lang="inform"> The poster is a thing. The description of the poster is "[bold type]PURCHASE OF GOODS[roman type] [paragraph break]Do you have Valuables? Sell it to ***GATES DEALERSHIP***. We are located at Burgring near to the Burggarten."

Gates Dealership is north of Burg-Ring at Burggarten. The description of Gates Dealership is "??? TODO ???" [Das Handelsunternehmen ist dort platziert, um die Spielerin in Richtung Master-Rätsel zu locken] The Dealer is a person in Gates Dealership. [TODO: Dialog einbauen, bei dem man die gestohlenen Waren eintauschen kann.

      Im Gespräch nennt der Dealer seinen Vornamen: William Henry Bill. ]

Lonesome Outlaw is a scene. Lonesome Outlaw begins when the grade of the player is Single_Amateur. Lonesome Outlaw ends when the grade of the player is not Single_Amateur.

Before printing the locale description of a room (called r) when a random chance of 30 in 100 succeeds and r is not in PrivateTerrain during Lonesome Outlaw, now the poster is in the location. </source>

Build 68

Map: Ring & Co.

Map: U2-Strecke

Eugenic Street (Ein Szenario im Schlössl;noch nicht vernetzt)

Build 68

Diff mit 66

• Einige Änderungen vorgenommen, damit nun individuelle Crowds für spezielle Zwecke erstellt werden können.
• Demonstration eingefügt für den Bibliotheksbereich (test plagiarize bringt dich direkt zum Menü mit den Bibliotheksangestellten)
• Das Debugging hat mich am meisten Zeit gekostet - ich hatte eine kryptische Fehlermeldung. Nach Langem herumprobieren bin ich dann endlich draufgekommen, dass die Victim-Beschreibung zu lang war (in Tabellen - oder speziell in Menü-Tabellen? - gibt es da scheinbar ein Problem). Ich habe den letzten Satz "Their label indicates that they are the property of the Library of Vienna University." entfernt und dann lief es. Habe kurz auch versucht, den text auf indexed-text zu ändern, das hab ich aber schnell wieder aufgegeben, weil ich sonst die Menu-Extension umschreiben müsste. Was lernen wir daraus? Nichts :) In manchen Fällen muss man einfach lange Debuggen, bis man draufkommt.--Andyk 22:45, 15. Jun. 2009 (UTC)