Hi Zusammen, falls hier überhaupt noch jemand ist (sonderlich viel scheint in diesem Forum ja nicht los zu sein )

Ich wollte seit langem wieder mal einen Versuch wagen, ein eigenes Textadventure zu basteln. Mein erster Versuch, damals mit T.A.G., endete in einem Festplattencrash und Datentotalverlust, was mir erst mal für Jahre die Lust nahm..

Nun jedoch scheint TAG nach Martin Oehm selbst recht veraltet zu sein, deshalb (und auch wegen der Portabilität) will ich Inform nehmen. Nun jedoch stellt sich mir die Frage, die auch im Threadtitel zu sehen ist.

Von den mannigfaltig existierenden werde ich wohl Deform oder die "offizielle" nehmen, aber kann mir jemand einen Tipp geben, welche für einen Anfänger besser wäre?

Für die "offizielle" wird wohl bei Problemen mehr im Netz zu finden sein als bei Deform, jedoch widerstrebt mir das benutzen einer angepassten Inform-Version, die, anders als die normale, nicht im Repository ist, und Deform scheint ja mit der normalen zu funktionieren (selbst nach Nachschlagen der seltsamen Commandlineoptionen und korrigieren der Gross/Kleinschreibfehler der Include-Dateinamen konnte ich mit dem normalen Inform die "offizielle" Lib nicht benutzen). Das sind aber nur Ersteindrücke...

EDIT: i7 wäre übrigens nichts für mich. Als Programmierer ist ein sprachähnlicher Code für mich wohl schwieriger als ein echter

Klaue:

Von den mannigfaltig existierenden werde ich wohl Deform oder die "offizielle" nehmen, aber kann mir jemand einen Tipp geben, welche für einen Anfänger besser wäre?

Hallo erst einmal :-)

Ich würde dir zu Deform raten - diese Library ist in den meisten Fällen besser als die "offizielle" und besitzt eine meiner Meinung nach fortschrittlichere Codebasis. Vermutlich kannst du das Jumpstart-Kit benutzen, indem du die "offizielle" Lib mit den Dateien von Deform überschreibst.

Viel Erfolg,

Max.

Hallo Klaue!

deform basiert auf der letzten I6-Library 6/11 und ist die aktuellste Lösung. Außerdem gibt es ein paar neue Features, die das Schreiben erleichtern, z.B. die Verwendung von flexiblen Endungen per Low-Strings, eine verbesserte Disambiguisierung und noch ein paar schöne Dinge.

Ich habe bei der Entwicklung von zwei Spielen (eines davon im Rahmen eines komerziellen Adventure-Projekts) sehr gute Erfahrungen mit deform gemacht und kann das nur empfehlen.

Hilfe bekommst Du hier im Forum recht zügig, das hat die Erfahrung gezeigt; auch wenn hier nicht die Hölle los ist, lesen doch einige regelmäßig mit.

Viel Spaß und Erfolg beim Einstieg und schöne Grüße,

Christian

Na, dann nehm' ich wohl Deform

Danke für die Antworten!

Ich frage mich nur gerade.. Warum macht man Deform dann nicht zur Ofiziellen? Oder, da ich in einem anderen Thread hier gelesen hab', dass Martin Oehm das nicht möchte, währe wenigstenseine Umbenennung der ofiziellen in etwas, das nicht "ofiziell" enthält, anzuraten..

Nunja, das sage ich natürlich nur als blutiges Greenhorn, ich finde es nur etwas seltsam, wenn sich die anscheinend schlechtere Lib selbst zur ofiziellen kürt.

Dann werde ich mir mal eine Story überlegen gehen - die, die ich beim ersten Versuch erwendete, scheint mir nun doch etwas sehr banal (Es ging drum, dass man selbst ein Koffeinsüchtiger eingesperrt im Haus eines Freundes ist und man die geheime Kaffeekammer finden muss)

Ich bin etwas irritiert, nutze ich mit I7/GerX nun eine minderwertige Sprachextension?

proc:

