ChristianB:

wenn man sich mit der Sekretärin beschäftigt, egal wie oft

schöne Vorstellung, aber ich schweife ab... :-)

Zurück zum Thema:

ChristianB:

Also beispielsweise nach einem Zug (sofort), wenn man sich mit der Sekretärin beschäftigt, egal wie oft. Beim ersten Mal in den Spiegel schauen ist der Anblick ebenfalls so interessant, dass die Stunde schon nach einem Zug verflogen ist. Bei den nächsten Malen müsste man vielleicht öfter hineinschauen, um sich an seinem Spiegelbild hinreichend zu ergötzen. Usw.

Ok, verstehe, das würde aber bedeuten, dass man nicht die Aktion als solche zeitlich bewerten würde, sondern doch auch wieder das betreffende Objekt (wie in Florians Beipiel). Und beim zweiten Mal könnte es ja auch länger dauern als beim ersten Mal (wenn z.B. beim zweiten Anblick auf das Foto der Ex die Depression so richtig zuschlägt), es ist ja nicht automatisch kürzer.

Dann müßte jedes Objekt wieder einzeln in die Hand genommen werden. Ich würde das nicht programmieren wollen (jedenfalls nicht für ein gesamtes Spiel, für einzelne Szenen ginge das sicherlich)

Gruß

Christof

Florian:

Der Spieler soll sich langweilen, aber nur, wenn er langweilige Dinge tut, und die Zeit soll nur bei einigen vergleichsweise spannenden Dingen voranschreiten.

Genau das wollte ich ursprünglich sagen. Und um dem „Vergleichsweise“ gerecht zu werden, hatte ich dann die Idee mit dem „Kurzweil-Index“, der dem Autor die Möglichkeit geben könnte, nicht nur zwischen zwei Extremen „spannend/langweilig“ zu unterscheiden, sondern Abstufungen zu ermöglichen. Von gaaaanz öde bis super-interessant. Wobei ich es nicht so realistisch fände, wenn bei gaaaanz öde die Zeit stehen bliebe – und das tut sie in 9to5, wenn man z.B. wartet.

Klingt nach Arbeit, weil für jedes relevante Objekt ein Index definiert werden müsste. Aber in T.A.G. hat Martin etwas Ähnliches ja auch schon mit Volumen und Gewicht (Vol und Gew), die für bestimmte Objekte festgelegt werden können, vorgesehen.

