Hallo an alle:

Auf meinem Hof steht ein kleines Klohäuschen. Das ist gleichzeitig Behälter und Raum. Somit kann ich das Klo von außen betrachten

(<<Examine>> bringt "Ein einfacher Bretterverschlag steht am Hofrand.") als auch betreten (<<Look>> bringt: "Du befindest dich..."); im zweiten Fall sind die Dinge auf dem Hof weder sicht- noch erreichbar.

Bisher würde ich daraus zwei Objekte machen, eines aus der Klasse Raum und einen Behälter. Ein <<Enter>>-Befehl bezgl. des Behälter wird abgefangen und in einen <<go>>-Befehl umgewandelt.

Lässt sich das vereinfachen? Dazu zwei Ideen:

1. Könnte es sinnvoll sein, ein Raum-Objekt "Klohäuschen" zu definieren, das im Raum-Objekt "Hof" enthalten ist? Dann müsste die description-Property des Klos eine Fallunterscheidung beinhalten.

2. Man könnte auf den Raum Klohäuschen verzichten und den Hof modifizeren, je anchdem, ob der Spieler im/auf dem Klo ist oder nicht.

Beides klingt nach viel Programmieraufwand, so dass mir das bisherige Verfahren (2 Räume + 1 scenery-Objekt) am simpelsten erscheint. Wie handhabt ihr solche Strukturen?

(Gibt es eigentlich eine maximale Anzahl von Objekten, Räumen, Variablen u.s.w., die Inform verarbeiten kann?)

Schöne Grüße,

Christof

Unterräume gibt es in Inform nicht. Ich sehe hier zwei sinnvolle Möglichkeiten. Welche Du wählst, hängt davon ab, was der Spieler machen kann und soll.

Die einfachere Lösung: Behandle das Klohäuschen wie einen Raum, der, sagen wir mal, nördlich vom Hof ist. Zusätzlich erstellst Du ein scenery-Objekt auf dem Hof, das vielleicht noch als door fungiert. Alle relevanten Aktionen - betreten, hieinschauen und so - fängst Du bei diesem Objekt ab.

Die beiden Räume sind voneinander unabhängig: Wenn man im Häuschen ist, kann man nicht mit den Dingen auf dem Hof interagieren und umgekehrt. Das ist gewiss in Ordnung so. Ausnahmen könne ja immer noch programmiert werden.

Constant Story "Herzhausen";

Constant Headline "^Ein interaktives Bedürfnis^^";

Include "Parser.h";

Include "VerbLib.h";

 Object Hof "Hof"

   with description

            "Auf dem Hof scharren einige Hünher vor einem

            kleinen, mit einem Herz verzierten Klohäuschen

            im Norden.",

        name 'huehner' 'vieh' 'tiere',

        n_to Im_Haeuschen,

        in_to Im_Haeuschen,

    has light;

   

 Object -> Klohaeuschen "Klohäuschen"

   with name 'haeuschen' 'klohaeuschen' 'klo'

            'abort' 'm.' 'herz' 'herzchen'

            'verschlag' 'm.' 'bretterverschlag' 'm.',

        description

            "Ein Bretterverschlag mit einem Herz in der ~Tür~.",

        before [;

            Search:

                print "Du schaust durch das herzförmige Loch

                    in der Tür:^";

                if (Locale(Im_Haeuschen, "Du siehst",

                    "Du siehst außerdem") == 0)

                    "^Das Klo ist nicht besetzt.";

                "";

               

        ],

        door_to Im_Haeuschen,

        door_dir n_to,

    has neuter scenery openable door;

 Object Im_Haeuschen "Im Klohäuschen"

   with description

            "Bisschen eng, aber wenigstens bist du hier

            sicher vor den Blicken der Hühner.",

        out_to Hof,

        s_to Hof,

        d_to Hof,

    has light;

 

 Object -> Rolle "Rolle Toilettenpapier"

   with name 'rolle' 'papier' 'toilettenpapier'

            'klopapier' 'p.',

        description

            "Nicht mehr viel übrig.",

    has female;   

   

[ Initialise;

   

    location = Hof;

    "^^^Dich drückt etwas.^^^";

];