Ich bin etwas irritiert, nutze ich mit I7/GerX nun eine minderwertige Sprachextension?

Ich denke mal, mkalus/ChristianB meinten pre-i7, da ich im OP schon schrieb, dass ich i7 nicht benutzen will

Puuh, dachte schon die Quelltexte büffeln zu müssen.

OT: Zwischen I7 und I6 kann ich strukturell keine Unterschiede erkennen außer dem gut gemeinten Versuch einer literate programming-Schnittstelle als eine Art Intelligenztest für Programmierer. Daher gleich die nächste Frage: Was spricht gegen I7 außer der fehlenden C++ -Erotik und dem ohnehin verwendeten I6.31-Compiler? Gibt es Unterschiede, die über ästhetische Belange hinausgehen?

proc:

Ich bin etwas irritiert, nutze ich mit I7/GerX nun eine minderwertige Sprachextension?

Inform 7 ist Inform 6 im Ballkleid. GerX ist für I7 also so eine Art trägerloser BH, der aus dem deform-Push-up geschneidert wurde. Es wurden nur Kleinigkeiten geändert.

proc:

Zwischen I7 und I6 kann ich strukturell keine Unterschiede erkennen außer dem gut gemeinten Versuch einer literate programming-Schnittstelle als eine Art Intelligenztest für Programmierer.

Vordergründig verhalten sich Spiele, die mit deform geschrieben wurden, so wie GerX-Spiele. Der von I7 erzeugte I6-Code ist jedoch um einiges größer und braucht mehr Ressourcen zur Laufzeit. Es gibt also schon strukturelle Unterschiede.

Wer auf schlanke, eher konventionelle Programmierung steht, ist bei I6 besser aufgehoben.

proc:

Was spricht gegen I7 außer der fehlenden C++ -Erotik und dem ohnehin verwendeten I6.31-Compiler? Gibt es Unterschiede, die über ästhetische Belange hinausgehen?

Gegen I7 spricht nichts, außer dass es nicht ganz leicht zu erlernen ist, wenn man richtig tricksen will. Wenn man sich aber erst an das neue Konzept gewöhnt hat und die umfangreiche Syntax einigermaßen drauf hat, lassen sich Sachen teilweise extrem elegant lösen. Wie gesagt, mit hohem Aufwand auf dem I6-Level.

Egal, ob man Inform 6 oder 7 benutzt, am Ende kommt ein Spiel raus. Und die Qualität des Spiels hängt nicht von dem einen oder anderen System ab.

ChristianB:

GerX ist für I7 also so eine Art trägerloser BH, der aus dem deform-Push-up geschneidert wurde.

vielen Dank für die beruhigende Antwort, hoffentlich kann da nix rutschen. Darf ich noch die indiskrete Doppelfrage stellen, welche Vision hinter dem Versionssprung auf 2 und welcher Kopf hinter Banbury steckt? -- Gruss Martin

Inform 7 befindet sich noch in der öffentlichen Beta-Phase. Es wird also noch kräftig weiterentwickelt und mit jeder neuen Version können sich viele Sachen ändern, die auch die deutsche Lib betreffen. Fehler in GerX Version 1 habe ich in einer gesonderten Patch-Extension "German Patches.i7x" korrigiert, das wurde aber immer sperriger, je mehr Fehler gefunden wurden. Deshalb habe ich eine Vorabversion 2 erstellt, in der alle bekannten Fehler korrigiert sind. Außerdem habe ich versucht, die Parser-Nachfragen, die mitunter seltsam waren, zu verbessern und die Dokumentation überarbeitet. Veröffentlicht habe ich das Ganze, damit jeder, der mag, sich an der Suche nach weiteren Fehlern beteiligen kann, oder Verbesserungsvorschläge gemacht werden können.

Der eigentliche Versionssprung wird erst noch erfolgen, und die Vision wird weiterhin sein, dass man die deutsche Erweiterung so effektiv und flexibel wie möglich zum Schreiben von deutschsprachigen Textadventures benutzen kann.

