Sicher kennt ihr aus verschiedenen Adventures diese Funktion, mit der ihr "Gehe zur Kammer" eingeben könnt, und die SpF macht sich dahin auf den Weg. Wenn sie unterwegs aufgehalten wird, bleibt sie stehen.

So was hab ich für TAG geschrieben. Ich bin mir allerdings nicht sicher, ob man's nicht auch einfacher machen könnte. Immerhin, ich habe zum ersten Mal erfolgreich TAG-Felder eingesetzt, aber die Zahlenkolonnen bei einer sehr großen Karte würden doch arg lang werden.

Wer a) selbst so einen Befehl einbauen möchte, aber nicht weiß, wie

b) einfach neugierig ist oder

c) auf der Grundlage meines Codes eine bessere Lösung finden möchte,

der schreibe mir eine kurze Mail (jens@tanan.de). Ich schicke ihm dann die Demo samt Quelltext.

*

Insbesondere Dich, Martin, würde ich bitten, mal einen Blick drauf zu werfen, denn der Workaround, den Du mir für mein "fragen über"-Beispiel gesendet hast, funktioniert hier nicht: Es nützt nichts, den Raum (bzw. dessen Objekt) "insicht" zu bewegen, weil der Parser dann nämlich denkt, er wäre schon da:

Bed /(aObj hier) 'Da bist du schon.'

(aObj) ist das Objekt, das stellvertretend für einen Raum steht.

Danke im Voraus!

Tanan der Wanderer:

Sicher kennt ihr aus verschiedenen Adventures diese Funktion, mit der ihr "Gehe zur Kammer" eingeben könnt, und die SpF macht sich dahin auf den Weg. Wenn sie unterwegs aufgehalten wird, bleibt sie stehen.

Ja, das kenne ich aus Guild of Thieves. Das war manchmal recht praktisch, obwohl ich es nie richtig benutzt habe. Aus anderen Spielen ist mir kein ähnliches Konzept bekannt.

Tanan:

So was hab ich für TAG geschrieben. Ich bin mir allerdings nicht sicher, ob man's nicht auch einfacher machen könnte. Immerhin, ich habe zum ersten Mal erfolgreich TAG-Felder eingesetzt, aber die Zahlenkolonnen bei einer sehr großen Karte würden doch arg lang werden.

Die Idee, den nächsten Schritt für jeden Raum auf ein Feld zu legen, ist sehr gut. Ich hätte wahrscheinlich versucht, jeden Pfad abzuspeichern. (Oder gar ein U-Bahn-Modell nach Volker Lanz zu implementieren.)

Bei einem Adventure mit vielen Räumen (und nur für so eines ist diese Abkürzung ja sinnvoll) müsste man halt sehr viele Felddaten einlesen. Allerdings kann man wahrscheinlich in einem großen Spiel nicht ueberall hingehen, sondern nur zu ein paar ausgewaehlten, markanten Punkten. Das spart auch Objekte, die ja mit 250 recht knapp bemessen sind.

Seit Kurzem ist es in T.A.G. möglich, mit einem vorangestellten & Variablen jeden Typs als Zahlen zu betrachten. Felder können nur Zahlen als Inhalt haben, aber man könnte etwas schreiben wie:

    Jenach araum

        (gangA)    

            Daten rritg 0 ( 0 &O &O &N &N &O &O)

        (gangB)    

            Daten rritg 0 (&W  0 &O &W &N &N &O)

        ...

    Ende

Ob das jetzt übersichtlicher ist, sei dahingestellt. Aber es erspart die jenach-Abfrage und reduziert sie auf:

    sei &aRitg lesRitg

    wenn (aRitg = 0) Stop

339966

Tanan:

Insbesondere Dich, Martin, würde ich bitten, mal einen Blick drauf zu werfen, denn der Workaround, den Du mir für mein "fragen über"-Beispiel gesendet hast, funktioniert hier nicht: Es nützt nichts, den Raum (bzw. dessen Objekt) "insicht" zu bewegen, weil der Parser dann nämlich denkt, er wäre schon da:

Zunächst vielleicht ein paar Worte zum oben angesprochenen Workaround: Die Angabe (Allg) lässt Objekte zu, die sich überall im Spiel befinden, auch im nirgendwo und im Nirwana. Sie ist speziell für verben wie "frage" oder "schlage nach" gedacht. Bei mehrdeutigen Angaben fragt der Parser nicht nach, sondern nimmt einfach das zürst im Quelltext auftauchende Objekt.

Um das zu umgehen, kann man für die Syntax von "frage" anstatt (Allg) einfach (hier) beziehungsweise gar nichts, da (hier) der Default ist, setzen:

    Bef     fragen

    Name    'fragen'

    Verb    'frage'

    Syntax  dasObj (Person) über dasObj

    ...

Dann kann man in der Routine SichtUndRW, die aus dem Parser heraus aufgerufen wird, um zu prüfen, ob sich Objekte in Sicht oder Reichweite befinden, folgendes schreiben:

    Aktion SichtUndRW

    Ausf

        wenn (aBef = fragen) und (%obj = 2) dann

            wenn (iObj bekannt) ObjInSicht iObj

        Ende

    EndeAusf

Das Attribut bekannt wird automatisch gesetzt: Alle Objekte, die der Spieler einmal gesehen hat, d.h. in der Regel alle, die einmal in einer Raumbeschreibung aufgelistet wurde, bekommen es. Wer will, dass ein Objekt, das der Spieler noch nicht gesehen hat, von dem er aber vielleicht gehört hat, als Gesprächsthema bekannt ist muss bekannt halt von Hand setzen.

    Text 'Der Söldner spuckt auf den Boden und

        sagt "Dazu brauchst Du den Bergkristall

        von Asgaroth. Fingar der Wanderer kann

        dir bestimmt mehr darüber sagen."'

    AttrHin Bergkristall bekannt

    AttrHin Fingar bekannt

339966

Die Lösung für Dein Problem ist, nicht die Funktion hier zu verwenden, die berücksichtigt, ob Objekte mit ObjInSicht in Sichtweite geholt wurden, sondern die direkte Abhängigkeit zu prüfen:

    Bed /(aObj.Stammraum = aRaum) 'Da bist du schon.'

Außerdem steht an der entsprechenden Stelle des Feldes ja eine Null, die könnte man auch prüfen. (Was aber dank der komplizierten Feldoperationen in T.A.G. kompliziert wäre.)

Martin:

Bed /(aObj.Stammraum = aRaum) 'Da bist du schon.'

Klar! So funktioniert's. Warum sieht die Lösung immer so einfach aus?

Danke.

Zitat:

Allerdings kann man wahrscheinlich in einem großen Spiel nicht ueberall hingehen, sondern nur zu ein paar ausgewaehlten, markanten Punkten. Das spart auch Objekte, die ja mit 250 recht knapp bemessen sind.

Ich habe bisher immer alle Räume auch als Objekte eingebunden. Das hat den Vorteil, daß man auch "u Zimmer" eingeben kann, und dann kommt die Raumbeschreibung. Ich mag solche Details. Klar, sparen kann man trotzdem, wenn man z.B. einen langen Gang mit einer einzigen Deko ausstattet, die dann überall dort zu sehen ist. Aber ich weiß nicht, ob ich es verkrafte, wenn man in dem Spiel nachher nicht alles direkt ansteuern kann. Mal sehen.

Zitat:

Ja, das kenne ich aus Guild of Thieves. Das war manchmal recht praktisch, obwohl ich es nie richtig benutzt habe. Aus anderen Spielen ist mir kein ähnliches Konzept bekannt.

Es gibt mindestens ein Infocom-Spiel, in dem es das auch gab. Mir fällt gerade der Titel nicht ein, aber hier gibt es ja Spezialisten für sowas...

Tanan:

Martin:

Ja, das kenne ich aus Guild of Thieves. Das war manchmal recht praktisch, obwohl ich es nie richtig benutzt habe. Aus anderen Spielen ist mir kein ähnliches Konzept bekannt.

