Wen es interessiert, hier mal ein Text. Mich interessiert, ob Attributregeln bzw. -klassen nicht ein gangbarer Weg sind, um die Programmierung von Adventures einfacher zu machen.

In Adventurespielen ist es wichtig, unterschiedliche Variablen zu haben, die unterschiedliche Zustände von Aktionen annehmen. Dies mag auf den ersten Blick gut erscheinen, führt aber zu verwirrenden Ketten von ineinander geschachtelten Abfragen.

Nehmen wir ein einfaches Beispiel zur Verdeutlichung einer typischen Handlung: Ein Fels blockiert den Weg in Richtung eines Tales und man gelangt nur in das Tal, wenn dieser Felsblock mit einer dafür geeigneten Säge zerschnitten wurde.

Um die Aktion ausführen zu können braucht man als Spieler erst einmal eine passende Säge. Normalerweise würde man abfragen, ob sich diese Säge im Besitz des Spielers befindet und ob der Parser gemeldet hat, dass diese Säge auf den Stein benutzt werden darf, der Parser filtert dabei alle ungültigen Eingaben wie z. B. "benutze Säge mit Fels" und erlaubt die Aktion erst, wenn z. B. "zerschneide Felsblock mit Säge" vom Spieler eingegeben wird.

Für die interne Objektlogik (das Weltmodell) ist es gleichgültig, wie diese Aktion ausgelöst wurde, entscheidend ist, dass sie ausgelöst wurde und was nun geschehen soll.

Man ersieht sofort, dass die Säge auf ein mögliches Objekt angewendet werden soll, man sieht auch, dass der Spieler sowohl die Säge als auch den Felsblock erreichen kann, folglich erscheint die Aktion als gültig.

Moment: Es könnte sein, dass die Säge erst noch geschärft werden muss, bevor sie den Felsen angreift. Es müsste nun also abgefragt werden, ob die Säge scharf genug ist, ob sie das Attribut/Flag "geschärft" enthält. Bei inform würde man vielleicht general setzen.

Es gibt allerdings auch eine Alternative, wenn man in einer relationalen Datenbank alle möglichen Zustände kummulativ sammeln könnte, die Säge könnte dann sowohl das Attribut "aus Eisen", "scharf" und "kaputt" und noch unzählige andere Attribute haben.

Es könnte für den Felsen unbedingt notwendig sein, dass die Säge aus Eisen wäre, dass sie scharf wäre und dass sie nicht kaputt wäre, damit die oben beschriebene Aktion greifen könnte. Sollte man dies alles für den Felsen abfragen?

if(if(if())) ?

Das wäre doch sehr umständlich. Nein, dies ist nicht der beste Weg, sondern der Fels könnte z. B. in die Attributklasse "steinhart" gestellt werden. Steinharte Objekte scheinen sich nun nur mit Gegenständen zerschneiden zu lassen, die der Mindestbedingung genügen, aus Eisen, scharf und nicht kaputt zu sein.

Damit sind von vorne herein alle weichen Gegenstände disqualifiziert. In Frage kommen auch Gegenstände, die aus hartem Diamant sind oder Gegenstände, mit denen man in Stein bohren kann.

Man definiert dazu ein Regelset und dieses befindet sich in der Attributklasse "steinhart", die Mindestanforderungen an die "Zerschneidbarkeit" von "felsenfesten" Objekten stellt.

Auf diese Weise erspart man sich lange Abfragen, da nun die Attribute direkt sprechen, da sie einen Hebel haben, der die Objektbeziehungen regelt.

Es gibt immer einen aktiven und einen reaktiven Teil. Drückt man eine Klinke, öffnet sich eine Türe, dreht man den Schlüssel, öffnet sich ein Schloss, hebt man einen Gegenstand auf, empfängt man diesen usw. Dies alles sind nur Regelsets.

Soweit wäre also eine Beziehung zwischen der Säge und dem Felsen scheinbar geklärt, allerdings stimmt das nur zum Teil, weil das Weltmodell nicht weiß, was aus dieser Beziehung wirklich erfolgen soll. Es könnte nur melden: "Du zerschneidest erfolgreich den Felsen..." und "Du erblickst einen zerschnittenen Felsen..."

Aber mehr wäre noch nicht drin.

Warum?

Der Weltmodell weiß noch nicht, dass der Felsen einen Weg blockiert und es weiß ebensowenig, dass ein zerschnittener Felsen einen Weg nicht blockieren kann.

Wir sehen auch, dass man auch noch ganz anders den Felsen entfernen könnte, z. B. durch einen Kran, aber auch in diesem Fall wäre die Auflösung möglich, wenn das Weltmodell wüßte, dass "weggehoben" auf das gleiche hinausläuft wie "zerschnitten" bzw. "weggehoben_2" und "zerschnitten_x".

Wir brauchen also wiederum Attributklassen, die definieren, dass "weggehoben" und "zerschnitten" einen Weg freigeben können.

Im Regelset der Attributklassen könnte stehen, dass Objekte, die weggehoben werden, aus dem Spiel entfernt werden usw.