Was demnächst zu tun sein wird, kann man ungefähr erahnen, wenn man einen Blick auf das Entwicklungspapier vom April 2009 wirft. Wie viel Arbeit das nach sich ziehen wird und was sich für uns genau ändert ... wer weiß das schon.

Sehr wahrscheinlich steht eine neue I7-Version unmittelbar bevor. Um dann nicht noch Zeit mit alten Fehlern zu verplempern zu müssen, gibt's die Testversion der GerX-Version 2.

Tja, wer ist Banbury? Es gibt ihn (oder sie), aber ich weiß nicht, wer sich hinter dem Namen verbirgt. Banbury hat das Projekt mit großem Elan begonnen und alles ins Rollen gebracht, war dann aber bald mit anderen Projekten beschäftigt, sodass ich die deutsche Erweiterung bis jetzt allein weiter betreue.

Vielen Dank für die aufschlussreiche Antwort, das 2009-Paper hatte ich bislang nur unter dem Aspekt wahrgenommen, dass das "hacky business" (Short) der Handhabung "nichtenglischer Sprachen" ersatzlos gestrichen wurde. Die russische IF-Szene klagt zudem über UTF-Probleme, die im Deutschen glücklicherweise noch überschaubar bleiben. Das liegt wohl an der Abschottung der Inform-Entwicklung und manchmal finde ich es schade, dass T.A.G. nicht weiterentwickelt werden konnte. Die Russen haben heute mehrere Systeme zur Auswahl, ich würde so gerne mal das eine oder andere ausprobieren, kann aber nicht mal den README-Text entziffern...

Sagt mal.. Bin ich der einzige, der von der inform-Sprache in den Irrwitz getrieben wird?

Ich meine, dass man Hex-Werte anstatt mit 0x-Prefix mit einem $-Prefix versieht, geht ja noch.

Dass 'a' ein char ist, aber 'aa' ein Bezeichner für das Dictionary ist schon hässlich.

Dass es ausser int (und "int im Tarnkleid") keine Datentypen gibt und sachen wie long, double etc fehlen ist bedenklich, aber für Adventures reicht das wohl.

Das Schlimmste fand ich aber die Variablen. Erstmal ist man eingezwängt auf nur 15, was bei fehlenden Array-Typen schon recht wenig ist, dann muss man sie zu Beginn definieren anstatt da wo man sie braucht (und hat dadurch keine Möglichkeit, Variablen innerhalb eines Loops (falls es die überhaupt gibt, soweit bin ich noch nicht) oder so zu definieren), typesafety gibt es keine...

Aber dann dass die Funktionsparameter nicht extra definiert sind, sondern schlicht die normalen Variablen genommen werden.. Da war ich nicht sicher, ob ich weinen oder schreien sollte

Also... Ist es normal, dass man sowas durchmacht, wenn man neu mit Inform Anfängt, oder bin ich einfach zu pingelig?

EDIT: Oh mann..

In strings, newlines sind ^ statt \n und Anführungszeichen sind ~ statt \"

Will man diese Sonderzeichen als normales Zeichen im string haben, muss man es mit zwei @ und dem ASCII-Wert escapen.. ^ = @@94

haare rauf was ist so schlimm an einem einzigen bestimmten Escape-Zeichen?

(Ja, ich musste schnell Dampf ablassen und bin mir nicht mehr so sicher, ob ich wirklich ein Adventure mit dieser Sprache schreiben will...)

EDIT2:

Um diesem Mecker-Post noch was brauchbares zu geben: Wie kann ich Umlaute benutzen? Laut DM4 sollte ich die direkt in die Source schreiben können, nach man-page von inform ist Latin-1 Standard, was AFAIR Umlaute enthält, aber bei einem Test geht's trotzdem nicht:

   print "ä";

];```

klaue@klaue-desktop:~/Desktop/Text Adventures$ inform hellö.inf

Inform 6.31 for Linux (10th Feb 2006)

line 2: Error:  Character can only be used if declared in advance as part of 'Zcharacter table': (ISO Latin1) $a4, i.e., '�'

>  print "ä"

Compiled with 1 error (no output)

Überall immer extra @:a oder @ae statt ä zu nehmen scheint mir doch sehr Umständlich

noch ein EDIT: Mein Source war als UTF-8 gespeichert, nach ändern auf Latin-1 klappte es, wie es sollte

Ich finde die Vision hinter Inform7 genauso gewagt wie wichtig: Es steckt schlichtweg die Idee dahinter, IF den (angelsächsischen) Nicht-Programmierern zugänglich zu machen. Dass der Schuss vordergründig nach hinten losgegangen ist, wie man beispielsweise aus den seit 2002 stagnierenden Teilnehmerzahlen der IF-Wettbewerbe herauslesen könnte, hat meines Erachtens drei Gründe: das syntaktische Konzept der natürlichen Programmiersprache unterscheidet sich praktisch nicht vom Vorgänger, der Motor des Zugpferds ist immer noch I6 und die kreative Tendenz geht hin zur Gruppenarbeit, in der die Autorenarbeiten und die Implementierungsaufgaben aufgeteilt werden. Für andere Sprachen als Englisch kommt freilich die starre Ausrichtung auf eine angelsächsische Befehlssprache und Grammatik hinzu, ich selbst würde am Rande noch die marginalen Möglichkeiten in puncto Multimedia-Elementen und Ausgabe-Styles, Ereignissen und die fehlende Offenheit des Compilers für externe Software bemängeln, meines Wissens liegt der Quellcode des ni bis heute nicht offen. Unterm Strich bewundere und befürworte ich die Arbeit an I7 vor allem deshalb, weil die Einstiegsbarriere gefallen ist und dennoch alle Features von I6 zugänglich sind. Umgekehrt steht es Autoren ohne inhaltliche Einbußen frei, I6 zu benutzen.

Zitat:

Sagt mal.. Bin ich der einzige, der von der inform-Sprache in den Irrwitz getrieben wird?

Nö, alles schon dagewesen... :-)

Zitat:

Dass 'a' ein char ist, aber 'aa' ein Bezeichner für das Dictionary ist schon hässlich.

Richtig hässlich ist, dass Einträge ins Wörterbuch, die aus nur einem Buchstaben bestehen, mit zwei nachgestellten Schrägstrichen kennzeichen muss: 'a//'. (Und das ist schon die schöne Variante, früher hieß das mal #n$a.)

Zitat:

Dass es ausser int (und "int im Tarnkleid") keine Datentypen gibt und sachen wie long, double etc fehlen ist bedenklich, aber für Adventures reicht das wohl.

Diese Beschränkung ist wohl weniger der Sprache als eher der Zielplattform z-Code geschuldet. Dort gibt es halt nur Bytes und Wörter und die maximale Anzahl der lokalen Variablen ist 15, die maximale Anzahl der Argumente 7.

Nach long und float wird an und ab schon einmal gefragt, aber so richtig braucht man das wohl nicht. Es gibt aber Extensions, die große Integer und IEEE-Floats implementieren.

Man muss halt beim Programmieren darauf achten, was eine Variable für Werte annehmen kann. Inform bietet ja immerhin die Möglichkeit, zwischen Routinen, Objekten und Strings zu unterscheiden. (Es wäre schön, wenn dieser Mechanismus auch auf Felder und Wörterbucheinräge erweiterbar wäre, aber Inform schaut sich nur an, ob ein Wert ein Objekt usw. sein könnte, also zum Beispiel im Bereich der gültigen Objekte liegt, und da ist bei der z-Maschine zumindest die Unterscheidung zwischen Strings und Feldern zum Beispiel nicht möglich.)

Die laxe Typisierung ist schon nützlich, besonders bei den Objekteigenschaften: Ist es ein String? Okay, dann gib's aus. Ist es eine Routine? Okay, ruf es auf. Man muss nur aufpassen, welche möglichen Typen eine Eigenschaft haben kann.

(Manchmal fällt man dabei auf die Nase: Ein String in Anführungszeichen ist eben nicht dasselbe wie ein Byte-Array. Und eine Eigenschaft, die drei Werte hat ist nicht dasselbe wie eine Eigenschaft, die als Wert eine Feldreferenz hat.)

Der Stack kann nur beschränkt (nämlich mit maximal 15 Variablen je Funktrionsaufruf) wachsen, und man kann keinen Speicher allokieren. Daher gibt es keine lokalen Felder. Man kann sich natürlich einen genügend großen Puffer freihalten und sich einen eigenen Stack programmieren. Man muss dann aber immer schön hinter sich aufräumen. Wer's ganz wild treiben will, kann sich ja mal die Garbage Collection aus Andrew Plotkins Lisp-Interpreter aus Lists and Lists ansehen.

Strukturen gibt es auch nicht; man muss sie faken oder Objekte verwenden.

Zitat:

Aber dann dass die Funktionsparameter nicht extra definiert sind, sondern schlicht die normalen Variablen genommen werden.. Da war ich nicht sicher, ob ich weinen oder schreien sollte

Ja, die Syntax der Funktionen ist schon sehr gewöhnungsbedürftig. Eckige Klammern als Begrenzer (wobei der Funktionsname bei Methoden außerhalb der Klammern, bei normalen Routinen innerhalb steht) gefallen mir auch nicht. Und dass alle lokalen Variablen auf einen Haufen in einer nicht durch Kommas getrennten Liste angegeben werden, ist auch hässlich. Variablendefinitionen innerhalb von Schleifen gibt es nicht.

Aber man kann sich dran gewöhnen und dann zwischen den Parametern der Funktion und den lokalen Variablen einen größeren Zwischenraum oder einen Umbruch setzen:

[ Funktion a b c    ! Argumente

    i j k;          ! lokale Variablen

];

Zitat:

Also... Ist es normal, dass man sowas durchmacht, wenn man neu mit Inform Anfängt, oder bin ich einfach zu pingelig?

Du bist zu sehr an die C/Java-Syntax gewöhnt. Und dabei hast du noch nichts gesagt über Doppelpunkte zum Abtrennen der Elemente einer for-Schleife, über die -> und --> zum Zugriff auf Bytes und Wörter in einem Feld, über die Syntax der Ausgaberegeln (printing rules), die wie ein Typecast aussehen, darüber dass alleinstehende Funktionen per Default true, Methoden per Default false zurückgeben und darüber, dass ein alleinstehender String diesen ausgibt und stillschweigend mit dem Rückgabewert true die Routine verlässt. Oh, und die sehr eigenwillige Verwendung von Kommas und Strichpunkten nicht zu vergessen.

Zitat:

Will man diese Sonderzeichen als normales Zeichen im string haben, muss man es mit zwei @ und dem ASCII-Wert escapen.. ^ = @@94

Tja, und selbst das funktioniert nicht, wenn zum Beispiel nach dem @-Zeichen eine Ziffer folgt. Deswegen schreibt man am besten direkt @{5e}.

Zitat:

(Ja, ich musste schnell Dampf ablassen und bin mir nicht mehr so sicher, ob ich wirklich ein Adventure mit dieser Sprache schreiben will...)

Der Z-Code als Zielplattform ist schon gut, weil es so viele Interpreter gibt, jetzt ja sogar mit Parchment einen web-basierten.

Mit Inform als Sprache kann man auch zurecht kommen. Wenn man mit Inform programmiert, hilft es, die darunterliegende Architektur, also die z-Maschine etwas zu kennen. Insofern ist es schon sehr ähnlich zu C. Aber über die Syntax, die fast, aber nicht ganz C ist, stolpere ich auch andauernd.

Und mit der Standard-Inform-Bibliothek, die ja auch hinter deform steckt, habe ich manchmal so meine Probleme.

Zitat:

noch ein EDIT: Mein Source war als UTF-8 gespeichert, nach ändern auf Latin-1 klappte es, wie es sollte

Ja, mit UTF-8 kann Inform nichts anfangen, man muss die ISO-8859-Zeichensätze verwenden. Alles, was außerhalb von Anführungszeichen steht, muss auch 7-Bit-ASCII sein.

Martin:

Zitat:

Sagt mal.. Bin ich der einzige, der von der inform-Sprache in den Irrwitz getrieben wird?

Nö, alles schon dagewesen... :-)

Gut, das gibt mir ein klein wenig Selbstvertrauen zurück

Zitat:

Richtig hässlich ist, dass Einträge ins Wörterbuch, die aus nur einem Buchstaben bestehen, mit zwei nachgestellten Schrägstrichen kennzeichen muss: 'a//'. (Und das ist schon die schöne Variante, früher hieß das mal #n$a.)

Ja, das fühlte sich sehr nach halbherzigem Workaround an, nicht wirklich nach einer Lösung

Zitat:

Du bist zu sehr an die C/Java-Syntax gewöhnt. Und dabei hast du noch nichts gesagt über Doppelpunkte zum Abtrennen der Elemente einer for-Schleife, über die -> und --> zum Zugriff auf Bytes und Wörter in einem Feld, über die Syntax der Ausgaberegeln (printing rules), die wie ein Typecast aussehen, darüber dass alleinstehende Funktionen per Default true, Methoden per Default false zurückgeben und darüber, dass ein alleinstehender String diesen ausgibt und stillschweigend mit dem Rückgabewert true die Routine verlässt. Oh, und die sehr eigenwillige Verwendung von Kommas und Strichpunkten nicht zu vergessen.

Och, diverses davon ist mir auch schon negativ aufgefallen, aber nach gefühlten 300 Edits des Posts wollte ich ihn mal stehen lassen

Zitat:

Der Z-Code als Zielplattform ist schon gut, weil es so viele Interpreter gibt, jetzt ja sogar mit Parchment einen web-basierten.

A pro pos und hier Offtopic: Auf deiner Webseite hast du ja diverse Interpreter aufgelistet. Die erwähnten Linux-Versionen (und alle, die ich per Google finden konnte, vom Frotz-Port bis hin zu jzip) wollten bei mir aber allesamt keine Umlaute unterstützen - Das bei dir unter Windows gelistete Gargoyle hat jedoch auch eine Linux-Version (sogar ein deb-Package) und klappt Problemlos

Wegen web-basierten: Bei meiner Suche fand ich unter anderem "ZPlet", das auf Java basiert und mit Umlauten umgehen kann, aber nur als Applet vorhanden ist (wofür es für mich wegfiel). Soweit ich das sehen kann, gibt's das schon eine ganze weile, was ist an Parchment denn so besonders?

Zitat:

Ja, mit UTF-8 kann Inform nichts anfangen, man muss die ISO-8859-Zeichensätze verwenden. Alles, was außerhalb von Anführungszeichen steht, muss auch 7-Bit-ASCII sein.

Schade nur, dass einem das weder in der Fehlermeldung noch bei Google-Suche danach gesagt wird

Danke für die ausführliche Antwort!

Ich fühle mich übrigens geehrt, dass Du mir antwortest. TAG war damals[TM] wohl die erste Programmiersprache, mit der ich mich ausführlicher beschäftigte (Davor nur etwas halbherziger QBasic/BlitzBasic), deshalb ist das ein klein wenig so, als würde einem Bjarne Stroustrup oder so antworten

EDIT:

Dutiful apostles of object-oriented programming [...] may want to call Inform a ‘‘weakly-typed language with multiple-inheritance’’, or more probably a ‘‘shambles’’.

Wie recht das Manual da doch hat

EDIT:

OK, noch was.. Ich bin nun zum ersten Excerzise im DM4 gelangt. Dort hat man einen Pilz und es wird von einem Verlangt, nach nochmaligem aufnehmen eine andere Nachricht zu geben wie beim ersten (da man ihn nur einmal pflücken kann).

Meine Lösung sah so aus (entschuldigt das Sprachgemisch):

Object -> mushroom "speckled mushroom"

[...]

      after [;

         Take: if (self hasnt dropped) "You pick the mushroom, neatly cleaving its thin stalk.";

            "Du nimmst ihn wieder auf";

         Drop: give self dropped;

            "The mushroom drops to the ground, battered slightly.";

      ],

      has edible, has ~dropped;```