Es gibt mindestens ein Infocom-Spiel, in dem es das auch gab. Mir fällt gerade der Titel nicht ein, aber hier gibt es ja Spezialisten für sowas...

Ha! Es war Moonmist. Das Spiel ist zwar nicht so besonders, aber das 'go to'-feature hat es mir hier echt angetan - Man bewegt sich durch die halbwegs bekannten Räume eines Schlosses, da macht die Funktion Sinn.

Ich bin übrigens kein Spezialist für Infocom-Spiele.

http://www.textadventures.de/

Walafrid:

Ich muss ehrlich sagen, ich habe das in Moonmist nicht benutzt. Vielleicht hab ich's deshalb nicht zu Ende gespielt...

Möglich. Schließlich läuft bei dem Spiel (leider) auch die Uhr mit, und mit 'Go to' bewegt man sich merklich schneller durchs Gebäude, als wenn man jeden Raum einzeln durchquert.

Ein geheimnisvoller Fremder?:

Möglich. Schließlich läuft bei dem Spiel...

Das war ich. Einloggen vergessen, tschuldigung.

Ein Moonmist-Spieler namens ryn:

Schließlich läuft bei dem Spiel (leider) auch die Uhr mit, und mit 'Go to' bewegt man sich merklich schneller durchs Gebäude, als wenn man jeden Raum einzeln durchquert.

Bist du sicher? Das ist aber dann eine fehlerhafte Implementierung, oder?

Normalerweise dauert

TAKE APPLE AND BANANA

zwei Runden (zumindest in Inform-Spielen, so weit ich weiß). Und wenn die Kirche drei Räume vom Acker entfernt ist, sollte

GEHE ZUR KIRCHE

(vom Acker aus) drei Runden dauern.

http://www.textadventures.de/

Eigentlich Walafrid:

Ein Moonmist-Spieler namens ryn:

Schließlich läuft bei dem Spiel (leider) auch die Uhr mit, und mit 'Go to' bewegt man sich merklich schneller durchs Gebäude, als wenn man jeden Raum einzeln durchquert.

Bist du sicher? Das ist aber dann eine fehlerhafte Implementierung, oder?

Ich hab extra nochmal nachgeschaut: Das ist wirklich so, und vielleicht auch Absicht. Als Rückmeldung auf einen 'Go to'-Befehl kommt nämlich z.B. "You go quickly toward the dining room."

In Verbindung mit der schön gemachten beiliegenden Karte, auf der alle offiziellen Raumnamen verzeichnet sind, wirkt das auf mich wie eine Abwehrmaßnahme gegen Raubkopierer.

Das ist übrigens ein Mangel, den auch meine Lösung hat: Es vergeht immer nur ein Zug, egal, wie weit man geht.

Tanan:

Das ist übrigens ein Mangel, den auch meine Lösung hat: Es vergeht immer nur ein Zug, egal, wie weit man geht.

Dieser Mangel lässt sich mit der momentanen Version von T.A.G. aber nicht beheben. Weder ist es möglich, die Eingabe zu überbrücken, noch kann man einen kompletten Spielzug aus einem anderen heraus aufrufen.

Eine Möglichkeit, die ich einmal (im Zusammenhang mit einem Modul, das es dem Spieler erlaubt, eine bestimmte Zeit lang zu warten) überlegt hatte, ist die Einführung einer weiteren globalen Systemflagge, sagen wir mal, hmmm, Verzögerung.

Wenn diese Flagge Null ist, läuft ein Spielzug wie gewohnt ab: Eingabe einer Anweisung, Analyse, und schließlich, wenn der Satz verstanden wurde, darf der Spieler seine Aktion ausführen, danach bekommen alle anderen (etwa mit einer Aktion *) die Chance, etwas zu tun.

