Make your own Timer >How To

JamJarRiotJamJarRiot Member Posts: 62
edited November -1 in Working with GS (Mac)
Further to the discussion in the other thread regarding the building of extra Timers, here's a breakdown of a simple method I use. First some theory...
The trick is to use the built-in Time value of Game Salad. 'Time' will begin from the moment the game starts/play is pressed. An on-screen 'Game Controller' (GC) dummy actor is good for this. Two attributes are needed, TimeCount and TimeLimit. I have these as Integers but for fractional Timers (ie half a second) you can use a Real number.

Creation:
To gain easy access to the new Timer from within your project, create TimeCount as a Game.Attribute (Integer). Now create your Game Controller actor (make it wide enough to display Text). Double click your actor to edit it and add an Actor.Attribute called TimeLimit. The value of this attribute should be the number of seconds you'd like to elapse before your new Timer increments, so make it 1.

Now, using the screen shot below;
Create a Rule; When Game.Time (GS's own Timer) is greater than TimeLimit ( 1, remember) then; Increment TimeCount (Your new Timer) by 1 AND then (the clever bit);

Increment Timelimit by 1 also. This leaves the game.Time value constantly chasing the TimeLimit attribute, which is ALWAYS 1 second ahead. You can now trigger any game events at this stage and reset TimeLimit to zero, or change the TimeLimit value to trigger at higher intervals. Much the same as a regular GS Timer. So...

For the sake of barkbark, who wanted a Timer to count to 9 seconds, I've adapted the Timer to do this. Simply add another Rule; make this query the value and if it reaches your required value (in this case, equal to 9 ) then trigger your event and reset TimeCount to zero to start the whole 9 second Timer again. Put a Text Display behaviour in your GC actor and set it to display TimeCount attribute.

image

Further to this, you can branch out and add another attribute (Timer2 ?) and increment that each time TimeCount reaches 9 (or whatever value you desire) and so on.
I've no idea how this compares to a Regular Timer but with the ability to branch out with further TimeCount Timers I would hope that just using a couple of Rules with this technique may be a better option than a bunch of GS Timers, although it may come down to the style of game you have planned.
I'd like to hear from anyone that uses this in comparison to 'real' Timers though so please try it and expand it all you like.

Comments

  • BarkBarkCoBarkBarkCo Member Posts: 1,400
    Thanks jamma! I can already think of a few ways I could use this.

    This has also sparked another idea for a "home-brew" timer...

    Let's say I want my off screen baddie to move into view 30 seconds into the level.

    - Create a self.integer (`self.LocalTimer`) for that actor. //this would be done for each timed event...

    - Change `self.LocalTimer` to `game.time + 30`

    Create a rule that says when `game.time = self.LocalTimer`
    -- Move to X:Y
    // if I wanted this to be a repeating action like a alpha fade in/out, I could Change `(self.LocalTimer` to `game.time + 30)` again, pushing it out for 30 more seconds...

    I guess it just depends whether swapping a bunch of timers for the same number of local attributes and a "change attribute" behavior is lighter on the processor.
  • BarkBarkCoBarkBarkCo Member Posts: 1,400
    I tried my logic compared to a regular timer...the timer won. :-(

    Image and video hosting by TinyPicx10 actors
    Lowest FPS = 58.24

    Image and video hosting by TinyPicx10 actors
    Lowest FPS = 60.09
  • JamJarRiotJamJarRiot Member Posts: 62
    That's a shame. I did think, however, that a SINGLE GS Game.Timer would be as efficient, if not better, than a home-brew Timer. (A top tip is to keep Timers down to a minimum, after all)

    It's what happens beyond a single Timer that interests me, as a game project spreads and you find yourself requiring 5, 10 or perhaps more standard Timers.

    All those different increasing values, incrementing at different times, would drag the processor back a fair amount. With this home-brew Timer you can at least set off various Timers from just ONE Timer, and that's the system Timer anyway.
    It's probably down to how few Rules you can do this in I would guess.
  • BarkBarkCoBarkBarkCo Member Posts: 1,400
    That's a good point. I did my test with a separate local home-brew timer for each of the 10 actors I added to my scene, and the 10 actors with real timers were faster.

    If timer functionality is the same in all actors, I could make one global instance instead of local and it would probably be as fast or faster than using real timers.
Sign In or Register to comment.