Difference between revisions of "Script Classes for Adventure Games/Timer Class"

From SCI Wiki
Jump to navigationJump to search
Line 124: Line 124:
  
 
<span style="float: left">[[Script Classes for Adventure Games/Script Class|&lt; Previous: The Script Class]]</span>
 
<span style="float: left">[[Script Classes for Adventure Games/Script Class|&lt; Previous: The Script Class]]</span>
<span style="float: right">[[Script Classes for Adventure Games/Feature|Next: Feature &gt;]]</span>
+
<span style="float: right">[[Script Classes for Adventure Games/Feature Class|Next: The Feature Class &gt;]]</span>
  
 
&nbsp;
 
&nbsp;

Revision as of 02:24, 7 December 2015

Official SCI Documentation

Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | Index


The Timer Class

Author: Jeff Stephenson

Date: 5 April 1988

 


The Timer Class

The Timer class implements the concept of an alarm clock, allowing you to create an object which will cue: another object after a certain interval. Timers dispose: of themselves after cue:ing their client, and always check to see if their client is still present before cue:ing it.

An important concept relating to Timers is that of game time versus real time. Real time is just what it sounds like — real time in real seconds. Game time is time adjusted to the performance of the user's computer — it is the same as real time on a computer which is able to keep up with the animation demands of the game, but slows down in proportion to the speed of the user's computer when it is not able to keep up.

An example may help clarify this. Say that you're writing a game in which ego has only five seconds to leave a room before a bomb blows up. If you set this time interval as real time, it may give you just enough time to get out on your nice fast 286 or 386 machine. But on a Tandy 1000, where it takes 1/5th of a second to complete an animation cycle instead of the standard 1/10th of a second, the user will only be able to go half as far and thus has no chance of leaving the room before the bomb blows. The time interval should really have been set in game time, which would have given the user the same number of animation cycles to get out.

As a rule of thumb, time intervals which are meant to be a constraint on how long the user has to do something should be set in game time, whereas time intervals which are just meant to be a delay between two events should be real time. A user with a slow machine has no desire to watch a banner screen twice as long as one with a fast machine.

In file: system.sc
Inherits from: Object
Inherited by: none


Properties

====
client

The object which the Timer will cue: at the end of its interval.


cycleCnt

The number of animation cycles remaining until the Timer cue:s its client. This is used by Timers which are timing either animation cycles or game time.


seconds

The number of seconds remaining until the Timer cue:s its client. This is used by Timers which are timing real time.


lastTime

Private. Used by a timer timing real time.


Methods


set: who nSec [nMin [nHrs]]

Create a timer to cue: who after a specified interval in game time. Set it to cue: in nSec seconds. nMin and nHrs are optional minutes and hours until the cue:.


setReal: who nSec [nMin [nHrs]]

Like set:, but the time interval is in real time.


setCycle: who cycles

Create a timer to cue: who after cycles animation cycles.


delete

Private. Does the actual deletion of a Timer. You should use dispose:, which sets the Timer up for a delete: by the system later on.

 

Notes


 

Table of Contents

 

< Previous: The Script Class Next: The Feature Class >