Die Musterlösung hingegen nahm ein property statt einem Attribut:

```[...]

mushroom_picked,

after [;

    Take: if (self.mushroom_picked)

             "You pick up the slowly-disintegrating mushroom.";

          self.mushroom_picked = true;

          "You pick the mushroom, neatly cleaving its thin stalk.";

    Drop: "The mushroom drops to the ground, battered slightly.";

],

[...]```

Welche Lösung ist da im Normalfall vorzuziehen?

Soweit ich das bisher verstanden habe, sind Attribute flags, also Boolean-Werte, und darum doch in einem solchen Falle vorzuziehen, oder nicht?

Zitat:

... deshalb ist das ein klein wenig so, als würde einem Bjarne Stroustrup oder so antworten

Na, das sind ja Vergleiche!

(Darüber, ob die Syntax von TAG oder von C++ hässlicher ist, wollen wir uns aber jetzt nicht streiten, oder?)

Zitat:

Welche Lösung ist da im Normalfall vorzuziehen?

Soweit ich das bisher verstanden habe, sind Attribute flags, also Boolean-Werte, und darum doch in einem solchen Falle vorzuziehen, oder nicht?

Du hast recht, die Lösung verlangt einen Wahrheitswert und ein Attribut ist genau das. Trotzdem ist die Musterlösung aus dem DM4 die bessere, zumindest in diesem Fall.