Ich habe mal an der Zeit gearbeitet, hierfür zwei Routinen erstellt:

     Close: Seconds(15); return false;

     Disrobe: Seconds(30); return false;

     Drop: Seconds(10); return false;

     EmptyT: Seconds(15); return false;

     Enter: Seconds(15); return false;

   ... usw ...```

und diese

```[ Seconds s;

   

   sec = sec + s;

   

   if (sec >= 60) {the_time = the_time + (sec/60); sec = sec - (sec/60)*60;} ! Sekunden addieren und ggf Minuten abziehen

];```

the_time ist ja die Zeitvariable in Inform, mit

```SetTime( (60*12)+23,0);```

startet das Spiel um 12:23, wobei die 0 nach dem Komma das Voranschreiten pro Zug bestimmt. Null deshalb, da ich meine Zeit selbst machen will.

Die Funktion Seconds(15) bewirkt, dass 15 Sekunden addiert werden.

Die Routine ActionTime rufe ich über die GamePostRoutine, dort werden jeder Aktion eine bestimmte anzahl von Sekunden zugeteilt, ggf. kann man die globale Variable sec auch noch jederzeit manuell aus dem Code heraus vergrößern, also z.B. beim Öffnen einer riesigen Maschine über after noch 30 Sekunden zusätzlich addieren.

Oder wenn man um von Raum A nach Raum B zu gelangen durch einen langen Tunnel laufen muß, kann sec ebenso um 120 Sekunden vergrößert werden.

(Entschludigung dass ich hier im TAG-Forum mit Inform komme)

Ein weiterer Vorteil ist, dass bei unausgeführter Aktion, z.B. weil das angesprochene Objekt nicht im Raum ist, die Zeit nicht weiterläuft, obwohl turns (die Züge) um eins erhöht werden.

the_time kann auch verwendet werden, wie von ChristianB vorgeschlagen, um nach einer gewissen Zeit eine neue Aktion starten zu lassen.

In einem extrem zeitabhängigen Spiel das vielleicht nur eine Stunde abdeckt, könnte man auch die Zeit mit Sekunden anzeigen, bei einem Spiel wie Holywood Hijinx, wo man eine ganze Nacht Zeit hat, fände ich Sekunden in der Statuszeile allerdings kleinkarriert.

Grüße

Christof

Florian:

2. Gibt es weitere klassische Situationen für Timer? Die tickende Bombe fällt mir ein. Weitere? Vielleicht kann man daraus ja Schlüsse ziehen.

• Da gibt es Verließe die mit diversen Sachen volllaufen, Sand, Wasser, Schlamm usw. oder die Decke sinkt langsam zu Boden.

• Man muß aus einem brennenden Raum gelangen bevor die Flammen einen erwischen.

• Im Flieger geht der Sprit aus.

• Eine Batterie, die irgendeine eine Maschine antreibt, reicht nur noch für 10 Minuten (Ich habe jetzt extra keine Taschenlampe genommen :-)

• Einen Countdown für Selbstzerstörung (Planetfall u.a.)

Bei all diesen Situationen würde mir als Spieler eine gute Beschreibung genügen, den Streß mache ich mir dann schon selbst...

Gruß

Christof

Oder in einer Detektivgeschichte, 30er Jahre. Du (Philip Marlowe) willst ein Büro durchsuchen, der Typ, der da drin sitzt, steht auf und geht zur Toilette. Nun kannst du hinein und hast begrenzt Zeit, dich dort umzusehen. Elegant fände ich hier, ein "Sterben" des Spielers zu vermeiden. Will man das schaffen, führt das allerdings zu vier möglichen Enden:

1.) Du findest, was du suchst und verlässt das Büro rechtzeitig.

2.) Du findest, was du suchst, bist aber noch im Büro, wenn der Typ zurückkommt. Jetzt solltest du dich irgendwie herausreden.

3.) Du findest es nicht, verschwindest aber entweder rechtzeitig ...

4.) ... oder schaffst auch das nicht.

Das wär schon große Kunst, wenn das Spiel alle vier Varianten sinnvoll innerhalb der Story abfangen könnte. (Überhaupt der große Haken bei der Verwendung von Zeitlimits - dass in der Regel das Spiel beendet ist, wenn man das Limit reißt. Muss das so? Reicht es nicht manchmal, wenn, wie in diesem Beispiel, spätere Rätsel schwerer werden, weil dem Spieler bestimmte Hinweise fehlen?)

ChristianB:

Bei Florian drückt aber nicht das Zeitlimit auf den Spieler, sondern das Limit will erzwungen/erreicht werden. Eine interessante Umkehrung des Atemnot-Motivs.

Stimmt. Interessante Umkehrung der üblichen Timerverwendung in Spielen überhaupt. Variante 2 des zeitabhängigen Rätselns.

Bei diesem Beispiel ist der Kurzweil-Index auch eine super Idee. Warum? Weil bei Florians Beispiel der Timer an sich schon das ganze Rätsel ist. Üblicherweise ist er ja nur eine Zeitbegrenzung für ein ganz anderes Rätsel. Bombe entschärfen, Büro durchsuchen, Eisdecke aufbrechen.

Variante 3 wären die Rätsel, bei denen man nicht innerhalb eines Zeitlimits, sondern exakt zu einer bestimmten Zeit Handlungen vornehmen muss. Punkt zwölf die Glocke läuten, oder so.

Idee einer Szene, bei der Variante 2 und 3 kombiniert werden: Deine Kumpels wollen in eine Bank einbrechen und du musst draußen Schmiere stehen. Prinzipiell ein langweiliger Job und du hast genügend Zeit, um dir Plakate und Litfaßsäulen anzuschauen, Zeitung zu lesen (nutzen wir die freie Zeit, um dem Spieler Hintergrundwissen unterzujubeln) oder einfach Däumchen zu drehen. Wenn ein Wachmann oder gar die Polizei aufkreuzt, musst du allerdings umgehend deine Kumpels warnen. Warum das Variante 3 ist? Weil deine Leute über falschen Alarm sicher nicht erfreut wären.

ChristianB:

ChrisW:

Kurz: Das Gleichsetzen eines Zuges mit einer bestimmten Zeiteinheit, vom Einführen mehrerer möglicher Zeiteinheiten ganz zu schweigen, wäre mir als Spieler deutlich zu simulationslastig.

Das verstehe ich nicht ganz. Es geht hier doch gerade um Simulation von Zeit und Zeitempfinden.

Geht es. Aber es geht auch darum, das sinnvoll einzusetzen. So, dass der Spieler etwas davon hat. Die Simulation der Länge einzelner Züge ist bei Florians Beispiel eine Spitzenidee, vielleicht auch bei dem Schmierestehen vor der Bank möglich. Bei der Bürodurchsuchung oder bei Christofs Beispielen einen Beitrag über mir empfände ich dieses Verfahren als Spieler allerdings als überdimensioniert. Für die meisten Szenen mit Zeitlimit wäre eine pauschale Obergrenze an Zügen, ohne sich um die exakte Dauer jedes einzelnen Zugs zu kümmern, ausreichend. Denke ich.

Darauf wollte ich hinaus:

1) Was technisch die optimale Lösung ist, hängt extrem von der jeweiligen Szene ab.

2) Die Erzeugung des entsprechenden Zeitgefühls beim Spieler, die wichtigste Sache also an zeitabhängigen Szenen, hängt überwiegend am Text, nicht an der Technik.

Das gälte auch für den Kurzweil-Index. Es ist sicher nicht einfach, das zu implementieren, klar. Ob er letztendlich funktioniert, hängt aber davon ab, ob du die entsprechenden zeitlichen Differenzen für die unterschiedlichen Züge dem Spieler tatsächlich im Text vermitteln kannst.

Und nun könnt ihr mit der technischen Diskussion fortfahren.

Florian:

Vielleicht müsste man zwischen zwei Timer-Funktionen trennen: Vermittlung von Struktur und Spannung. (Spannung erfordert wiederum die Möglichkeit des Scheiterns.) Und ist Simulation eine dritte Funktion?

Spannung - klar. Was genau meinst du mit "Struktur"? Dass es gut für den Spielfluß ist? Dass es eine saubere Einteilung des Spiels in Szenen geradezu erzwingt?

Simulation - ja, ist meiner Meinung nach aber eher das "wie mache ich das" als das "wozu mache ich das".

ChrisW:

Florian:

Vielleicht müsste man zwischen zwei Timer-Funktionen trennen: Vermittlung von Struktur und Spannung. (Spannung erfordert wiederum die Möglichkeit des Scheiterns.) Und ist Simulation eine dritte Funktion?

Spannung - klar. Was genau meinst du mit "Struktur"? Dass es gut für den Spielfluß ist? Dass es eine saubere Einteilung des Spiels in Szenen geradezu erzwingt?

Ja, die Einteilung des Spiels, wie in Anchorhead. Ein Beispiel: Mein Krimi-Spiel umfasst einen Vormittag, Nachmittag und Abend. Sobald vormittags der Tatort untersucht und der Hauptzeuge befragt sind, bekommt der Assistent des Spieler-Kommissars Hunger, und es ist Zeit, ein Restaurant oder eine Pommesbude aufzusuchen. Am Nachmittag wird dann weiter ermittelt: Erst jetzt öffnet der Nachtwächter zur Befragung seine Tür, da er vormittags noch geschlafen hat, und erst nachmittags kann man in der Gerichtsmedizin den Befund abholen. Der wichtigste Zeuge aber ist beruflich unterwegs und wird erst abends angetroffen. (Eine Reihe von Dingen kann man aber zu einem beliebigen Zeitpunkt erledigen, bspw. Recherche der Akten.)

In dem Fall tritt meiner Ansicht nach die Zeit an die Stelle von Gegenständen, um das Spiel zu strukturieren: Normalerweise benötigt man einen Schlüssel für die Tür oder ein Goldstück für den Troll, um neue Bereiche der Karte zu öffnen, hier öffnen sie sich nur zu bestimmten Zeitpunkten. Der Rätselcharakter ist nicht mehr, an bestimmte Gegenstände heranzukommen, sondern, zur richtigen Zeit am richtigen Ort zu sein (wozu das Spiel natürlich Hinweise geben sollte, wie bei jedem guten Rätsel).

ChrisW:

Simulation - ja, ist meiner Meinung nach aber eher das "wie mache ich das" als das "wozu mache ich das".

Ich möchte mich da korrigieren: Simulation ist eigentlich auch genau eine Struktur wie eben beschrieben. Ist ja egal, ob man den Zeugen nur nachmittags erreicht oder Oberst von Gatow um 11:13 am Gartenhäuschen abpassen muss - das Prinzip ist das gleiche.

Die Unterscheidung "wie" und "wozu" trifft es schon, aber ich würde betonen, dass das "wie" keine reine Äußerlichkeit ist. Anchorhead spielt sich anders als Deadline (ich würde sagen großzügiger, problemloser, weil man nicht so genau sein muss), während der alte Mann in den Höhlen von Karn zeitunabhängig herumwandert, und die Schätze bleiben, wo sie sind.

Viele Grüße,

Florian

Kris:

Ein weiterer Vorteil ist, dass bei unausgeführter Aktion, z.B. weil das angesprochene Objekt nicht im Raum ist, die Zeit nicht weiterläuft, obwohl turns (die Züge) um eins erhöht werden.

Hierzu ist mir noch eine wichtige Sache eingefallen:

Wenn man zeitabhängige Rätsel implementiert hat, die einen engen Zeitrahmen abstecken mit Timer-Funktion, dann wird der Timer trotzdem weiterlaufen, auch wenn mit der Zeit in der Statuszeile nichts passiert. Das verwirrt natürlich den Spieler.

Man müßte dann den Timer unter Berücksichtigung der Spiel-Echtzeit manipulieren.

Gruß

Christof

Kris:

Man müßte dann den Timer unter Berücksichtigung der Spiel-Echtzeit manipulieren.

Mit anderen Worten: Wenn man denn den Timer in der Statusanzeige will, muss die kleinste angezeigt Zeiteinheit auch die kleinste simulierte Zeiteinheit sein?

ChrisW:

Mit anderen Worten: Wenn man denn den Timer in der Statusanzeige will, muss die kleinste angezeigt Zeiteinheit auch die kleinste simulierte Zeiteinheit sein?

Ich denke ja, sonst verwirrt es den Spieler nur.

Ich dachte da an einen Trick:

Wenn man den Timer in Sekunden Startet, also sagen wir 90 für 1 1/2 Minuten, dann würde dem Timer pro Zug ja eine Sekunde abgezogen. Die restlichen Sekunden müßte man dann anhand der Aktion (z.B. etwas aufheben = 10 Sekunden) noch abziehen (Die Formel wäre dann: Timer = Timer - (Aktionszeit -1).

Das funktioniert momentan nur in meinem Kopf, ich werde es mal ausprobieren und berichten, kann aber ein paar Tage dauern.

Grüße

Christof

Kris:

Das funktioniert momentan nur in meinem Kopf, ich werde es mal ausprobieren und berichten, kann aber ein paar Tage dauern.

... so, ging doch schneller als erwartet, ich bitte aber wieder um Entschuldigung, dass ich im TAG-Forum mit Inform aufwarte:

Es wird noch eine Global actime eingeführt. In der weiter oben erwähnten Funktion Seconds wird dieser die Sekunden einer Aktion zugeordnet:

   actime = s;

   

   sec = sec + actime;

   

   if (sec >= 60) {the_time = the_time + (sec/60); sec = sec - (sec/60)*60;} ! Sekunden addieren und nullen

];```

