Benutzer:Andyk/Mitschriften/Inform 7 Rahmenstruktur
<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>
Inhaltsverzeichnis
Was ist das hier?
Ich möchte mir kurz überlegen, welche Elemente in einer Interactive Fiction vorkommen können (oder manchmal: müssen). Wenn man die Elemente kennt, muss man sich fragen…:
- wie man die Elemente näher beschreiben kann (descriptions, initial appearances, properties, …),
- in welche Struktur(en) sie eingebettet sind (Actions, Rules, Scenes, Relationen,…) und
- wie die Struktur genau ausschaut (To-Phrasen, Aktivitäten, Algorithmen, Schleifen, ...).
Über die Sinnhaftigkeit einer Rahmenstruktur
Natürlich kann man einwenden, dass die geistige Flexibilität durch eine solche Rahmenstruktur eingeschränkt wird, da man dem Inhalt durch sie bereits voreingenommen entgegentritt. Andererseits ist der Einsatz einer solchen Struktur verständlich: Sie ermöglicht die Umsetzung durch ein Minimum an Kompatibilität zwischen inhaltlichen Überlegungen und technischen Einschränkungen. Mein Lösungsvorschlag aus diesem Dilemma: Die Rahmenstruktur aus Sicht jener Struktur, die sich aus den inhaltlichen Überlegungen ergibt, in Frage stellen und (falls I7 uns das erlaubt) anpassen.
Es folgt nun also der Versuch, I7-Konzepte in Elemente, Elementspezifikationen, Strukturen, Strukturspezifikationen einzuteilen. Wir sollten prüfen, ob das eine viable Einteilung und Auflistung ist:
Elemente
(eine vollständige Auflistung der Elemente und auch der Elementspezifikationen findet man in der I7-Entwicklungsumgebung unter INDEX / KINDS. Ich habe versucht, die wichtigsten zusammenzufassen)
- Räumliche Struktur: room, region, door
- Zeug: thing, supporter, container, device, <other kinds>
- Kulisse: scenery, backdrop
- Akteure und Akteurzeug: person (man, woman, animal), player, player’s holdall, <actor>’s holdall
Elementspezifikationen
Räume
Spezifikation für Räume | ||||
Struktur | Beispiel | I7-Codebeispiel | ||
Property | Value | Inhalt | ||
identifier | in-code | my house | My house is a dark room.
| |
description | text | "Nice house with...." | ||
printed name | text | "AKAdemie" | ||
map region | region | Retz | ||
lighted/dark | either/or | dark | ||
<new property> windowcount |
<some value> number |
6 | ||
is <D> of <R> | <D>… Direction <R>… Room |
is north of grandmas house |
Türen
Spezifikation für Türen | ||||
Struktur | Beispiel | I7-Codebeispiel | ||
Property | Value | Inhalt | ||
identifier | in-code | golden door | The Cemetery and the Church
| |
description | text | "[if...]..." | ||
printed name | text | default: identifier | ||
open/closed | either/or | closed | ||
openable/unopenable | either/or | unopenable | ||
unlocked/locked | either/or | locked | ||
unlockable/lockable | either/or | lockable | ||
matching key | thing | jimmy | ||
<new property> | <some value> | |||
is <D> of <R> and <D> of <R> |
<D>… Direction <R>… Room |
is north of grandmas house |
Dinge
Spezifikation für Dinge | ||||
Struktur | Beispiel | I7-Codebeispiel | ||
Property | Value | Inhalt | ||
identifier | in-code | jimmy |
| |
kind | kind | thing | ||
description | text | "[if proper-named]…" | ||
printed name | text | rusty jimmy | ||
initial appearance |
text | "Oh… whats this? …" | ||
not wearable/ wearable |
either/or | default: not wearable | ||
singular-named/ plural-named |
either/or | singular-named | ||
proper-named/ improper-named |
either/or | proper-named | ||
edible/inedible | either/or | inedible | ||
initially carried | either/or | yes | ||
portable/fixed in place | either/or | portable | ||
pushable between rooms | either/or | yes | ||
unlit/lit | either/or | unlit | ||
scenery | Zuweisung | no | ||
located in <R> located in <C> located at |
<R>… Room <C>… Container |
located in player's holdall (weil initially carried) | ||
<new property> | <some value> |
Container
Spezifikation für Container | ||||
Struktur | Beispiel | I7-Codebeispiel | ||
Property | Value | Inhalt | ||
identifier | in-code | small coffin | The big coffin is a container in Cemetery.
| |
kind | kind | container | ||
description | text | "It is made of marzipann." | ||
printed name | text | default: identifier | ||
initial appearance | text | "Oh… whats this? …" | ||
not wearable/ wearable |
either/or | default: not wearable | ||
singular-named/ plural-named |
either/or | singular-named | ||
proper-named/ improper-named |
either/or | proper-named | ||
edible/inedible | either/or | edible | ||
initially carried | either/or | default: no | ||
portable/ fixed in place |
either/or | portable | ||
pushable between rooms |
either/or | no | ||
unlit/lit | either/or | unlit | ||
scenery | Zuweisung | no | ||
located in <R> located in <C> located at |
<R>… Room <C>… Container |
located in big coffin (located in Cemetery) | ||
carrying capacity | number | 1 | ||
<new property> | <some value> |
Strukturen
- Understandings
- Aktionen
- Gruppen von Aktionen
- Regeln
- Regelbücher für Aktionen (Check, Carry Out, Report)
- Aktions-bezogene Regeln (Instead of, After, Before, Persusation, Unsuccessful attempt)
- Zeitbezogene Regeln (Every Turn, Spielbeginn, Spielende, Szenenbeginn, Szenenende)
- Individuelle Regeln/Regelbücher
- Prozedurale Regeln
- Aktivitäts-bezogene Regeln (Before, For, After)
- Aktivitäten
- Szenen
- Relationen
- Phrasen (To, To-say,
Aktionen, Understandings, Regeln (und evt. Szenen) sind eng miteinander verknüpft.
Aktivitäten und Aktivitäts-bezogene Regeln sind eng miteinander verknüpft.
Szenen und Zeitbezogene Regeln sind eng miteinander verknüpft
Strukturspezifikationen
Understandings
Es ist zunächst wichtig, zwischen Aktionen und Spieler-Befehlen zu unterscheiden. Spieler-Befehle sind sprachliche Ausdrücke, die der Spieler eingibt. Die sprachlichen Ausdrücke (genannt: Topics) verursachen eine Aktion, sofern es ein Standard-Befehl ist oder eine passende Understand-Phrase im Code festgelegt wurde.
Man kann zwischen verschiedenen Arten von Understandings unterscheiden:
- Befehl: Spieler-Befehl, der eine Aktion verursacht
- Alias: Ausdruck, der synonym zu einem Objektnamen verwendet werden kann
- Mistake: Understandings, die nur eine Textmeldung verursachen und Vorrang gegenüber anderen Understandings haben ( vgl. hier )
Zusätzlich sollte man angeben, unter welchen Bedingungen ein sprachlicher Ausdruck auf bestimmte Weise verstanden werden soll. (z.B könnte kill the soldier
nur in der Szene „Gemetzel“ zur Aktion kill [a person]
führen).
Ich schlage vor, Understandings folgendermaßen zu spezifizieren (da man mit Understand auch noch andere Dinge machen kann, habe ich <Other> in der "Typ"- und "führt zu"-Zeile reingeschrieben. Wenn man nicht weiß, wie man den Zusammenhang in die Rahmenstruktur bringt, können Ausnahmefälle bei "zusätzliche Bemerkungen" beschrieben werden):
Spezifikation für Understandings | ||||
Struktur | Beispiel | Beispiel 2 | ||
Property | Value / Beschreibung | |||
Typ | (Befehl|Alias|Mistake|Other) | Befehl | Mistake | |
Topic | Ausdruck, den die Spielerin eingibt | "read [book]" | "read [book]" | |
führt zu | (Aktion|Objekt|Befehl|Text|Other) | Aktion: reading | Text "reading is too…" | |
Bedingungen | (Szene X läuft|Akteur im Raum R|…) Alles, was wahr oder falsch sein kann |
keine | Szene "blue-Monday-feeling" läuft | |
zusätzliche Bemerkungen |
Warum wird diese Verbindung hergestellt? | kann man auch mit einer Check-Rule machen, aber so geht’s auch. |
||
I7-Code | ||||
The degree is a kind of value.
|
Ein kleiner Hinweis: Man sollte das Standard-Befehlsset (Index/Actions/“Commands available to the player“) verwenden und nur dort, wo es semantisch notwendig ist, zusätzliche Befehle durch Understandings festlegen. Es ist kein Problem, wenn sowohl ein Standardbefehl als auch ein selbst erstellter Befehl auf eine Aktion gemapped werden. Schwierig für die Spieler wird es erst dann, wenn ausschließlich individuelle Befehle verwendet werden, die man im Kontext des Spiels und der vorhergehenden Beschreibungen schwer bis gar nicht erraten kann.
Aktionen
Um eine Aktion grob zu spezifizieren, sind folgende Angaben wichtig:
Spezifikation für Aktionen | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Aktionsname | <Verb> + ing | destroying | |
Objektbezug | (visible thing|thing|room|nothing|text|topic) Visible thing bedeutet, man braucht das Ding nicht angreifen, es reicht, wenn es sichtbar ist. |
thing | |
Licht? | (yes|no) default: no | yes | |
informelle Beschreibung |
Was wird durch die Aktion bewirkt und was sind die Bedingungen für das Ausführen der Aktion? Das ist sinnvoll, wenn man nur weiß, dass man die Aktion brauchen wird, aber die Regeln noch nicht explizit definiert werden (z.B. weil eine andere Arbeitsgruppe dafür verantwortlich ist oder weil man gerade keine Zeit dafür hat). |
Vorbedingung: Man kann nur Bücher lesen. Das Buch ist offen (wenn nicht - öffne es). Wirkung: Es wird der Inhalt der linken und rechten Seite des Buches angezeigt. Bericht: Einen Hinweis einbauen, dass man zum Weiterlesen umblättern muss (vgl. Aktion browse) |
|
I7-Code | |||
Reading is an action applying to one thing requiring light. |
Für jede Aktion werden explizit 3 Regelbücher erstellt (Prüfen,Durchführen,Berichten), die aber jeweils leer bleiben können, doch dazu später.
Gruppen von Aktionen
- Aktionsgruppen, auf die man später zum Beispiel in Regeln Bezug nehmen kann (vgl. hier) :
Spezifikation für Aktionsgruppen | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Name | Name der Gruppe | unjust action | |
Liste der Aktionen |
Aktion1 Aktion2 Aktion3 |
attacking drinking stealing |
|
Zweck der Verwendung |
Warum wird diese Gruppe definiert? Wofür könnte sie eingesetzt werden? |
Man kann damit alle ungerechten Handlungen klassifizieren und dann eine Regel erstellen, wodurch ungerechte Handlungen nur von ungerechten Personen durchgeführt werden können. |
|
I7-Code | |||
Attacking is unjust action. Drinking is unjust action. Stealing is unjust action. |
Aktivitäten
Spezifikation für Aktivitäten | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Name | Name der neuen Aktivität | Soultransferring | |
Objektbezug | (something|nothing) | something | |
Variablen | (können von den Regeln geändert/gelesen werden) Variablen anzugeben wird nur sinnvoll sein, wenn man schon relativ konkrete Vorstellungen hat, was die Aktivität bezwecken soll. <Value1> genannt <Name1> |
/ | |
informelle Beschreibung |
Was wird durch die Aktivität ausgeführt und was sind die Bedingungen für das Ausführen der Aktivität? Unter welchen Umständen wird die Aktivität aufgerufen? Diese Beschreibung ist sinnvoll, wenn man nur weiß, dass man die Aktivität brauchen wird, aber die Regeln noch nicht explizit definiert werden (mangels Zeit, fehlender Details oder anderer Verantwortungsbereich). |
Der Spieler wird aufgrund seiner im Spiel bekannt gegebenen Wahl in eine andere Person transferiert. Diese Aktivität triggert im Kontext des Spiels "Sein und Schein V2" das Ende der Szene "Carry on Nature", in der sogut wie alle üblichen I7-Befehle suspendiert sind. Das eigentliche interaktive Spiel beginnt erst danach. |
|
I7-Code | |||
Soultransferring something is an activity. |
Szenen
Spezifikation für Szenen | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Typ | (Wiederkehrend|Einmalig) | Einmalig | |
Name | Name der Szene | Call on Nature | |
Start- Bedingung |
Unter welchen Umständen beginnt die Szene? Alles, was wahr oder falsch sein kann (Wenn Szene S endet, Wenn Punktezahl >10,…) |
Wenn das Spiel beginnt | |
End- Bedingung |
Unter welchen Umständen endet die Szene? Alles, was wahr oder falsch sein kann (Wenn Szene S endet, Wenn Punktezahl >10,…) |
Wenn der Spieler nicht mehr im Himmel ist | |
Plot | Was passiert? Welche Rätsel/Aufgaben sind zu bewältigen? Welche Gegenstände zu holen? Sind besondere Regeln/Aktivitäten wichtig? |
* Der Spieler muss nur die gestellten Fragen beantworten * Das Standard I7-Verhalten ist suspendiert * Die Eingaben werden mit After reading a command-Regeln abgefangen |
|
Ausgang | Wie endet die Szene? Interessant, wenn man mehrere Ausgänge vorsieht und Daran "Zeitbasierte Regeln" (When Szene x ends happily…) anknüpft. |
/ | |
I7-Code | |||
A scene has a number called step.
|
Relationen
- Im Prinzip sind Relationen Eigenschaften, die einem Ding verglichen mit einem anderen Ding zukommen.
- Prädikatenlogische Interpretation: Eine Relation ist ein Prädikat, das ein Individuum näher bestimmmt.
- Graphentheoretische Interpretation: Relationen sind Kanten. Sie verbinden zwei Knoten miteinander.
- Technische Details gibt's hier
- "the stone, and the table, have no opinions, emotions, knowledge or memory. If the stone is taken away and then put back, nothing has changed. People, on the other hand, tend to remember having met each other before; they like being in some places, but not others; their behaviour depends on who, or what, is nearby. Being conscious, they have internal states, unlike the stone. Relations are a simple but powerful way to express and talk about such connections, and although they have numerous uses in physical contexts too, they are at their most powerful when helping to make the characters of interactive fiction come alive."
Spezifikation für Relationen | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Name | Name der Relation | Justice | |
Objekte | Welche Objektarten werden verbunden? Links: <thing|room|person|new kind> Rechts: <thing|room|person|new kind> ggf. Name der rechten Seite (Ehepartner, Haustier , Freundin, Bruder,…) |
Links: People Rechts: People |
|
Quantität | * 1-zu-1 Beziehung * 1-zu-Viele-Beziehung * Viele-zu-1-Beziehung * Viele-zu-Viele-Beziehung * Gruppen-Beziehung * Bedingung wann Relation zutrifft |
Bedingung: Wenn das Sein der Personen gleich ist |
|
Typ | (S|A) S… Symmetrisch (nur: 1-zu-1, Viele-zu-Viele) A… Asymmetrisch S: Relation geht in beide Richtungen A: geht nur in eine Richtung (default) |
S | |
Verben | to / to be <Verb> (normal oder invers) ( wenns schräge Verben sind, dann mit Beugung . Es kann sinnvoll sein, mehrere Verben anzugeben, die diese Relation implizieren. Wenn das Verb von rechts nach links verstanden werden soll, "invers" angeben) |
to resemble to equal |
|
Bemerkungen | Ideen, wo man die Relation einsetzen kann; andere Implementierungsdetails etc. |
/ | |
I7-Code | |||
Justice relates people (called x) to another
|
Regeln
Wenn man sich Regeln überlegt, sollte man ein bisschen ein Verständnis über die technischen Hintergründe haben, die hier und hier zu finden sind.
Regelbücher für Aktionen
Es gibt folgende Typen von Regeln, die auf eine bestimmte Aktion Bezug nehmen (die Liste ist nach der Reihenfolge, nach der die Regeln geprüft werden, geordnet):
- BEFORE: Hier kann man gut Ergänzungen für Standard-Regeln unterbringen
- Persuasion (nur für NPCs wichtig): Die Regel gibt Antwort auf die Frage, ob ein NPC der Aufforderung, etwas zu tun, nachkommen soll.
- INSTEAD OF: Mit dieser Regel kann man üblicherweise Regeln von Standard-Aktionen/Aktionsgruppen blockieren. Das heißt, nach einer Instead-Of-Regel wird standardmäßig mit „STOP THE ACTION“ abeschlossen.
- CHECK: Regelbuch, indem geprüft wird, ob für die Aktion nötige Vorbedingungen erfüllt sind. Falls nicht, wird abgebrochen.
- Unsuccessful Attempt By (nur für NPCs wichtig): Ein NPC würde gern der Aufforderung nachkommen, kann aber nicht, weil es CHECK- oder INSTEAD-OF-Regeln der Welt nicht erlauben
- CARRY OUT: Die Regeln dieses Regelbuchs führen die Aktion aus, d.h. verändern bestimmte Zustände der Welt, der Spielfigur, etc. Hier sollte wenn möglich kein Text ausgegeben werden.
- AFTER: Solche Regeln sind nützlich für Szenen-Wechsel (wenn eine solche Regel existiert, wird die Report-Regel üblicherweise unterdrückt).
- REPORT: Hier soll Text ausgegeben werden, der dokumentiert, was in CARRY OUT passiert ist.
Zur Spezifikation dieser Regelarten schlage ich folgenden Rahmen vor:
Spezifikation für nur-Aktions-bezogene Regeln | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Typ | ( Before | Persusasion | Instead of | Check | Unsuccessful Attempt | Carry out | After | Report ) |
Instead of | |
Name | Name der Regel (wenn gewünscht) | / | |
Reihenfolge | (nur, wenn gewünscht; Bezugspunkt ist immer das durch den Typ festgelegte Regelbuch) ganz am <Anfang|Ende> <vor|nach|statt> Regel <R> |
/ | |
Betroffene Aktion oder Aktionsgruppe |
<Aktion|Aktionsgruppe> | Aktionsgruppe: unjust action | |
Akteur | (alle|nur NPC|nur Spieler) | alle | |
Bedingungen | Alles, was wahr oder falsch sein kann | wenn das Sein des Spielers gerecht ist |
|
informelle Beschreibung |
* Was wird durch die Regel getan? * Was ist durch sie erlaubt/verboten? * Was wird durch sie verändert? * Welche Aktivitäten führt sie ungefähr aus? (evt. I7-Codestücke zur Verdeutlichung) |
* say "I cannot do this because of my moralic behaviour" * erhöhe den Zähler der un- gerechten Taten um 1. * vermindere die Punktezahl um 10 |
|
Ergebnisse (Outcome) |
Bedingungen angeben für: <Erfolg|Misserfolg|benanntes Ergebnis> der Regel --> Regelbuch wird nicht weiter verarbeitet Ergebnis unentschieden --> nächste Regel im Regelbuch Geplante Verwendung von Ergebnissen (in Aktionen, anderen Regeln, …) |
unter allen Bedingungen: Regelstatus unentschieden |
|
Benannte Ergebnisse |
<Ausdruck1> bedeutet <Erfolg|Misserfolg|Unentschieden> |
keine | |
I7-Code | |||
Instead of unjust action when the being of the player is just:
|
Zeitbasierte Regeln
Spezifikation für Zeitbasierte Regeln | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Typ | When play begins, When play ends, When scene S begins, When scene S ends, Every turn |
When scene begins scene: blue-Monday-feeling |
|
Name | Name der Regel (wenn gewünscht) | / | |
Reihenfolge | (nur, wenn gewünscht; Bezugspunkt ist immer das durch den Typ festgelegte Regelbuch) ganz am <Anfang|Ende> <vor|nach|statt> Regel <R> |
/ | |
Bedingungen | Alles, was wahr oder falsch sein kann | wenn Spieler im Haus ist | |
informelle Beschreibung |
Was wird durch die Regel getan? Was ist durch sie erlaubt/verboten? Was wird durch sie verändert? Welche Aktivitäten führt sie ungefähr aus? (evt. I7-Codestücke zur Verdeutlichung) |
* say "I feel so slumberous" | |
Ergebnisse (Outcome) |
Bedingungen angeben für: * <Erfolg|Misserfolg|benanntes Ergebnis> * Ergebnis unentschieden Geplante Verwendung von Ergebnissen (in Aktionen, anderen Regeln, …) |
unter allen Bedingungen: Regelstatus unentschieden |
|
Benannte Ergebnisse |
<Ausdruck1> bedeutet <Erfolg|Misserfolg|Unentschieden> |
keine | |
I7-Code | |||
When the blue-monday-feeling begins
|
Prozedurale Regeln
- Diese Spezifikation verwendet man, wenn man bestehende oder bereits definierte Regeln unter bestimmten Umständen nicht oder schon oder anders verwenden möchte (dazu vgl. hier )
- Gibt es keine speziellen Umstände, braucht man auch keine Prozedurale Regel
- Prozedurale Regeln kann man als Metaregeln ansehen, die dazu führen, dass unter bestimmten Bedingungen (z.B. in einer bestimmten Szene) bestimmte Regeln (z.B. die Regel, dass die Zeit vergeht) anders als normalerweise anwenden (unterdrücken oder mit einer anderen Regel ersetzen)
Spezifikation für Prozedurale Regeln | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Aktion | * Regel <R> ignorieren * <R> durch <R2> ersetzen * ignorierte <R> wiederherstellen * Ergebnis von <R> unterdrücken * ignoriertes Ergebnis von <R> wiederherstellen * verschiebe <R> (vor|nach> <R2> |
Die "Turn Sequence Rules" ignorieren |
|
Bedingungen | Alles, was wahr oder falsch sein kann | wenn eine Aktion der Aktionsgruppe "acting fast" ausgeführt wird |
|
Bemerkungen | Warum braucht man diese Prozedurale Regel? Was will man damit für ein Verhalten erzielen? |
Alle Aktionen, die man in dieser Aktiongruppe definiert, performen schneller, weil ein Haufen von komplexen und oft auftretenden Regeln ignoriert werden. |
|
I7-Code | |||
Procedural rule when acting fast: ignore the turn sequence rules. |
Regeln für Aktivitäten
Spezifikation für Aktivitäts-bezogene Regeln (Object-parametrized rulebooks) | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Typ | (Before |For | After) | For | |
Name | Name der Regel (wenn gewünscht) | the soul transfer rule | |
Reihenfolge | (nur, wenn gewünscht; Bezugspunkt ist immer das durch den Typ festgelegte Regelbuch) ganz am <Anfang|Ende> <vor|nach|statt> Regel <R> |
/ | |
Betroffene Aktivität | <Aktivität> | Soultransferring <someone> | |
Bedingungen | wenn <andere Aktivität> (nicht) läuft | / | |
Beschreibung | Was wird durch die Regel getan? Was ist durch sie erlaubt/verboten? Was wird durch sie verändert? Welche Aktivitäten führt sie ungefähr aus? (evt. I7-Codestücke zur Verdeutlichung) |
* Glückwunsch-Text zum neuen Körper * Befehlsprompt auf Standard ändern * Spielerin auf "target"-Person ändern |
|
I7-Code | |||
Rule for Soultransferring someone (called the target)
|
Individuelle Regeln / Regelbücher
Phrasen
Spezifikation für Hilfsfunktionen / neue Adjektive | |||
Struktur | Beispiel | ||
Property | Value / Beschreibung | ||
Typ | * A: Hilfsfunktion ohne Rückgabewert * B: Hilfsfunktion mit ja|nein-Rückgabewert (wann trifft Adjektiv zu?) * C: Hilfsfunktion mit Rückgabe <thing|room|…> * D: Hilfsfunktion für Verwendung in Textausgaben |
4 Beispiele: * A * B * C (Rückgabe "number") * D |
|
Parameter/ Argument |
Bezeichnung - Typ | * A: whatever - a book * B: / * C: bookvar - a book * D: / |
|
Funktionsname | * B: Adjektivname * A,C,D: Funktionsname (+ optionale Teile) |
* A: pageswitch <whatever> * B: the turn count is even * C: maximum page of <bookvar> * D: muse |
|
Informelle Beschreibung |
A,C,D: Was tut die Hilfsfunktion? B: Wie entscheidet die Funktion, ob das Adjektiv zutrifft? |
* A: Wechselt auf die nächste Seite * B: Ist Bewegungsanzahl gerade? * C: Seitenzahl bestimmen * D: Abkürzung für Tastendruck und Zeilenumbruch |
|
I7-Code | |||
|
Der source
-Tag hat bei diesem Code-Stück irgendwie nicht funktioniert... :|
- ja, das Syntax-Highlighting hat leider noch seine Macken. Wenn wie im Sample A eckige Klammern innerhalb eckiger Klammern auftauchen, schafft das leider Unruhe. Wenn sich da einer der Herren Informatiker berufen fühlt, die inform.php zu verbessern, würde mich das sehr freuen... --Thai 13:03, 19. Mär. 2009 (UTC)
- Lag an meinem Sourcecode, da war ein
[
zuviel.--Andyk 00:41, 25. Mär. 2009 (UTC)
- Lag an meinem Sourcecode, da war ein