Attribute sind Flaggen für Objekte. Jedes Objekt kann ein Attribut haben, ohne dass es explizit beim Objekt definiert werden muss. Allerdings ist die Anzahl der Attribute auf 48 beschränkt.

(Attribute sind ein Mechanismus der z-Maschine: Jedes Objekt hat in seinem Kopf ein Feld mit 48 Bits, die beliebig gesetzt und gelöscht werdenkönnen. Das sind die Attribute.)

Properties müssen in einem Objekt definiert werden, damit man sie später verwenden kann und stehen natürlich dann auch nur bei diesen Objekten zur Verfügung. Ob ein Objekt eine Property bereitstellt, kann man mit provides prüfen. Auf eine Property in einem Objekt zuzugreifen, wenn es diese Property nicht hat, ist ein Fehler. Wenn man also bei einem Objekt irgendwann einmal eine Property benötigt, muss man einen Dummy-Wert definieren. Der Vorteil von Properties ist, dass sie unbegrenzt zur Verfügung stehen.

Da das Pflücken des Pilzes nur für den Pilz interessant ist, sollte man hier eine Property beim Pilz definieren, damit keins der 48 Attribute "verschwendet" wird.

Die Lib unterscheidet allerdings bereits, ob ein Gegenstand bereits aufgehoben (oder "bewegt") wurde und belegt alle Objekte, bei denen ein ##Take erfolgreich war und alle Objekte, die zu Beginn des Spiels beim Spieler sind mit dem Attribut moved. Hier wird ein Attribut verwendet und das ist auch sinnvoll, da dieser Mechanismus so bei allen Objekten verfügbar ist, ohne, dass der Autor bei jedem Objekt eine Property definieren muss.