(übrigens funktioniert das nicht, wenn man anstelle von s gleich actime einsetzt, dann bleibt der Wert nur in der Formel gespeichert. Das war mir auch neu, ich dachte, man könne auch so einer Global einen Wert zuordnen.)

Das Objekt bekommt noch einen Daemon:

```Object Baum "Baum" Spielplatz

  with dekl Genitiv_s,

       description "Der Baum wackelt bedrohlich im Wind",

       name 'baum',

       daemon [;

            self.time_left = self.time_left - (actime -1);

             if (self.time_left <= 0){

              self.time_left = 0;

              StopDaemon(self);}

              ],

       time_left,

       time_out "Der Baum ist umgefallen.",

   has male static;```

Der Daemon bewirkt, dass die Aktionszeit dem Timer abgezogen wird, sollte time_left kleiner/gleich 0 sein, wird sie genullt und der Daemon angehalten.

Das einzige was man machen muß, ist zum Timer auch noch den Daemon zu starten, in diesem Fall mit 200 Sekunden:

```    StartTimer(Baum,200);

    StartDaemon(Baum);```

Es funktioniert im Reagenzglas, ich weiß aber nicht, welche Nebenwirkungen in einem Spiel auftauchen können. Ich halte das ganze auch nicht für allzu sauber, da ich nicht Zeit simuliere, sondern ich simuliere eine Simulation von Zeit.