Wenn Verzögerung gesetzt ist, passiert folgendes: der Spieler darf keinen Befehl eingeben, aBef ist Null und der Spieler fürhrt keine Aktion aus. Damit entfällt der ganze Block mit VorAusfen und NachAusfen. Alles andere, wie z.B. umherwandernde NPCs, brennende Zündschnüre und natürlich auch die Zeit, verhalten sich normal, so als ob der Spieler lediglich "warte" eigegeben hätte. (Am Ende des Zuges könnte Verzögerung um eins vermindert werden, was verhindert, dass der Spieler nie wieder einen Prompt sieht, weil schlampig programmiert wurde.)

Im gehezu-Beispiel würde (Verzögerung) bedeuten, dass der Spieler noch in Bewegung ist. Der Befehl "gehe_zu" würde nur den Zielort und Verzögerung setzen, die eigentliche Bewegung müsste aus einer Aktion * aufgerufen werden.

339966

Die Änderung wäre natürlich ein Eingriff in das bestehende T.A.G.-Format. Das heißt, es gäbe wieder eine neue T.A.M. (Die wievielte?) Alte Spiele würden aber weiterhin funktionieren, das es vier oder so freie Systemvariablen gibt, die bislang immer Null sind.

Tanan:

Das ist übrigens ein Mangel, den auch meine Lösung hat: Es vergeht immer nur ein Zug, egal, wie weit man geht.

Nun kenne ich TAG leider nicht, aber wenn die Anzahl der Züge in einer Variablen gespeichert wird, könnte man diese Variable nicht auch manuell hochsetzen?

Mo:

Nun kenne ich TAG leider nicht, aber wenn die Anzahl der Züge in einer Variablen gespeichert wird, könnte man diese Variable nicht auch manuell hochsetzen?

Das wäre für ein einfaches Spiel OK. Die Zeit würde verstreichen, die Anzahl der Züge erhöht. Aber die Spielwelt bliebe dann auch stehen, und mit ihr alle NPCs, U-Bahnen, Aufzüge, fallende Steine, tickende Bomben und Taschenlampenbatterien.

Eine (vielleicht bessere) Alternative zu meinen Gedanken oben wäre deshalb ein Befehl ZeitVergeht, der einen Zug verstreichen lässt, das heißt, jeder darf was machen, nur der Spieler nicht. Konkret bedeutet das, dass alle Aktionen * ausgeführt werden und die Aktion Nachher.

Was ich oben gesagt habe, könnte dann einfach in T.A.G. programmiert werden:

    Flagge Verzögerung

   

    Aktion Nachher

    Ausf

        solange (Verzögerung)

            Zeitvergeht

            dekr Verzögerung

        Ende

    EndeAusf

Ja, das gefällt mir.

Klingt gut!

Martin:

Das heißt, es gäbe wieder eine neue T.A.M. (Die wievielte?)

Und von mir aus kannst Du jede Woche ne neue TAG-Version rausbringen, solange sie auch mit alten Spielen klappt und immer schöne neue Features drin sind. g

Tanan:

Klingt gut!

Fatto! Ich habe Jens' Modul etwas überarbeitet und auf die Seite Nuetzliches fuer T.A.G. gepackt. Es funktioniert allerdings nur mit der neuesten Version von T.A.G. und T.A.M. vom 29. Oktober 2002.

Tanan:

Und von mir aus kannst Du jede Woche ne neue TAG-Version rausbringen, solange sie auch mit alten Spielen klappt und immer schöne neue Features drin sind. g

Solange alte Spiele noch funktionieren, ist es, denke ich, auch kein großes Problem.

Andersherum muss allerdings der Autor eines Spiels dann aber unbedingt in seinem Spiel mitteilen, welche Version es mindestens benötigt. Wenn man zum Beispiel das Modul oben mit einem neuen T.A.G. kompiliert und es adnn mit einer alten T.A.M. spielt, kommt irgendwann die Meldung "[unbekannte Anweisung]".

In der T.A.G.-Datei sind das momentane und das Kompabilitätsdatum enthalten, sie werden aber noch nicht benutzt. Vielleicht sollte die T.A.M. in Zukunft am Anfang eine Warnung ausgeben, wenn es dort Unstimmigkeiten gibt.