(Das ist, wie fast immer in Inform, nur die halbe Wahrheit: Inform unterscheidet zwischen common properties und individual properties. Die z-Maschine implementiert das Konzept der Properties, ist aber auf 64 Properties beschränkt. Alte Versionen von Inform hatten diese Beschränkung ebenfalls, so dass viele Objekte die Dummy-Property number definieren, die dann aber von jedem Objekt individuell genutzt wird, d.h. die eigentlich bei jedem Objekt eine andere Bedeutung hat. Common Properties haben einen Default-Wert, so dass man bei einem Objekt, das eine Common property nicht definiert zumindest Lesezugriff darauf hat. Mit Property wird eine Property als Common deklariert und dort kann man auch den Default-Wert definieren.

Inform 6 hat das Konzept der Properties erweitert, so dass man nun Properties definieren kann, ohne sie extra vorher als solche zu definieren. Die Definition der Property muss jedoch in einem Objekt auftreten, bevor sie zum ersten Mal verwendet werden kann.)

(Die Musterlösung zur selben Aufgabe in einer älteren Ausgabe des Inform-Manuals verwendet übrigens wie du ein Attribut, allerdings kein eigens definiertes, sondern das Allzweckattribut general.)

(Dass man über die Attribute und über die common properties die Möglichkeit hat, allgemein gültige Regeln zu definieren, ist natürlich schön, aber man könnte es ja auch dadurch erreichen, dass man zum Beispiel alle Objekte im Spiel zur Klasse Thing und alle Räume zur Klasse Room gehören lässt, die dann die entsprechenden Properties definieren. So würde man es wohl in TADS2 machen.)