Wirklich sauber wäre es, wenn jeder Zug eine Sekunde wäre und bei einer Aktion von 10 Sekunden wirklich 10 Züge vergehen würden. Das wäre dann das, was ChrisW meinte:

**ChrisW:**
> Mit anderen Worten: Wenn man denn den Timer in der Statusanzeige will, muss die kleinste angezeigt Zeiteinheit auch die kleinste simulierte Zeiteinheit sein?

Für ein Spiel, dass mit Zeit arbeitet (z.B. ein Tag auf einem Boot das ein Leck hat) in dem das eine oder andere zeitabhängige Rätsel implementiert ist, könnte man es aber damit mal versuchen.

Gruß

Christof

...sec = sec - (sec/60)*60; ...

Entspricht sec = sec%60;

Mit dem Prozentzeichen kriegt man jeweils den Rest einer Division durch den angegebenen Wert.

Das Objekt würde ich ausschließlich mit einem Daemon ausstatten. Der wird auch jeden Zug einmal aufgerufen, dort kannst du die vergangene Zeit in Sekunden einfach so einer lokalen Variable des jeweiligen Objekts abziehen, für die zusätzliche Verwendung eines Timers gibts in deinem Beispiel eigentlich keinen Grund.

Zitat:

Es funktioniert im Reagenzglas, ich weiß aber nicht, welche Nebenwirkungen in einem Spiel auftauchen können. Ich halte das ganze auch nicht für allzu sauber, da ich nicht Zeit simuliere, sondern ich simuliere eine Simulation von Zeit.