Include "GermanG.h";

(Siehe hierzu auch die I7-Übung Starry Void.)

Die etwas kompliziertere Lösung ist, das Häuschen zu einem enterable, openable, static container zu machen - dann kann man das Häuschen betreten, die Tür von innen zumachen und sogar von draußen Sachen hineinlegen. So etwas würde ich machen, wenn es wichtig ist, dass man die Dinge sowohl aus dem Häuschen als auch vom Hof aus sehen und handhaben soll.

Constant Story "Herzhausen";

Constant Headline "^Ein interaktives Bedürfnis^^";

Include "Parser.h";

Include "VerbLib.h";

 Object Hof "Hof"

   with description

            "Auf dem Hof scharren einige Hünher vor einem

            kleinen, mit einem Herz verzierten Klohäuschen

            im Norden.",

        name 'huehner' 'vieh' 'tiere',

        n_to [; <<Enter Klohaeuschen>>; ],

        in_to [; <<Enter Klohaeuschen>>; ],

    has light;

   

 Object -> Klohaeuschen "Klohäuschen"

   with name 'haeuschen' 'klohaeuschen' 'klo'

            'abort' 'm.' 'herz' 'herzchen'

            'verschlag' 'm.' 'bretterverschlag' 'm.',

        description

            "Ein Bretterverschlag mit einem Herz in der ~Tür~.",

        inside_description

            "Bisschen eng hier im Klohäuschen, aber wenigstens

            bist du hier sicher vor den Blicken der Hühner.",

    has neuter scenery container openable enterable light;

 

 Object -> -> Rolle "Rolle Toilettenpapier"

   with name 'rolle' 'papier' 'toilettenpapier'

            'klopapier' 'p.',

        description

            "Nicht mehr viel übrig.",

    has female;   

   

[ Initialise;

   

    location = Hof;

    "^^^Dich drückt etwas.^^^";

];

Include "GermanG.h";

(Siehe hierzu auch die I7-Übung Tamed.)

(Die inkonsistenten Texte und Beschreibungen zu korrigieren ist als Aufgabe für den Leser gedacht, ich wollte nur zeigen, wie's im Prinzip funktioniert.)

C++:

(Gibt es eigentlich eine maximale Anzahl von Objekten, Räumen, Variablen u.s.w., die Inform verarbeiten kann?)

Räume sind in Inform auch Objekte. Diese sind eigentlich nicht beschränkt. Der Compiler kann aber nur eine gewisse Anzahl von Objekten erzeugen. Dieses Limit kann man aber beim Aufruf mit (glaube ich) $MAX_OBJECTS=700 hochsetzen.

Für z-Code gilt, dass alle Objektdaten in den Speicherbereich unter der 64k-Grenze passen müssen, und den teilen sich die Objekte mit den Vokabeln, der Grammatik, den Variablen, den Felddaten und dem Dateikopf. Wenn das Limit erreicht ist (was nicht sehr wahrscheinlich ist), kann man sich im DM4 das Kapitel zu den Sparmaßnahmen durchlesen oder direkt beim Kompilieren -G wie Glulx sagen.

Die Anzahl der globalen Variablen ist auf 237 oder so begrenzt und die Lib verbraucht davon schon gut die Hälfte. Die Anzahl der Properties ist für alle praktischen Belange unbegrenzt, daher wird empfohlen statt globalen Variablen individuelle Properties zu verwenden.

Dank dir, Martin!

Die beiden von dir genannten Möglichkeiten hatte ich in etwa auch im Sinn. Nur habe ich mal nicht auf die Schnelle rund 70 Zeilen Code aushusten können...

Ich werde es so machen, wie du vorgeschlagen hast: ein Scenery-Object, dessen Betreten in ein go-to umgewandelt wird.

Ich habe übrigens gerade ausprobiert, was passiert, wenn man ein Tochterobjekt (ein Stuhl in einer Stube) über eine n_to Property anstatt über <<Enter>> ansteuert. Alles im Raum ist weiterhin problemlos sicht- und erreichbar, ein Befehl funktioniert jedoch nicht, nämlich <<Ende>>. Man muss den Interpreter schließen.

Schöne Grüße,

Christof