Benutzer:Andyk/Mitschriften/Projekttagebuch: Unterschied zwischen den Versionen

Aus Philo Wiki
Wechseln zu:Navigation, Suche
K (corr.)
K (move)
Zeile 292: Zeile 292:
  
 
= 26.02. - 01.03.2009: Session 4: Einschub: Inform7 vs. Standard-Programmiersprachen =
 
= 26.02. - 01.03.2009: Session 4: Einschub: Inform7 vs. Standard-Programmiersprachen =
== Was ist das hier? ==
+
Um die Übersicht zu wahren, verlinke ich diese Session auf eine eigene Seite. Sie kann relativ unabhängig von den anderen Überlegungen verstanden werden, da es hauptsächlich um eine technische Auseinandersetzung mit den Möglichkeiten von Inform7 geht.  
Ich habe mir gedacht, dass das Schlussstatement in Session3 - nicht alles an Inform 7 ist objektorientiert - zu ungenau ist und wollte einfach mal nachhaken, weil es mich interessiert hat.
 
  
Es folgen nun einfach ein paar Notizen, die ich mir beim Lesen des [http://www.ifwiki.org/index.php/Inform_7_for_Programmers Inform7-Tutorials für Programmierer] gemacht habe. Vielleicht kann jemand etwas damit anfangen; für mich ist es einfach ein kleines Cheat-Sheet und der Versuch mir etwas klarer über die Möglichkeiten von I7 zu werden.
+
<div align="center"> --> '''[[Benutzer:Andyk/Mitschriften/Technische I7-Auseinandersetzungen|Technische I7-Auseinandersetzungen]]''' <--</div>
 
 
* Regeln sind in Regelbücher eingeordnet.
 
* Regeln sind auf 3 parameter eingeschränkt -> die höchste Stelligkeit (arity), die ein englisches VERB haben kann.
 
* Über Regeln wird noch mehr zu verstehen sein!!
 
 
 
== Allgemeines ==
 
 
 
* Events werden Actions genannt, denn sie bestimmen die Handlungen des  Protagonisten
 
 
 
* Verhältnis zur Objektorientierung: Einfachvererbung und Polymorphismus werden unterstützt, Abstraktion, Modularität und  Namensräume nicht.
 
 
 
* Inform7 source code wird in Inform6 code und dann in die virtuelle Maschine kompiliert. Diese Kompilierungsvorgänge laufen aber für den durchschnittlichen IF7-Entwickler unbemerkt im Hintergrund ab. (vgl.  I7-Dokumentation ab 24.13)
 
 
 
* Es ist nicht wirklich erwünscht, Inform6-code in ein Inform7-Projekt zu integrieren: "for those who do know I6 already, it would be all too  easy to write highly hybridised code, constantly mixing I6 and I7. The  authors of Inform hope that this will not happen: for almost all  purposes, I7 is much more powerful than I6, and fails - when it has to  fail - in a way more helpful to the user. Ideally, all I6 content would  be confined to extensions (and this may be mandated in future releases  of Inform), and even writers of extensions are asked to pare down their  usage of I6 to the minimum necessary."
 
 
 
* Bei Inform-7 gibt es keine einheitliche Theorie. In der Objektorientierung kann man sagen "Alles ist ein Objekt" oder bei manchen Skriptsprachen zum Beispiel "Alles ist eine Liste". Das kann man generell nicht bei Inform7 sagen. Deswegen ist es leichter zu erlernen, weil man jedes Feature lernen kann, ohne die anderen zu benötigen. Für Nicht-Programmierer mag das eine zufriedenstellende Sache sein. "But at higher levels of programming, the language has a very ad-hoc feel to it."
 
 
 
* Jedes Programm braucht mindestens einen Raum. Das kleinste Programm: <code>X is room.</code>
 
 
 
* Das obligatorische Hello-World in Inform: <code>My apartment is a room. When play begins: say "Hello world.</code>
 
 
 
== Wissenswertes über die Basics ==
 
 
 
* Die Artikel ('some', 'a', 'the', 'an') werden beim Kompilieren  einfach entfernt.
 
* 'is' und 'are' sind synonym (ist also egal, was du verwendest)
 
 
 
=== Variablen ===
 
* Man kann einfach einen Satz schreiben der mit "that varies." endet.
 
* Die wichtigstenn vordefinierten 'Kinds of Values' (Datentypen) sind:
 
** number, text, truth state
 
** thing, person, direction
 
** table-name, rulebook, rule
 
** indexed text, stored action
 
* <code>X is a number that varies.</code>
 
* <code>Y is a number variable.</code>
 
* <code>An excuse is some text that varies.</code>
 
* <code>The best spot is a room that varies.</code>
 
* <code>The light switch's boolean is a truth state that varies.</code>
 
 
 
=== Objekte / things ===
 
Da ist mir das meiste schon von der Dokumentation gut bekannt, außer:
 
* Wenn nach einer Raum-Instanz wie <code>My house is a room,</code> ein  Text wie "Schönes, großes Haus." kommt, dann wird der Text der  Description-Property zugewiesen.
 
* Wenn nach einer Objekt-Instanz wie <code>The apple is a thing.</code>  so ein Text kommt, dann wird er der "Initial Appearance"-property  zugewiesen. Wenn das Ding von der Spielerin aufgehoben wird, wird AFAIK  der Initial appearance-text ausgegeben.
 
 
 
=== Klassen / kinds ===
 
* Funktion von usually: Wenn man <code>usually</code> schreibt, dann  dürfen Objekte der Klasse trotzdem noch nen anderen Wert haben, wenn  man es explizit angibt. Wenn man <code>always</code> schreiben würde,  dann wäre für alle Objekte der Klasse fixiert, welchen Wert sie  annehmen. Mit Wert annehmen meine ich sowas wie dass die Farbe eines  Pferdes braun ist <code>A horse is a kind of animal. A horse has a text  called color. The color of a horse is usually "brown".</code>
 
 
 
Was ist bei den Klassen sonst noch wissenswert?
 
* Eine Region ist ein Container für Räume
 
* Supporter: Gegenstände, wo man andere Gegenstände draufstellt  (anbietet). Ist normalerweise "fixed in place"
 
* Backdrop (Kulisse/Hintergrund): Eine Szenerie (die Sonne am Himmel,  der immer präsente Bach)
 
* "The positioning of Animal is our first hint that we're stepping out  of a scientific worldview, and into a humanistic one. Likewise, the  purpose of the language as a whole is to produce works of art, not  software tools."
 
* anonyme (dichotomische oder:) boolean-Eigenschaft mit benannten  Werten anstatt true und false: <code>A human can be just or  unjust.</code>
 
* "yourself" ist ein thing von der Klasse 'person'. "The player" ist  nur eine Variable auf "yourself". Diese Person mit der Variable gibts  bei jedem Spiel (außer man ändert es im Code).
 
* Es gibt eine Instanz der Super-Klasse (die, die in der Hierarchie  ganz oben steht) 'object', nämlich "nothing". Synonyme von nothing sind  nowhere,nobody,no-one und 'no one'.
 
 
 
== Good, old coding @ Inform7 ==
 
Weil es so schön instruktiv ist, würde ich einfach die ganze  Demonstration der obligatorischen Programmierkonstrukte if, else,  switch, while, for-each in Inform7 aus dem Tutorial hier rein kopieren.  Damit es nicht zu unübersichtlich ist, reiß ich mich zusammen und mache  einen Link:
 
*  [http://www.ifwiki.org/index.php/Inform_7_for_Programmers/Part_1#The_Coding_Imperative DER LINK, DER ALLE VERSCHIEDENEN NOTATIONEN VON  ÜBLICHEN KONSTRUKTEN IN DER PROZEDURALEN PROGRAMMIERUNG FÜR INFORM7 VORSTELLT]
 
* Erwähnenswert: Man kann das letzte Statement in einem Block entweder  mit einem '.' beenden oder man nimmt wie immer ; und fügt danach eine  leere Zeile hinzu.
 
 
 
== Wie hängen Phrasen, Funktionen und Regeln zusammen? ==
 
* Alle Schlüsselworte/Befehle wie if, repeat, next, etc. sind Phrasen.
 
* Funktionen sind auch Phrasen, weil sie ähnlich aufgerufen werden  (nämlich explizit im Code)
 
* Regeln sind keine Phrasen. Man ruft sie nicht explizit auf, sondern  sie werden aufgerufen, wenn im Spiel ein Ereignis (z.b. eine Action)  oder eine andere Situation eintritt.
 
 
 
== Wie hängen Inform und Objektorientierung zusammen? ==
 
Das ist der Punkt, der mir in Session 3 bereits aufgefallen ist:
 
* "Frequently in OOPLs (AKA: Object Oriented Programming Languages),  new properties and methods cannot be added to a pre-existing class  because doing so would break pre-existing code that uses it;  subclassing is required to add such embellishments. But since Inform  isn't designed for re-usable code or even team-built works, Inform  allows the direct modification of classes, and those changes are  propagated down the subclasses regardless whether they are built-in or  not."
 
 
 
== Wie man bool'sche Eigenschaftswörter definieren kann ==
 
* Ganz klar ist mir noch nicht, wofür man diese Wörter genau verwendet,  aber die Dokumentation sagt und das Tutorial deutet an, dass man mit  ihrer Hilfe gut Regeln definieren kann
 
* '''Möglichkeit1''': Eine anonyme bool'sche Eigenschaft mit benannten  Namen (anstatt true/false) erstellen: <code>A person can be grumpy or  happy.</code>
 
* '''Möglichkeit2''': Das Äquivalent zu dem, was man in OOPLs "eine  Klassen-Methode erstellen, die einen Boolean-Wert zurückgibt" nennen  könnte:
 
:<code>Definition: a person is unlikable if it is boring or it is  grumpy.</code>
 
 
:<code>Definition: a person is boring [...];</code>
 
::<code>[...];</code>
 
::<code>decide no.</code>
 
 
 
:<code>Definition: A room is occupied rather than unoccupied if a  person is in it.</code>
 
(rather than unoccupied ist optional, sozusagen genau das Gegenteil,  aber man braucht dafür nicht eine ähnliche Definition mit 'unoccupied'  schreiben, wenn man es definieren will)
 
 
 
* '''Möglichkeit3''': mit 'to decide wheather' (vgl. Inform7-Doku  11.16. oder siehe [[#Funktionen mit Boolean-Rückgabewert: To decide whether/if...|unten]]).
 
 
 
=== Und wie überprüft man diese Adjektive? ===
 
* Mit einem repeat-Konstrukt:
 
<code>repeat with associate running through every chatty not grumpy  spiffy person begin;</code>
 
::<code>say "Hi [associate].";</code>
 
<code>end repeat;</code>
 
 
 
=== Und was sind die expliziten Verwendungszwecke solcher Adjektive?  ===
 
* Im Tutorial wird nur mal erwähnt, dass sie bei Inform7 die große  Stärke sind. Kann man die Adjektive als analog zu den Prädikaten in der Prädikatenlogik verstehen? Mal sehen, ob ich diese Frage besser  beantworten kann, wenn ich mehr über 'rules' weiß.
 
 
 
== Das Äquivalent zu Globalen Funktionen: 'To ...'-Phrasen ==
 
* Man kann sich Funktionen definieren, die man dann in irgend einer  Phrase aufrufen kann.
 
=== Funktionen, die keinen Wert zurückliefern ===
 
:<code>To plainly greet (friend - a person):</code>
 
::<code>say "Hi [friend]."</code>
 
 
 
:<code>To ponder/mull over/-- (good point - a thing) for (awhile - a  time period) as (ponderer - a person):</code>
 
::<code>say "[Ponderer] sits back in [his-her] chair for about  [awhile]. 'Hm, [good point] is a very good point, sir.'" plainly greet  Dr. Muller; </code>
 
 
 
* Die Slashes ('/') trennen die Synonyme für den Funktionsnamen ab (man  darf keine Leerzeichen dazwischen haben).
 
* Die beiden Bindestriche ('--') sagen aus, dass das Wort davor  (nämlich 'over') optional ist.
 
* In Klammern steht immer die Bezeichnung des Parameters (good point,  awhile, ponderer) und welche Klasse/kind erwartet wird (thing, time  period, person)
 
* Das finde ich wirklich beeindruckend (vor allem weil ich die  Mächtigkeit dieser Prozeduren In I7 noch nicht kannte). Man kann wie in  der zweiten Funktion mehrere Parameter (thing, time period, person)  angeben und dann für die Verarbeitung entsprechend verwenden. Aufrufen  tut man die Funktion auf folgende mögliche Arten:
 
 
 
* <code>ponder the best idea yet for 7 minutes as Dr. Muller; </code>
 
* <code>ponder over the best idea yet for 7 minutes as Dr.  Muller;</code>
 
* <code>mull best idea yet for 7 minutes as Muller; </code>
 
* <code>mull over the best idea yet for 7 minutes as Dr. Muller;  </code>
 
 
 
* Zwei Parameter dürfen nicht direkt neben einander stehen (z.B.:  <code>To ponder for (awhile - a time period) (good point - a  thing):</code>)
 
 
 
* Das Tutorial sagt: Man nimmt nicht so gerne diese Art von globalen  Funktionen sondern lieber 'rules': die kann man zwar nicht so schön  aufrufen, dafür sind sie flexibler.
 
 
 
=== Funktionen mit Rückgabewert: To decide which/what... ===
 
* Funktion: <code>To decide what person is brother to/of (sibling - a  person): [...]; decide sibling.</code>
 
* Aufruf: <code>if the brother of the noun is not the noun, say "[Noun]  has a brother, [Brother of the noun].";</code>
 
* Zwischen 'to decide what' und 'is...' befindet sich das, was  zurückgegeben wird... in diesem Fall ein 'thing' von der Art 'person'.
 
 
 
=== Funktionen mit Boolean-Rückgabewert: To decide whether/if... ===
 
* Wenn ein wahr/falsch zurückgegeben werden soll:
 
:<code>To decide whether (pants - a thing) is/are on fire:</code>
 
::<code>decide on whether or not a random chance of 1 in 2 succeeds.</code>
 
 
:<code>if the brother of the noun is on fire, say "That's gonna leave a  mark.";</code>
 
* Wie man beim Aufruf sieht, kann man den Rückgabewert gleich in dem if einbinden. Nützlich.
 
 
 
=== To say... ===
 
* Man kann für bestimmte (evt. durch Variablen generierte) Texte Platzhalter einführen. Ich würde mir das wie Funktionen vorstellen, die einen String (Zeichenkette) zurückliefern.
 
* Die Syntax funktioniert ansonsten genauso wie [[#Funktionen, die keinen Wert zurückliefern|hier] erklärt
 
 
<code>To say He-She for (P - a person):</code>
 
::<code>if P is plural begin;</code>
 
:::<code>say "They";</code>
 
::<code>otherwise;</code>
 
:::<code>if P is female, say "She";</code>
 
:::<code>otherwise say "He";</code>
 
::<code>end if.</code>
 
 
 
Aufruf mit eckigen Klammern:
 
:<code>[...]; say "[He-She for Chris] says Hello.";</code>
 
 
 
== Relationen ==
 
* Darüber hab ich mir bei der [[Benutzer:Andyk/Mitschriften/PSI_06_12_08_Inform7_Einf%C3%BChrung|I7-Einführung]] ein bisschen Gedanken gemacht
 
* Der Name einer Relation darf keine Leerzeichen enthalten.
 
* Ein Beispiel einer symmetrischen 1-zu-1-Relation: Wenn A mit B verheiratet ist, dann ist automatisch auch B mit A verheiratet. A kann aber nicht zusätzlich mit jemand anderen (z.B. C) verheiratet sein.
 
::<code>Marriage relates one person to another (called the spouse).<font color="darkgreen"> ["to another" means a symmetric relation]</font> </code>
 
::<code>The verb to be married to implies the marriage relation.</code>
 
* Ein Beispiel einer symmetrischen Freundschafts-Relation. Wenn A mit B befreundet ist, ist bei einer symmetrischen Relation auch B mit A befreundet. In diesem Fall kann A aber auch mit C (D,E,F,G usw.) befreundet sein.
 
::<code>Friendship relates various people to various people. <font color="darkgreen">[an asymmetric relation]</font></code>
 
::<code>The verb to be friends with implies the friendship relation.</code>
 
::<code>The verb to be befriended by implies the reversed friendship relation. <font color="darkgreen">[ defining a "reversed" syntax for asymmetric relations is useful in Descriptions ]</font></code>
 
 
 
* I7 kann Verben der Form "to be X" automatisch beugen (vgl. [http://de.wikipedia.org/wiki/Flexion Flexion]).
 
* Bei Verben der Form "to X" muss man alle Beugungen in Klammer angeben:
 
::<code>Trust relates people to each other in groups. <font color="darkgreen">[an equivalence relation]</font></code>
 
::<code>The verb to trust (he trusts, they trust, he trusted, it is trusted, he is trusting) implies the Trust relation.</code>
 
 
 
* Eine Übersicht über alle möglichen Relationen:
 
:::<code>...one person to one person...</code>
 
:::<code>...various people to one person...</code>
 
:::<code>...one person to various people...</code>
 
:::<code>...various people to various people...</code>
 
:::<code>...one person to another... <font color="darkgreen">[ one-to-one, symmetric (if A~B, then also B~A; think "commutative operator")]</font></code>
 
:::<code>...people to each other... <font color="darkgreen">[various-to-various, symmetric]</font></code>
 
:::<code>...people to each other in groups... <font color="darkgreen">[equivalence (think "if A equals B, then A also equals everything that B equals)]</font></code>
 
 
 
* Relationen kann man nicht nur wie oben einfach bedingungslos zwischen zwei Mengen herstellen, sondern auch (wie das bei der Prädikatenlogik AFAIK üblich ist) Bedingungen angeben, wann eine Relation zutrifft:
 
::<code>Siblinghood relates a person (called X) to a person (called Y) when X is the brother of Y or X is the sister of Y.</code>
 
 
 
=== Wie kann man Relationen gebrauchen? ===
 
* Man kann keine Relations-Variable erstellen. Man kann auch keine Relation als Rückgabewert einer Funktion vorsehen.
 
* Nützlich ist so eine Relation zum Beispiel bei der Pfadsuche:
 
::<code>let X be the number of steps via the acts-with relation from Kevin Bacon to Jodie Foster;</code>
 
::<code>let S be the next step via the acts-with relation from Christopher Walken to Kevin Bacon;</code>
 
* Man kann solche Relationen gut für Abfragen (Queries) benutzen (mit repeat with kann man alle 'things' durchgehen, auf die die Abfragekriterien zutreffen).
 
 
 
== Regeln / rules ==
 
Nun kommen wir zu dem berüchtigten Konzept, das ich in I7 noch nicht einordnen kann, weil es sich dem Prozeduralen bzw. dem Objektorientierten Paradigma widersetzt: Regeln.
 
* '''Das prozedurale Paradigma''' (Beispiel: C)führt Befehle einer Prozedur (Funktion, Operation) dann aus, wenn die Prozedur mit ihrem Namen (+ evt. Parameter) aufgerufen wird.
 
* '''Das regel-getriebene Paradigma''' (Beispiel: Prolog) braucht keinen Namen, da sie nicht notwendigerweise aufgerufen werden muss; sie ruft sich quasi selbst auf. Das klappt durch die inhärente Struktur einer Regel: Sie weiß, wann sie zum Zug komemn soll, da in ihr selbst die Bedingungen enthalten sind, unter welchen Umständen sie selbst auftritt. Ich stelle mir das zunächst mal so ähnlich vor wie wenn man die Regeln einer Turingmaschine definiert: "Wenn die Maschine in Zustand q1 ist, dann fahre mit dem Lese/Schreib-Kopf nach links und nimm Zustand q2 an." Diese Regel wird dann aktiv, wenn die Maschine in einer bestimmten Situation ist, nämlich in der Situation, die der Zustand q1 beschreibt.
 
** Man kann die Regeln nochmal unterteilen in Header und Code-Teil. Im Header sind die Situationsinformationen (vgl. Zustand q1 bei Turingmaschinen) gespeichert, im Code die einzelnen Befehle (vgl. Turingmaschinen: Nach Links fahren).
 
* Die Information, unter welchen Bedingungen eine Prozedur aufgerufen wird, ist im ganzen Code verstreut, nämlich überall, wo ihr Name auftaucht. Bei Regeln ist sie anscheinend im Header.
 
 
 
=== Syntax ===
 
Der Header einer Regel endet mit einem Doppelpunkt (<code>:</code>). Danach kommen die einzelnen Instruktionen (jeweils abgetrennt durch einen Strichpunkt <code>;</code>) und enden mit einem Punkt (<code>.</code>) oder mit einer leeren Zeile:
 
::<code>A persuasion rule: [...]; [...]; [...]. </code>
 
::<code>Every turn during the collapsing bridge scene: [...].</code>
 
::<code>Carry out an actor helping someone: now the noun is friends with the actor.</code>
 
* Regeln sind in Regelbücher eingeordnet. Im Header einer Regel gibt man im Wesentlichen an, in welches Regelbuch die Regel hinein gehört. Zusätzlich kann man auch noch andere Elemente nach der Angabe des Regelbuches reinpacken:
 
** when/while (bei if-then-strukturen)
 
** during (wenn man Szenen verwendet)
 
** eine einzelne Beschreibung einer Aktion ("someone burning something")
 
* Man kann sagen, dass Regelbücher veränderbares Verhalten kapseln (Im reinen Objektorientierten Paradigma tun das Objekte auch. Bei I7 tun das Objekte/things nicht.)
 
* "It could be said that objects implement nouns, while rulebooks implement verbs."
 
 
 
=== Wie benennt man Regeln und warum soll man das tun? ===
 
(vgl. I7-Doku 18.3)
 
 
 
<code>This is the blossom shaking rule: say "The summer breeze shakes the apple-blossom."</code>
 
 
* Fürs Debugging ist das ganz wichtig. Durch die Befehle <code>RULES </code> und <code>RULES ALL</code> erfolgt eine Ausgabe, die die Namen aller Regeln auflistet, wenn sie ausgeführt weren.
 
* "it is always good extension-writing practice to name all rules merely so client code can reference, modify, or delete them, to say nothing of documentation":
 
::<code>My magic hand rule '''is listed instead of''' the can't take distant objects rule in the check taking rulebook.</code>
 
::<code>The landlubbers can't walk right rule '''is listed first''' in the check going rules.</code>
 
 
 
AKA: Welche Regelbücher gibt es? Welche sind wichtig?
 
 
 
=== Anwendungsbeispiel ===
 
* Ich hätte bei [http://phaidon.philo.at/viewvc/Probegalopp/book.inform/ meinem Buch-Beispiel] gerne die Switching-On/Off-Rules mit eigenen Rules ergänzt, die nur dann in Kraft treten, wenn es sich um ein Ding der Art "Buch" handelt (damit kann man die unpassenden Meldungen beim öffnen des Buches und beim Betrachten des Buches hoffentlich entfernen)
 
* Update: Es ist mir gelungen, neue Regeln hinzuzufügen, die unerwünschten Ausgaben der Standard-Regeln zu unterdrücken (zumeist mit <code>stop the action</code>) und zum Buch passende Ausgaben zu schreiben. Natürlich (!) kann man das Ganze auch leichter haben, indem man die Buch-Art direkt von 'thing' ableitet (<code>A book is a thing</code> und sich einfach ein dichotomisches Adjektiv für die Frage, ob das Buch offen oder geschlossen ist, definiert: <code>A book can be open or closed.</code>. Dementsprechend bräuchte man dann auch noch <code>Instead of opening a book: say "The book is open."; now the noun is open.</code> und Ähnliches für closing.
 
 
 
Ich habe es umständlicher gemacht und dadurch ein bisschen die Abgründe der Rulebooks erkundet:
 
 
 
 
 
<code>Carry out examining described books: abide by the standard examining rule; say "[if the noun is switched on]The book is open and I can see [a list of pages which are part of the noun].[otherwise]The book is closed.[end if]";stop the action.<br><br>Check switching off described books when the noun is switched off: say "You want to close a closed book?"; stop the action.<br><br>Check switching on described books when the noun is switched on: say "Oh my god... The book is already open."; stop the action.<br><br>Report switching on described books: say "The book is now open."; stop the action.<br><br>Report switching off described books: say "The book is now closed."; stop the action.</code>
 
 
 
== Regelbücher ==
 
* Hätte ich das [http://www.ifwiki.org/index.php/Inform_7_for_Programmers/Part_3 Tutorial-Kapitel über Regelbücher] vor dem Schreiben des obigen Anwendungsbeispiels gelesen, hätte ich das Übergehen der Standardregeln ein wenig anders gelöst:
 
* Ein Regelbuch geht die Regeln, die in ihm enthalten sind, von der ersten bis zur letzten durch. In diesem Vorgang wird es nur unterbrochen, wenn in einer Regel ein definitives Ergebnis der Form <code>rule succeeds</code> oder <code>rule fails</code> vorkommt. Kommt so etwas nicht vor, wird implizit jeder Regel am Ende ein default-Ergebnis hinzugefügt (standardmäßig ist das: <code>make no decision</code>, den man natürlich auch explizit hinschreiben kann). Man kann das default-Ergebnis auch für jedes einzelne Regelbuch ändern:
 
<code>The pick a plan rules are a rulebook.<br>The pick a plan rules have default outcome success. <font color="darkgreen>[ Or failure, or no outcome ]</font></code>
 
* Das Ergebnis/outcome (succeed,failed) ist verschieden von einem Rückgabewert/return value, den man für eine Regel folgendermaßen zurückliefern kann:
 
<code>The audible rules have outcomes silent (failure), whisper (success), voiced (success - the default), shout, and deafening.</code>
 
::<code><font color="darkgreen">[...]</font>; rule succeeds with result the whisper outcome. <font color="darkgreen">[Rückgabe von einem Objekt 'whisper outcome']</font></code>
 
::<code><font color="darkgreen">[...]</font>; whisper.<font color="darkgreen">[die Regel hat ein erfolgreiches Ergebnis, das whisper benannt wurde]</font></code>
 
::<code><font color="darkgreen">[...]</font>; rule succeeds with result my fabulous doodad.<font color="darkgreen">[Rückgabe von einem named value]</font></code>
 
::<code><font color="darkgreen">[...]</font>; rule fails with result "In your dreams."<font color="darkgreen"> [Rückgabe von Text; ein fehlgeschlagenes (nicht benanntes) Ergebnis]</font></code>
 
* Wenn man neue Regelbücher schreibt, muss man irgendwo im Code festlegen, wann sie aufgerufen werden sollen. Dafür sind die Schlüsselwörter <code>consider</code>, <code>follow</code>, <code>abide by</code> (das ich im Anwendungsbeispiel der Regeln schon verwendet habe) und <code>anonymously abide by</code> wichtig. Wenn wir mal in diese Verlegenheit kommen sollten, müssen wir [http://www.ifwiki.org/index.php/Inform_7_for_Programmers/Part_3#Rulebooks:_White-box_Paradigm hier] oder in der [http://www.inform-fiction.org/I7/Manual.html I7-Doku] (Kapitel [http://www.inform-fiction.org/I7/doc326.html 18.15]/[http://www.inform-fiction.org/I7/doc327.html 18.16]) nachschlagen; es ist dort IMHO gut erklärt.
 
 
 
=== Regelbücher und Actions ===
 
* Das prinzipielle IF-Szenario ist: Die Spielerin steuert den Avatar/die Spielfigur durch Befehle, die von IF als Actions interpretiert werden. Diese Actions sind Regelgeleitet. Das heißt, wenn die Spielerin <code>examine Sim0n3</code> eingibt, wird zunächst geschaut, zu welcher Action der Befehl <code>examine (thing)</code> gehört, nämlich zu <code>examining</code>.
 
** Nebenbemerkung: Man kann zum Beispiel mit <code>understand "examine (book)" as reading</code> die Zuordnung: Befehl <-> Action verändern.
 
* Wenn man eine neue Action erstellt, werden automatisch 3 Regelbüchern erstellt, die jedoch zunächst leer sind und erst mit Regeln gefüllt werden können
 
** Nebenbemerkung: Ich habe in der [[Benutzer:Andyk/Mitschriften/PSI_06_12_08_Inform7_Einf%C3%BChrung#Aktionen|Inform7-Einführung]] schon einmal etwas über Actions geschrieben, wobei das dort noch relativ rudimentär erklärt war (und eigentlich auch nicht sauber programmiert). Ich versuche es jetzt in einem neuen Anlauf:
 
 
 
Eine Action erstellt man in zwei Schritten:
 
* Action mit ihrem Namen und ihren Parametern definieren. Die Parameter können nicht nur Objekte, sondern auch kinds of values sein. Ich übernehme die folgende Liste aus dem Tutorial:
 
:<code>Donating is an action applying to one thing. <font color="darkgreen">[Man kann hier statt thing nicht genauer werden, z.B. device oder so verwenden]</font></code>
 
:<code>Discussing is an action applying to one topic.</code>
 
:<code>Accusing it of is an action applying to one object and one visible object.</code>
 
:<code>Tabulating is an action applying to one number and requiring light.</code>
 
:<code>Scheduling is an action applying to one time.</code>
 
:<code>Temporarily waiting is an action applying to one time period.</code>
 
:<code>Whining is an action applying to nothing.</code>
 
:<code>Teleporting to is an action applying to one room.</code>
 
:<code>Saving the game is an action out of world applying to nothing.</code>
 
:<code>Tattooing it of is an action applying to one limb and one thing, requiring light.</code>
 
:<code>Weaving is an action with past participle woven, applying to one thing.</code>
 
 
 
* Drei Regelbücher, die für jede Actions erstellt werden, sind das <code>check</code>-, das <code>carry out</code>- und das <code>report</code>-Regelbuch. Man muss (bzw. sollte) sie mit entsprechendem Inhalt füllen:
 
** '''CHECK:'''' Hier wird überprüft, ob die Action überhaupt ausgeführt werden kann. Welche Vorbedinungen sind nötig?(Beispiel: Lesen kann man nur ein Buch.)
 
** '''CARRY OUT:''' Hier wird die eigentliche Aktion durchgeführt. Die Zustände der Welt können verändert werden. Es sollte aber kein Text ausgegeben werden (sonst wird <code>try silently</code> nicht den erwünschten Sinn haben, siehe nächster Absatz)
 
** '''REPORT:''' Das, was getan wurde, kann hier nochmal kommentiert werden. (Beispiel eine Textausgabe: "Die Tür ist nun geöffnet.")
 
** Was noch erwähnenswert ist, wenn man Regeln für Actions schreibt: Falls man sich auf die Parameter beziehen will, für die die aktuelle Action angewandt wird, referenziert man Objekte mit <code>the noun</code>, <code>the second nount</code> usw. Man kann aber, wenn es sich nicht um Objekte handelt, sondern um Zahlen, Text oder anderen kinds of values, diese referenzieren mit <code>the number understood</code>, <code>the text understood</code>, <code>the time understood</code>, ...
 
 
 
Man kann Actions auch ohne <code>Understand</code>-Sätzen aufrufen, und zwar mit <code>try</code>:
 
* <code>try Bob donating the jeans;</code>
 
* <code>silently try donating the red Porsche;<font color="darkgreen">[Silently bedeutet: Alle Reporting-Rules werden übersprungen]</font></code>
 
* <code>try teleporting to the tattoo parlor;<font color="darkgreen">[Man braucht hier keinen Parameter angeben, weil die Spielfigur, die die Action ausführt, automatisch in den Parameter hineingesteckt wird]</font></code>
 
 
 
 
 
Außerdem kann man Actions in einer Variable abspeichern und erst später aufrufen:
 
:<code>An abeyance is a '''stored action''' that varies.</code>
 
:<code><font color="darkgreen">[...]</font>; now the abeyance is '''the action of''' Bob examining the player; </code>
 
:<code><font color="darkgreen">[...]</font>; try the abeyance; </code>
 
:<code><font color="darkgreen">[...]</font>; now abeyance is '''the action of''' the current manager firing the noun; </code>
 
 
 
=== Weitere Details bzgl. der Reihenfolge der Regelbücher bei Actions ===
 
Die drei oben beschriebenen Regelbücher (check, carry out, report) sind nicht die ganze Wahrheit, wie das Tutorial deutlich macht. Für jede Action werden eigens diese drei Regelbücher erstellt. Außerdem gibt es für alle Actions noch gemeinsame Regelbücher. Im Folgenden die Reihenfolge der Regelbücher, die ausgeführt werden:
 
* '''Setting Action Variables for <action>''': Dieses Regelbuch wird auch für jede Action erstellt. Hier können Variablen gesetzt werden, die innerhalb der Action gebraucht werden. Sie sind auch nur dort gültig.  Meistens braucht man dieses Regelbuch aber nicht.
 
* '''Before''': Anhand der Reihenfolge sieht man, dass diese Aktionen noch VOR der eigentlichen Action kommen. Man kann hier z.B. Ergänzungen von Standardaktionen reinbringen.
 
** für NPCs: '''Persuasion''': Hier wird überprüft, ob - wenn die Spielerin einen NPC auffordert, etwas zu tun - der NPC der Aufforderung nachkommt. Falls nicht, soll das entsprechend kommuniziert werden.
 
* '''Instead''': hier ist das Default-Ergebnis: Failure, das heißt, im Normalfall wird nur eine Regel ausgeführt, und dann wird aufgehört). Ist geeignet, um einzelne oder Gruppen von Standard-Actions zu blockieren.
 
* '''Check <action>''': Bereits von oben bekannt.
 
** '''Unsuccessful Attempt By''': Kommt nur bei NPCs zum Zug, wenn Instead oder Check ein fehlgeschlagendes Ergebnis liefern. Regeln dieser Art kommen zum Zug, wenn der NPC die Aufforderung zwar annimmt, aber eine CHECK oder INSTEAD-OF-Regel ihn daran hindert, der Aufforderung nachzukommen. Beispiel: Man kann dem Wächter befehlen, die Tür zu öffnen und selbst wenn er so nett ist und das tatsächlich tun würde, wäre das noch keine Garantie dafür, dass er es tun kann (weil er z.B. den Schlüssel nicht hat).
 
* '''Carry out <action>''': Bereits von oben bekannt.
 
* '''After''': hier ist das Default-Ergebnis: Success, das heißt, im Normalfall wird nur eine Regel ausgeführt, und dann wird aufgehört. Außerdem werden die Report-Rules übergangen, wenn outcome=success. Dieses Rulebook ist nützlich für Szenenwechsel oder um bestimmte wichtige Scenen einzuleiten. Beispiel: Nachdem du den Schlüssel gefunden hast, wirst du von den Wachen in den Kerker geworfen (Verdacht: Landesverrat).
 
* '''Report <action>''': Wie gesagt - bei <code>try silently</code> wird dieses Regelbuch übersprungen.
 
 
 
* Was noch ganz informativ ist: <code>an actor</code> schließt NPCs und die Spielerin ein, <code>someone</code> meint nur die NPCs und wenn kein Subjekt genannt ist, dann ist die Spielerin gemeint. Instruktive Beispiele aus dem Tutorial:
 
:<code>Instead of Tiny jumping: say "Tiny is too overweight to jump. You all must find another way to help him across."</code>
 
:<code>Carry out an actor jumping: now the actor is on the nearby platform. <font color="darkgreen">["an actor" applies to everyone]</font></code>
 
:<code>Report someone jumping: say "You see [the actor] jump over." <font color="darkgreen">["someone" applies to any NPC]</font></code>
 
:<code>Report jumping: say "You jump over." <font color="darkgreen">[subject-less means the player]</font></code>
 
 
 
 
 
'''''2,5 of 5 TUTORIAL-PARTS studied. TO BE CONTINUED...'''''
 
 
 
* Eventuell sollte ich diesen Einschub auf eine extra Seite geben und dann nur eine Referenz drauflegen.
 
* Übrigens: Wenn man [http://www.google.at/search?hl=de&q=inform7&btnG=Suche&meta=lr%3Dlang_de "Inform7" im deutschsprachigen Google] eingibt, bekommt man einige Ergebnisse, die beim Philo-Wiki landen. --[[Benutzer:Andyk|Andyk]] 18:54, 27. Feb. 2009 (UTC)
 

Version vom 1. März 2009, 14:46 Uhr

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

09.02.2009: Session 1

Ich habe vor, an dieser Stelle so etwas wie ein Projekttagebuch zu führen, das die Ideen, die mir beim Lesen der Bücher 3,4 und 5 kommen, kommentiert (Selbst-Dokumentation). Einzelne inhaltliche Ergebnisse (wie z.B. Inform7Code oder Analyseergebnisse, Storyboard-Ideen, Raumgestaltungen, etc.) werde ich dann nochmals explizit und pointierter an anderer Stelle verlinken, sodass man sich nicht durch das Tagebuch wälzen muss. Wer will – ich denke, dass es sinnvoll ist - kann sich an dieser Unternehmung beteiligen; kommentieren, kritisieren, erläutern. Wenn nur ein Kopf denkt, passiert es unter Umständen, dass man sich irgendwohin verfährt – und ein Vorzug unseres Projektes (also einer Kooperation) soll es ja sein, so etwas zu verhindern.

Vorbemerkungen, Zielsetzung

Bevor ich zu lesen beginne, sollte ich mir im Klaren werden, in welche Richtung ich lesen soll – also worauf ich achten soll. Als ich die besagten Bücher das erste Mal gelesen habe, hat sich bei mir auf jeden Fall so etwas wie ein elementartiger Aufbau des Staates eröffnet, der für eine objektorientierte Analyse, wie wir sie für Inform7 gut gebrauchen können, geeignet scheint. Es wird – das wurde schon angemerkt - sehr konkret beschrieben, wie der Staat auszusehen hat, wer welche Aufgaben hat, etc. Beim Lesen möchte ich mal überwiegend bei Platons Gedankenexperiment bleiben und den Gegenwartsbezug - den wir diskutiert haben und den ich auch für sinnvoll erachte - auf später verschieben, da ich fürchte, dass es beim Lesen zu sehr ablenken könnte, es sei denn, es gibt eine penetrante Assoziation, dann werde ich das kurz anmerken. Ich werde bei Motivation und Gelegenheit ein kleines Exzerpt des Buches „Methoden der objektorientierten Systemanalyse“ von Heide Balzert anfertigen, wo es darum geht, wie man die richtigen Klassen (in Inform: Kinds) und Attribute (in Inform: Kind of values) findet; einfach gesagt handelt es sich um eine Methode zur Analyse eines prosa-artigen Textes (wie z.B. eines Pflichtenhefts oder in unserem Fall eines Platon-Werks).

Wo anfangen?

Wollte eigentlich mit Buch 3 anfangen, aber irgendwie hat sich mir der Gedanke ergeben, dass man noch weiter vorne zu analysieren beginnen müsste. Deshalb bin ich nochmal zu Buch 2 und der Gyges-Stelle zurückgegangen. Die Motivation, warum Glaukon das vorschlägt ist ja, dass er beweisen will, dass man nur gerecht handelt, wenn man nicht anders kann. Wenn man freigestellt ist und nicht mit Konsequenzen rechnen muss, dann tut man Unrecht. Und was dann ab 360e kommt ist eigentlich Objektorientierung in Reinform. Glaukon geht von zwei Klassen/Konzepte „Gerechter“ und „Ungerechter“ aus wie von zwei Tierarten (Katze und Maus) – beide verhalten sich völlig anders und haben auch ganz andere Eigenschaften. Wir stellen „jeden als vollendet in seiner Art hin“. Hier werde ich wahrscheinlich das nächste Mal beginnen, ein paar Merkmale von Glaukons Modellierung Gerechter/Ungerechter zu explizieren.--Andyk 01:10, 13. Feb. 2009 (CET)

„Der Gipfel der Ungerechtigkeit ist es, gerecht zu scheinen, ohne es zu sein.“

22.02.2009: Session 2: Sein und Schein

Nun hab ich endlich Zeit gefunden, ein paar meiner Notizen von letzter Woche zu digitalisieren. Das letzte Mal habe ich bemerkt, dass Glaukon die beiden Personen Gerechter und Ungerechter ganz genau auseinanderdividiert und dass sich das ganz gut mit Objektorientierter Modellierung verbinden lässt. Ich habe versucht, in einer kleinen Inform7-Implementierung und parallel dazu allgemein anhand eines Klassendiagramms wichtige Teile von dieser Gegenüberstellung von Gerechtem und Ungerechtem zu modellieren. Diese Gegenüberstellung ist von Glaukon genau so konstruiert, dass es darauf hinausläuft, dass man nur aus Zwang gerecht handelt. Ein wichtiges Werkzeug, damit diese Konsequenz aufgeht, ist die Unterscheidung von Sein und Schein.

  • Eine ideale Gerechte Person IST gerecht, und muss auch, wenn sie den Leuten ungerecht erscheint, gerecht handeln. (Wobei ich mich frage, wie man ganz persönlich wissen kann, was gerecht IST, wenn man bei jeder gerechten Handlung eine auf den Deckel bekommt, weil die gerechte Handlung dem Anschein nach ungerecht ist. Das führt wohl bereits hin zur Rolle der Erziehung und der sozialen Verstrickungen.)
  • Eine ideale ungerechte Person vollzieht ihre ungerechten Taten derart, dass man ihr nie draufkommt, dass die Taten "in Wirklichkeit" ungerecht sind, was zur Folge hat, dass auch sie selbst von 'den Leuten' als gerecht gesehen wird. Durch Rhetorik, Tapferkeit, Beziehungen baut sie den Schein der Gerechtigkeit auf. Falls sie einmal einen Fehler begeht, helfen ihr diese Fähigkeiten, ihn auszubalanzieren.
  • Ich habe auch noch 'die Leute' modelliert, denn man kann sich fragen, welcher Gerechtigkeitsstatus denen zukommt. Ich habe die Entscheidung getroffen, dass ihre Erscheinung 'neutral' ist (sozusagen: die graue Masse, die nicht besonders auffällt) und dass ihr Sein 'unentschieden' ist. Diese Leute sollte man nicht als eigenständige Personen sehen, sondern eher als die Vorstellung die man sich selbst als Antwort auf die Frage 'Wie könnte man meine Handlung beurteilen?' gibt. In der Glaukon-Argumentation ist das jedenfalls nicht so im Vordergrund, aber IMHO eine wichtige Frage. Denn wenn diejenigen, die den Gerechtigkeitsstatus beurteilen (den Ungerechten loben und den Gerechten Foltern, Fesseln und Kreuzigen), alle gerechte Leute sind, dann müssten sie wissen, dass gerechte Handlungen nicht immer gerecht erscheinen. Und wenn sie ungerechte Leute sind, kann man sich auf ihr Urteil nicht verlassen, da es ihnen nicht um den Gerechtigkeitsstatus der Handlung geht, sondern darum, welche Vorteile eine bestimmte Beurteilung für sie selbst bringt.

Wenn man 'Hochbegabt an Leib und Seele' ist, warum sollte man ungerecht sein?

  • Diese Trennung von Gerechter und Ungerechter hat den Sinn, dass man sie am Ende einander gegenüberstellen kann: "[...] dann sollen sie beurteilt werden, wer der glücklichere ist."
  • Wenn man sich durchliest, was der Ungerechte so alles vollbringen soll dann wünsch ich mir schon rein aus Faulheit bzw. weil es zu stressig ist, nicht ungerecht zu sein. Ein Anforderungsbeispiel, das eine ideale ungerechte Person erfüllen muss:
    • Sie muss das Durchführbare sogut wie immer vom Undurchführbaren auseinanderhalten. Das geht nicht. Wenn sie Fehler macht, hat sie zwar ihre Redekunst und ihre Beziehungen, ihre körperliche Kraft und das ungerecht verdiente Geld zur Hilfe, aber die Fehler dürfen nicht zu häufig sein, denn sonst wird der Schein bald löchrig. Das dürfte ein ungeheurer Druck sein, dem man ausgesetzt ist.
  • Das Problem, dass man in Inform7 durch überlagerte Szenarios deutlich machen könnte ist, dass es zu anstrengend ist ungerecht zu sein, da man Fehler macht und dass Ehrlichkeit (im Schein das Sein durchblicken lassen --> Transparenz) auch für sich selbst vorteilhaft ist, weil man nicht so streng auf die Konsistenz der Mauer des Scheins zu achten braucht.
  • Das ist nur so eine Idee, die von der Rezeption wegführt. Bis jetzt habe ich eher die Glaukon-Idee, dass der Ungerechte immer belohnt wird, in Inform7 integriert.

Inform7-Implementierungsentwurf

Klassendiagramm über wichtige Stellen von Glaukons Argumentation
  • Ich habe im Probegalopp-SVN-Verzeichnis das Modell, das ich allgemein in Form eines Klassendiagramms dargestellt habe, versucht in Inform7 zu implementieren. Das Ganze ist noch nicht sehr anspruchsvoll und hat keine Handlung. Ein paar Bemerkungen dazu:
  • Es gibt einen Status der Gerechtigkeit, der einen der folgenden Werte annehmen kann: gerecht, ungerecht, unentschieden, neutral.
  • Jeder Mensch kann charakterisiert werden durch sein Sein und durch seinen Schein. Sein und Schein sind jeweils Stati der Gerechtigkeit.
  • Die Gruppe der Menschen kann in Untergruppen aufgespalten werden: Gerechte, Ungerechte und Neutrale ('die Leute').
  • Mensch ('human') soll in diesem Framework statt dem Inform7-Konzept 'person' verwendet werden.
  • Handlungen können gerecht oder ungerecht sein (als kinds of actions modelliert). Man kann mit einer Zuweisung der folgenden Art bestimmen, um welche Art von Handlung es sich handelt:
Attacking is unjust action.
Kissing is just action.
  • Es gibt nun 4 Kombinationen, die auftreten können, wenn ein Mensch eine Handlung vollzieht:
    • Gerechter Mensch --> Gerechte Handlung:
    • Gerechter Mensch --> Ungerechte Handlung
    • Ungerechter Mensch --> Ungerechte Handlung
    • Ungerechter Mensch --> Gerechte Handlung
  • Die Logik der von mir modellierten Welt verhindert, dass ein Gerechter Mensch ungerechte Handlungen vollzieht und ein ungerechter Mensch gerechte Handlungen. (Details siehe Inform7-Code)
  • In jedem Menschen ist ein Zähler integriert, der zählt, wieviele gerechte respektive ungerechte Handlungen versucht bzw. durchgeführt worden sind (Das könnte einem am Ende vor die Nase gehalten werden)
  • Interessant finde ich, dass die Kapselung des Seins gegenüber dem Schein IMHO genau der Kapselung von privaten und öffentlichen Variablen in der Objektorientierten Programmierung entspricht. Im Klassendiagramm habe ich das folgendermaßen angedeutet:
    • sowohl Being als auch Appearance sind private Variablen. Das deutet das Zeichen '-' üblicherweise an.
    • die öffentliche Funktion getAppearance bedeutet, dass jede andere Klasse (also jeder andere Mensch zum Beispiel) die Erscheinung ansehen kann. (öffentliche Variablen oder Funktionen werden mit dem vorangehenden Zeichen '+' angedeutet)
    • da es keine getBeing-Funktion gibt, weiß niemand (außer die Programmierer) ob dieser Mensch seinem Wesen nach ein gerechter oder ein ungerechter Mensch ist (niemand würde eine Änderung der privaten Variable Sein direkt bemerken - es sei denn, dass sie in der Funktion getAppearance irgendwie verwendet würde).
    • Man hat hier also genau die Unterscheidung zwischen öffentlicher Fassade und geheimer, interner Programmlogik (wie plausibel das in unserer Welt ist, ist eine andere Frage, aber sowohl bei diesen Platon-Stellen als auch in der Objektorientierten Welt kann ich diese Struktur erkennen).
  • Was sich aus diesem Framework machen ließe:
    • Zunächst wählt die Spielerin, was sie gerne SEIN würde (welche Auswirkungen das auf ihre Erscheinung hat, lässt man im Unklaren)
    • Nun wird die Spielerin vor bestimmte Probleme gestellt, die sie lösen muss (wobei die Regeln der Welt gelten, dass gerechte Personen nur gerecht handeln können und vice versa mutatis mutandis; der Versuch wird mitgezählt)
    • Entsprechend Glaukon muss ein gerechter Mensch auf jeden Fall getötet werden und ein ungerechter muss das Spiel auf jeden Fall gewinnen.
    • Man könnte ab einer bestimmten Anzahl an Versuchen, entgegen seinem Sein zu handeln, das Sein der Spielerin verändern (von Gerecht auf Ungerecht und vice versa). Auch das könnte man mitzählen (nicht implementiert).
    • Das wäre ein kleines Motivationsspiel für die Frage der Gerechtigkeit, die dann im Staat mit dem Aspekt der Erziehung und der Gemeinschaft beleuchtet wird.

'einen Staat in einem Dennkentwurf entstehen lassen' [369a]

Im Folgenden ein paar Überlegungen und Aspekte, die mir im zweiten Buch bei der Entstehung des Staates (ab ca. 369a) aufgefallen sind:

  • 369b: ein Staat entsteht, weil keiner von uns auf sich alleinn gestellt sein kann, sondern vieler anderer bedarf.
    • Eine Stelle, dir mir interessant erscheint: "da sie [die Leute] vielerlei Bedürfnisse haben, so lassen wir viele in einer Siedlung als Mitbürger und Helfer zusammenkommen; dieser Siedlungsgemeinschaft geben wir den Nameen Staat". Und ein paar Zeilen später: "Nun wollen wir in Gedanken einen Staat von Anfang an entstehen lassen. Es schafft ihn aber, so glaube ich, unsere eigene Bedürftigkeit!"
    • Wie kann man das <Es schafft ihn aber unsere eigene Bedürftigkeit> verstehen? Vielleicht so? Die ganze Staatskonzeption passiert nicht zum Spaß, sondern aufgrund der Notwendigkeit heraus, dass solche Zweckgemeinschaften selbst einer gewissen Struktur bedürftig sind.

Ansatz für unser Projekt

  • Zu Spielbeginn sind wir mit einer Art Reiseführer oder Erzähler konfrontiert, der die Spielerin zunächst in die Glaukon/Adeimantos-Welt (vgl. Implementierungsentwurf oben) teleportiert. Das ist eine ganz simple Welt mit wenigen Gesetzen und ohne staatlicher Struktur, die von der folgenden Grundüberlegung ausgeht:
    • wie willst du das Beste aus deinem Leben machen? Warum glaubst du, bist du überhaupt hier? du glaubst, du kannst entspannen bei einer gemütlichen Interactive Fiction? weit gefehlt. Du bekommst die einmalige Chance, dein Leben neu anzufangen. Mach das Beste daraus; Viel Spaß.
    • Dann könnte man im oben beschriebenen Setting erste aufgaben bekommen (vielleicht auch Aufgaben, die alleine nicht zu lösen sind, die man nur im Zusammenhang eines Staates lösen kann - was eine gute Überleitung zur Welt des Staats sein könnte)
  • Solche Reiseführer oder Erzähler kenne ich aus den typischen 2D-Adventures. Meistens stellt sich bei solchen Spielen heraus, dass dieser Reiseführer / der Erzähler eng mit dem Plot verflochten ist, d.h. die Spielerin deswegen gerufen hat, weil er in ärgsten Schwierigkeiten steckt.
  • Und ist es nicht so? ;) Wir wollen doch tatsächlich durch dieses Projekt etwas herausfinden, was uns Platons Konzept der Gerechtigkeit im Rahmen der Staatskonzeption besser verstehen lässtt?
  • Zunächst liegt es an uns, dass wir durch die Entwicklung der Rahmengeschichte tatsächlich ein paar Schritte in dieser Frage weiterkommen, denn Geschichten und den Inform-7-Code muss man schreiben, sonst hat die Spielerin keine Möglichkeit, zu spielen.
  • Für die Spielentwicklung ist die Spielerin also ein Platzhalter, der - wenn das Spiel zu Ende ist - in den Plot vollständig integriert ist (der Platzhalter wurde also im Laufe des Spiels allmählich immer mehr bestimmt) zumindest hab ich das bei den Adventures, die ich gespielt habe (Monkey Island, Indiana Jones, Sam'n'Max, Simon the Sorcerer,...) so erlebt.
  • Dieser sich allmählich bestimmende Platzhalter hat im Entwicklungsprozess eine wichtie Rolle: Durch ihn ist man gezwungen, Entscheidungen im Handlungsverlauf und im Weltenbau zu treffen, sodass die Spielerin, die prinzipiell jede(r) sein kann, ...
    • den Sinn der Geschichte versteht
    • weiß, was sie für eine Rolle in der Handlung einnimt
    • weiß, wie sie prinzipiell ihre Aufgaben erfüllen kann, um in der Geschichte weiterzukommen
    • Spaß dabei hat und etwas daraus lernt.

Ausblick: Was mich noch interessiert

  • Möchte mir die Code-Beispiele, die vor allem von H.A.L gemacht wurden, noch genau anschauen.
  • Ein paar Texte über die theoretischen Ansätze der Interaktivität begutachten
  • Ein bisschen mehr mit Inform7 machen. Ich komm mir bei dieser Art von Programmierung immer noch ein bisschen Fehl am Platz vor. Der Ansatz der natürlichen Sprache ist eine Sache, doch auf der anderen Seite kann man zum Beispiel von der Klasse 'object' nicht direkt ableiten, sondern muss 'thing' verwendet, um die vorgegebenen Strukturen einer Interactive Fiction nicht durcheinanderzubringen. Ganz wohl fühle ich mich jedenfalls noch nicht mit Inform7.--Andyk 18:09, 22. Feb. 2009 (CET)

24.02.2009: Session 3: Objektorienterte Analyse

Motivation für diese Session

Ich möchte in diesser Session von dem in Session1 erwähnten Buch v. Helmut Balzert „Methoden der objektorientierten Systemanalyse“ eine Darstellung in Hinblick auf unsere gemeinsame Arbeit versuchen und darüber hinaus eine Rahmenstruktur vorschlagen, die wir beim Lesen von Platons „Der Staat“ für das Erarbeiten der Inform7-Welt verwenden können.


Ich mache das vor dem Hintergrund des folgenden Problems: Wenn wir die zentralen Stellen in Plaons „Der Staat“ lesen, wo es um die Frage geht: „Wie kann ein idealer Staat aussehen?“ dann können wir daran etwas verstehen und jeder wird sein Verständnis in einer anderen Art und Weise zum Ausdruck bringen. Da wir jedoch trotz des natürlichsprachigen Ansatzes von Inform7 mit einer Programmiersprache arbeiten müssen, sollten wir unser Verständnis so ausdrücken, dass zwei Punkte erfüllt sind:
  • Wir (jede Teilnehmerin unseres Projekts) können anhand der Ausdrücke nachvolllziehen, worum es geht
  • die Ausdrücke können ohne großem Interpretationsaufwand von den Teilnehmerinnen, die für die Inform7-Implementierung zuständig sind, in Inform7-Code umgesetzt werden. Man soll während der Implementierung nicht mehr überlegen müssen, wie das jetzt gemeint ist – denn das sollte in der vorherigen Phase schon passiert sein und würde die ganze vorherige Interpretations- und Modellierungsabeit wieder zunichte machen. Das zwingt uns außerdem auch, so konkret wie notwendig die einzelnen Ausgestaltungen unseres platonischen Staates zu entwerfen.

Genau zu diesem Zweck bietet sich Objektorientierte Analyse an. Es wird jedoch in dieser verkürzten informatischen Terminologie kaum eine Philosophin mit dieser Art von Ausdrücken vertraut sein, weshalb ich nun versuchen will, die wichtigsten Notationselemente und Begriffe kurz zu erklären und gleich mit der Notation, wie sie in Inform7 verwendet wird, zu verbinden.

Objekt (Inform7: thing)

  • [Balzert, S.31-36]
Definition

Ein Objekt „ist [..] ein Gegenstand des Interesses, insbesondere einer Beobachtung, Untersuchung oder Messung.“

Beispiele
  • Dinge ( ein ganz bestimmter Opel Manta, ein Ring, der Hörsaal 3D, die Stadt Wien)
  • Personen ( Gyges, Adeimantos, Sokrates, der da drüben mit der roten Haube )
  • Begriffe ( eine bestimmte Gerechtigkeit, eine bestimmte Krankheit, eine bestimmte Besonnenheit)
Merkmale
  • Ein Objekt ist ein konkretes Einzelding, wobei es vom Abstraktionsgrad abhängt, was man unter Einzelding verstehen will.
  • „In der objektorienterten Softwareentwicklung besitzt ein Objekt bestimmte Eigenschaften und reagiert mit einem definierten Verhalten auf seine Umgebung.“
„Die Eigenschaften eines Objektes werden durch dessen Attributwerte ausgedrückt“
Das Verhalten des Objekts wird „durch eine Menge von Operationen (Funktionen) ausgedrückt“
  • „Außerdem besitzt jedes Objekt eine bestimmte Identiät, die es von allen anderen Objekten unterscheidet.“ „Objektidentität bedeutet, daß alle Objekte aufgrund ihrer Existenz unterscheidbar sind, auch dann wenn sie zufällig identische Attributwerte besitzen. Die Identität eines Objekts kann sich nicht ändern.“

Klasse (Inform7: Kind of)

  • [Balzert, S.36-46]

Man kann Objekte besser verstehen, wenn man ähnliche von ihnen zu einer Gruppe zusammenfasst und sagt: Objekte, die diese Eigenschaften (Attribute) und diese Funktionen (Operationen) haben, sind alle von der Art/Klasse „Mensch“. Man klassifiziert alle Objekte eines bestimmten Ausschnittes der Welt (das ist so etwas Ähnliches wie die bei Aristoteles bekannte Ontologie).

In der Softwareentwicklung kehrt man diesen Prozess ein wenig um und sagt: Ausgehend von dieser Klasse (die diese Attribute und jene Operationen hat) leiten sich Objekte ab, bei denen Attribute einen konkreten Wert haben (zum Beispiel: das Attribut 'Alter' hat den Wert '23') und Operationen unter Umständen die Attribute des Objekts verändern können (dazu genauer etwas später).

Definition

„Eine Klasse beschreibt eine Kollektion von Objekten mit gleichen Eigenschaften (Attribute), gemeinsamer Funktionalität (Operationen), gemeinsamen Beziehungen zu anderen Objekten und gemeinsamer Semantik. Ferner legt die Klasse fest, wie neue Objekte dieser Klasse erzeugt werden. Eine Klasse definiert also die Eigenschaften und das Verhalten ihrer Objekte.“

Beispiel (von der Betrachtung der Einzeldinge zur Klassifikation)

Ich betrachte das Ding zu meiner Linken. Es ist gelb. Es steht darauf geschrieben „Platon. Der Staat. Reclam“. Dieses Ding ist aus Papier. Man kann es aufschlagen. Wenn man es aufschlägt, finden sich, symmetrisch aufgeteilt gedruckte Sätze. Im linken Bereich des Dings findet sich links oben eine Zahl. Im rechten Bereich findet sich rechts oben eine Zahl, die um 1 größer ist als die Zahl im linken Bereich. Es stellt sich heraus, dass die Bereiche fortlaufend durchnummeriert sind.

Ich betrachte das Ding zu meiner Rechten. Es ist blau. Es steht darauf geschrieben „Heide Balzert. Medhoden der objektorientierten Systemanalyse. Angewandte Informatik. Herausgegeben von Helmut Balzert.“. Dieses Ding ist ebenfalls aus Papier und man kann es aufschlagen. Die Nummerierung der Bereiche ist ähnlich wie bei dem gelben Ding.

Das Ding links, ich nenne es „gelbSchlag“, hat nach meiner obigen Betrachtung folgende Eigenschaften:

  • Farbe: gelb
  • Material: Papier
  • Inhalt: gedruckte Sätze, nummeriert

Man kann folgende Dinge mit „gelbSchlag“ durchführen:

  • Aufschlagen
  • Weiterblättern

Das Ding rechts, ich nenne es „blauSchlag“, hat demnach folgende Eigenschaften:

  • Farbe: blau
  • Material: Papier
  • Inhalt: gedruckte Sätze, nummeriert

Folgende Dinge kann man mit „blauSchlag“ durchführen:

  • Aufschlagen
  • Weiterblättern

Es scheint so, als ob es zwischen diesen beiden Dingen eine Ähnlichkeit geben würde. Beide Dinge haben eine Farbe, sind aus dem Material „Papier“ und ihr Inhalt ist „gedruckte Sätze, nummeriert“. Beide kann man Aufschlagen und Weiterblättern. Von nun an gehören diese beiden und alle Dinge, die solche Eigenschaften und Operationen aufweisen, zur Klasse „Buch“.

Ich habe versucht, die obige in Sprache verfasste Analyse der beiden Bücher in Inform7 unterzubringen. (vgl. weiter unten )

Attribut (Inform7: Properties / Kind of Value)

  • [Balzert S.46-53]
Definition

„Die Attribute beschreiben die Daten bzw. die Eigenschaften einer Klasse. Alle Objekte einer Klasse besitzen dieselben Attribute, doch unterschiedliche Attributwerte.“

Beispiel
  • Wir haben oben die Klasse Bücher gefunden. Typische Attribute, die ich in der obigen Analyse beschrieben habe, sind: Buchtitel, Farbe und Material.
  • In Inform7 definiert man Attribute mit <kind> has a <kind of value> called <Attributname>. Zusätzlich muss man angeben, welche Werte diese Attribute annehmen können (Werte-Bereich alias Kind of Value). Standard-Wertebereiche sind 'text' oder 'numbers'. Falls man neue definieren will, muss man einen neuen Kind of Value definieren (unten im Beispiel bei side geschehen.
Merkmale
  • „Der Attributname muss im Kontext der Klasse eindeutig sein.“
  • „Im allgemeinen wird ein Substantiv dafür verwendet“. (die Farbe, der Titel,...)
  • Bei reiner Objektorientierung (bei Inform ist das nicht der Fall) dürfen die Attribute nur überc die Operationen der Klasse geändert werden. „Die Attribute sind zwar sichtbar für den Systemanalytiker, aber nicht sichtbar für andere Klassen bzw. deren Objekte.“ (Dieses Konzept nennt man auch Information Hiding)

Operation (Inform7: ungefähr Action)

  • [Balzert S.53-60]
Definition

„Operationen beschreiben die Funktionalität eines Objekts. Eine Operation ist eine ausführbare Tätigkeit im Sinne einer Funktion bzw. eines Algorithmus. Sie kommuniziert mit anderen Objekten über Ein-/Ausgabe-Parameter.[...]Operationen werden jeweils auf ein einzelnes Objekt angewandt.“

Beispiele
  • Wir haben oben die Beiden Operationen „Aufschlagen“ und „Weiterblättern“ gefunden (wobei wir davon ausgegangen sind, dass wir wissen, was beim Aufschlagen und Weiterblättern mit dem Buch passiert.
Merkmale
  • In Inform7 gibt es dieses Konzept meines Wissens nach nicht in dem genauen Sinn, da man bestimmte 'actions' auch dazu verwenden kann, 'properties' von anderen 'things' (Objekten) verändern kann. Anders gesagt: Man kann die 'actions' nicht einem 'thing' zurechnen – die actions in Inform7 bestehen eigenständig neben den Dingen in der Welt.

Beispiel, wie man das in Inform7 implementiern könnte

Verfügbar im Probegalopp-SVN-Verzeichnis

Kinds und Kind of Values

  • Buch-Definition:
    • Über einen Umweg: Ein Buch ist ein Gerät.

A book is a kind of device.
A book has a text called title. The title of a book is usually "".
A book has a text called color. The color of a book is usually "gray".
A book has a text called material. The material of a book is usually "paper".
A book has a text called content. The content of a book is usually "sentences and page numbers".
The description of a book is "A [color] book[if title of the noun is empty][otherwise] named [italic type][title][roman type][end if]. It is made of [material]. There are [italic type][content][roman type] in it.[if the noun is switched on]The book is open and I can see [a list of pages which are part of the noun].[end if]".

  • Ein Buch hat zwei Seiten (eine linke und eine rechte)

The side is a kind of value.
The plural of side is sides.
The sides are left and right and none.

A page is a kind of thing.
A page has a side called page side. The page side of a page is usually none.
A page has a number variable called page number. The page number is usually 1.
A page has a text variable called text. The text of a page is usually "[one of]The quick brown fox jumps over the lazy dog[or]Franz jagt im komplett verwahrlosten Taxi quer durch Bayern[or]kaufen sie jede woche vier gute bequeme pelze[or]ein wackerer bayer vertilgt jeden tag bequem zwo pfund schweinshaxe[or]karl mays pferdevieh sagt jawohl zur quellnixe am bach[or]zwölf süße boxkämpfer jagten quer durch vinyl[or]falsches üben von xylophonmusik quält jeden größeren zwerg.[or]Bei jedem klugen Wort von Sokrates rief Xanthippe zynisch: Quatsch! [or]Bei jedem klugen Wort von Sokrates rief Xanthippe zynisch: Quatsch![purely at random]".

The description of a page is "This is a [page side] page with page number [page number]. It is written: [italic type][text][roman type]".

A left page is a kind of page.
A right page is a kind of page.
The page side of a left page is left.
The page number of a left page is usually 1.
The page side of a right page is right.
The page number of a right page is usually 2.

[Two pages are parts of every book.]
A left page is part of every book.
A right page is part of every book.

Actions

  • Benutzereingaben mit Aktionen verknüpfen:

Understand "browse [something]" as browsing.
Understand "open [book]" as switching on.
Understand "read [something]" as reading.

Lesen

Reading is an action applying to one visible thing.

Check reading:
if the noun is not a book then say "I cannot read [the noun]. Maybe you should try a book!?" instead;

if the noun is not switched on
begin;

say "(first opening [the noun])[command clarification break]";
try switching on the noun;

end if.

Carry out reading:

Let L be the list of pages which are part of the noun;
repeat with item running through L
begin;
say "At [page side of item] page (#[page number of item]):[line break][italic type][text of item][roman type][paragraph break]";
end repeat.

Report reading:

say "To read more, I have to browse.".

Weiterblättern

Browsing is an action applying to one visible thing.

Check browsing:

if the noun is not a book then say "I cannot browse through [the noun]. Maybe you should try a book!?" instead;
if the noun is not switched on
begin;
say "(first opening [the noun])[command clarification break]";
try switching on the noun;
end if.

Carry out browsing:

pageswitch the noun.

Report browsing:

say "I switched to the next page".

To pageswitch (whatever - a book):

if whatever is not a book then say "[printed name of the noun] is not a book.";
Let L be the list of pages which are part of the noun;
repeat with item running through L:
increase the page number of item by 2.

Test-Welt

  • Zwei Bücher in einem Hauus
  • Die Wand ist nur eine Spielerei

The house is a room.

The wall is a backdrop. The wall is everywhere. The description of the wall is "[one of]This wall is from Pink Floyd.[or]Impenetrable.[purely at random]".
The yellowBrowser is a book in the house.
The color of the yellowBrowser is "yellow".
The title of the yellowBrowser is "Platons Politeia".

The blueBrowser is a book in the house.
The color of the blueBrowser is "blue".
The title of the blueBrowser is "Helmut Balzert: methods of object-oriented system analysis".

Test-Kommandos

  • Platon oder Balzert lesen

test readPlaton with "x yellowBrowser / open yellowBrowser / x yellowBrowser / read yellowBrowser / browse yellowBrowser / read yellowBrowser / browse yellowBrowser / read yellowBrowser"

test readBalzert with "x blueBrowser / browse blueBrowser / open blueBrowser / x blueBrowser / read browser / browse blueBrowser / browse blueBrowser / x blueBrowser / read blueBrowser".


Zusammenfassung und Ausblick

Anbei eine kleine Tabelle, die zusammenfassen soll, was für Objektorientierung typisch ist:

Konzept Inform7-Entsprechung Erklärung Beispiel Kommentar
Objekt thing einzelner Gegenstand des Interesses das gelbe Platon-Buch
Klasse kind beschreibt die Menge von Objekten mit gemeinsamen Attributen und Operationen Buch
Attribut property + kind of value beschreibt eine Eigenschaft einer Klasse Buchtitel Beim konkreten Objekt wird jedem Attribut ein Wert aus dem in der Klasse definierten Wertebereich zugewiesen.
Operation ~Action oder
"To ..."-Phrasen
Ausführbare Tätigkeit im Sinn einer Funktion oder eines Algorithmus Weiterblättern In Inform7 nicht innerhalb der Objekte, sondern eigenständig (in der Luft hängend) zu definieren. Besser ist IMHO zu sagen, dass es kein wirkliches Äquivalent zu Operationen in Inform7 gibt.
  • Anmerkung: Wie sich das gesamte Objektorientierte Konzept zu dem 'rules' in Inform7 verhält, muss noch eigens erörtert werden (da ich die 'rules' noch nicht ganz verstanden habe).

Nachdem die grundlegendsten Elemente und Begriffe der Objektorientierung nun erklärt sind und mir der Zusammenhang bzw. die Unterschiede mit Inform7 durch die Buch-Implementierung ein bisschen deutlicher geworden sind, kann es jetzt endlich darum gehen, die Vorschläge aus dem Balzert-Buch zusammenzufassen. Nämlich: Wie soll man am Besten vorgehen, um Objekte zu analysieren? Was mir jetzt etwas klarer geworden ist, ist das Problem, dass wir dadurch, dass Inform7 sich nicht ausschließlich an objektorientierte Konzepte hält sondern durch 'actions' und 'rules' aus der Reihe fällt, die Vorschläge aus dem Buch sicher nicht alle ohne Änderungen übernehmen können.

26.02. - 01.03.2009: Session 4: Einschub: Inform7 vs. Standard-Programmiersprachen

Um die Übersicht zu wahren, verlinke ich diese Session auf eine eigene Seite. Sie kann relativ unabhängig von den anderen Überlegungen verstanden werden, da es hauptsächlich um eine technische Auseinandersetzung mit den Möglichkeiten von Inform7 geht.