Martin:

Die Lib unterscheidet allerdings bereits, ob ein Gegenstand bereits aufgehoben (oder "bewegt") wurde und belegt alle Objekte, bei denen ein ##Take erfolgreich war und alle Objekte, die zu Beginn des Spiels beim Spieler sind mit dem Attribut moved. Hier wird ein Attribut verwendet und das ist auch sinnvoll, da dieser Mechanismus so bei allen Objekten verfügbar ist, ohne, dass der Autor bei jedem Objekt eine Property definieren muss.

Sowas dachte ich schon. Das war einer der Gründe, warum ich ein Attribut für richtiger hielt: Ob etwas bewegt wurde, ist immer mal wieder wichtig.

Also ist der beste code eigentlich sowas:

   Take: if (self hasnt moved) "You pick the mushroom, neatly cleaving its thin stalk.";

      "Du nimmst ihn wieder auf";

   Drop: "The mushroom drops to the ground, battered slightly.";

],```

**Zitat:**
> (Die Musterlösung zur selben Aufgabe in einer [älteren Ausgabe des Inform-Manuals](http://ifarchive.org/if-archive/infocom/compilers/inform6/manuals/old/designers_manual.pdf) verwendet übrigens wie du ein Attribut, allerdings kein eigens definiertes, sondern das Allzweckattribut **general**.)

Da fragt man sich nur, was man da machte, wenn man mehr als ein Attribut brauchte, aber das würde nun zu weit gehen 

**Zitat:**
> zum Beispiel alle Objekte im Spiel zur Klasse Thing und alle Räume zur Klasse Room gehören lässt, die dann die entsprechenden Properties definieren.

Sowas hatte ich schon im Hinterkopf.. Dass Räume und Dinge beide Objekte sind, fand ich sowieso recht hässlich.

---

Gibt es eigentlich irgendeine brauchbare Entwicklungsumgebung für Inform 6, mit Einfärbung, Autoverfollständigung (besonders bei den möglichkeiten in before und after wär' das praktisch) und so?

Ich hätte da einen namens "wide" gefunden, aber das linux-binary ist defekt (das GUI kommt zwar, aber keinerlei Sourcecode zu sehen)

Klaue:

Dass Räume und Dinge beide Objekte sind, fand ich sowieso recht hässlich.

Inform 7 hat das schon vordefiniert als die Objektklassen (die da "kinds" heißen) room und thing. Und auch bei den Typen ist Inform 7 etwas pingeliger.

Klaue:

Gibt es eigentlich irgendeine brauchbare Entwicklungsumgebung für Inform, mit Einfärbung, Autoverfollständigung (besonders bei den möglichkeiten in before und after wär' das praktisch) und so?

Vielleicht die hier:

http://wide.berlios.de/

Ansonsten gibt es in Roger Firths Inform FAQs eine ganze Menge Infos:

http://www.firthworks.com/roger/informfaq/index.html

Grüße,

Christian

Heh, mein Edit kam wohl zu spät

Wide klappt leider nicht

Die im FAQ noch erwähnten sind entweder nur Windows oder bessere Texteditoren, was auch nicht viel hilft