Unsauber wirkt es deshalb, weil du die Zeit gleich zweimal simulierst: Per Daemon und per Timer.

Zitat:

Wirklich sauber wäre es, wenn jeder Zug eine Sekunde wäre und bei einer Aktion von 10 Sekunden wirklich 10 Züge vergehen würden. Das wäre dann das, was ChrisW meinte:

ChrisW:

Mit anderen Worten: Wenn man denn den Timer in der Statusanzeige will, muss die kleinste angezeigte Zeiteinheit auch die kleinste simulierte Zeiteinheit sein?

Das meinte ich eigentlich nicht. Die jeweils vergangene Zeit muss nicht zwingend mit den Spielzügen zusammenhängen. Was du in der Statusleiste anzeigst, hat mit den Spielzügen ebenfalls erstmal nichts zu tun.

Wenn du allerdings in der Statusleiste eine Zeitanzeige implementierst, dann sollte ein Zug, der (im Gegensatz zu Metabefehlen, zum Beispiel) Zeit verbraucht auch eine Änderung in der Statuszeile bewirken. Damit der Spieler Züge, die Zeit verbrauchen unterscheiden kann von Zügen, die ihn keine Zeit gekostet haben.

Eine Aktion ist und bleibt ein Spielzug. Fertig. Daran würde ich auch nicht drehen.

ChrisW:

Entspricht sec = sec%60;

Danke, wieder was gelernt :-)

ChrisW:

Der wird auch jeden Zug einmal aufgerufen, dort kannst du die vergangene Zeit in Sekunden einfach so einer lokalen Variable des jeweiligen Objekts abziehen, für die zusätzliche Verwendung eines Timers gibts in deinem Beispiel eigentlich keinen Grund.

Die lokale Variable behält ihren Wert doch aber nur für die Lebensdauer der Funktion (oder doch nicht?) . D.h. bei jedem Aufruf vom Daemon würde sie neu initialisiert werden.

Den Timer braucht man allerdings nicht starten, könnte aber die Properties time_left (um den übrige Zeit zu speichern) und time_out (um die auszuführende Aktion abzulegen, wobei man das auch im Daemon selbst ablegen könnte) verwenden, um sie vom Daemon aus anzusprechen. Dann spart man sich auch das Abziehen des einen Zuges der dem Timer abgezogen wird. Da habe ich um zu viele Ecken gedacht.

Gruß

Christof

Ja, ich meinte schon sowas wie time_left und time_out.