Objekte, die zerschnitten sind, könnten nicht weiter den Weg in eine Richtung blockieren. Diese Regelsysteme werden vom Spielleiter im Vorfeld als Attributklassen definiert, die sich dann auf die Objektbeziehungen auswirken. Natürlich kann man fragen, ob dies nicht einfach nur die Verschiebung von Funktionen von den Objekten weg ist.

Ja, aber es ist doch als Ergänzung nicht schlecht, ebenso wie überhaupt vordefinierte Aktionen, wie sie z. B. inform vorsieht.

Bis zu einem gewissen Grade wird die Erstellung von Adventurespieelen dadurch vielleicht einfacher.

Dieser Weg erinnert mich auch etwas an die Logiksprachen Lisp und Prolog, diese haben wohl eine gemeinsame Logik mit denen von Adventurespielen.

Diesen Post verstehe ich nicht. Du schlägst ja hier vor, was in Adventures sowieso üblicherweise gemacht wird. In einem typischen Spiel, das, sagen wir mal, mit Inform geschrieben wird, gibt es (a) die Bibliothek, die ein möglichst allgemeines Weltmodell beschreibt, (b) die Ergänzungen des Weltmodells für das jeweilige Spiel, wie zum Beispiel allgemein gültiger Code zum Schneiden von Dingen, zum Mixen von Flüssigkeiten, zum Handhaben von Seilen, und schließlich (c) einzelne Objekte, die den Regeln des Weltmodells unterliegen, die aber auch oft eigene Regeln haben, wie zum Beispiel dein Stein.

(a) und (b) definieren eigene Attribute, Objekteigenschaften und Klassen. Gut, die Bibliothek von Inform benutzt keine eigenen Klassen, aber für Spielwelten mit vielen ähnlichen Objekten würde man solche als Ergänzungen wohl anlegen, wie Klassen für NPCs, Räume, sich automatisch öffnende Türen usw. Abschnitt 25 im DM4 beschreibt, wie man die Regeln der Library erweitern kann. Ein Beispiel für die Erweiterung der Lib zum Zerschneiden von Objekten findet man im Inform FAQ.

Wenn alle Objekte nur durch die gültigen Regeln beschrieben werden, hat man entweder ein recht langweiliges Spiel (weil eins von drei Rätseln ein Stein ist, der einen Weg blockiert) oder ein übermäßig komplexes Regelwerk (weil eine Einzelsituation bereits in den allgemeinen Regeln abgefangen wird). Deshalb haben die Objekte üblicherweise eigenen Code, der besondere Situationen abfängt, im Fall des Felsens halt die Freigabe des Wegs.

In der Praxis bietet sich ein Kompromiss an: Das Modell des Schneidens sollte bereits ein gewisses Maß an Genauigkeit mitbringen. Wenn der Spieler eine Säge findet, möchte er verschiedene Sachen zersägen, und dann ist es dem Spiel, das ja letztendlich eine Simulation einer Spielwelt ist, abträglich, wenn die Antwort auf fast alle Sägeversuche ein abschlägiger Standardtext ist. Die Einzelsituationen werden dann am Objekt selbst abgefangen, so dass man hier auch individuelle Texte ausgeben kann. Wenn das Weltmodell (Säge geschärft? Und aus Eisen? Und noch intakt?) zuerst geprüft werden soll, muss man diese Situationen halt nicht in before, sondern in after berücksichtigen.

Um noch einmal zu rekapitulieren: Die in der Library vogegebenen Regeln sind erweiter- und austauschbar, und üblicherweise werden zur Beschreibung der Regeln Objektklassen und neue Attribute und Eigenschadften verwendet. Um das Schreiben des ein oder anderen if-Konstrukts direkt beim Objekt-Code wirst du nicht herumkommen, wenn du ein Textadventure (und nicht etwa eine Textvariante von NetHack) schreiben willst.

Hmm...

dieses Posting liest man nicht in einer Minute, das muss man erstmal sacken lassen :-)

Ich denke auch, hier wird es verkompliziert. Wie Martin schon gesagt hat, werden besondere Objekte in der berfore oder after Property komplexe Vorgänge, die nur sich selbst (möglicherweise auch andere Objekte) betreffen, abfangen.

Eine Möglichkeit eine allgemeinere "Regeln" aufzustellen wäre doch z.B. eine Gewichts-Property mit einem Wert (z.B 10) und im Gegenzug eine Kraft-Property eines Zwerges.

Verschiedene Aktionen (z.B füttern des Zwerges, dann trinken geben usw. - vielleicht auch eine Massage) stärken den Zwerg und Kraft wird jedesmal um 1 erhöht, hiefür könnte man noch die "GibtKraft-Property" einführen, diese würde bei einer Kirsche den Wert 1 und bei einem Steak vielleicht 4 haben. Dieser Wert wird an den Empfänger (dessen Kraft-Property) weitergeben. Gibt man dem Zwerg den Befehl den Stein zu heben, könnte man jedes mal abfragen ob Kraft und Gewicht mindestens gleich sind.

Gleiches Konzept könnte man mit einer Schärfe- und Härte-Property entwickeln. Dann einige Gegenstände damit versehen und schon hat man ein relativ flexibles System das dem Spieler viele verschiedene Möglichkeiten einer Problemlösung bietet.

Kris