A different approach to timers

Post here your demos and examples with the source files.
Forum rules
Always post the games with a screenshot.
The file must have the ged and data files (complete game source)
Use the forum attachment to post the files.
It is always better to use the first post to put the game files

A different approach to timers

Postby feral » Wed Jul 09, 2008 3:04 am

Attached is a very small demo of my alternative to timers..
Fcount.zip
ged file and data of very simple demo
(4.92 KiB) Downloaded 211 times


why not use timers ?

well they are handy for many things, but unfortunately they can get messed up with game lags.
They depend on REAL time.. not in game time... which means if the game lags, or "windows" decides at a critical moment to do something in the background.. then the timers will be messed with..

This is ok if they are not critical to game play.. for example setting a timer to destroy a "killed" actor after a period of time..

but if your game requires careful timing... for example player only has 2 minutes to get to a safe zone, or player has only 10ms to cross a hot river of lava ... well... then timers can be a problem..

I was going to write a 'function' to solve this, but then thought of a much easier way, one that also has other advantages..

in the attached demo i have created a "actor" variable called fcount. ( short for "frame count")

HOW TO FOR NEW USERS
use the variables button in any script window and add the variable as
name: fcount
as: integer
type: Actor variable

This creates a new variable called fcount for EVERY actor and it can be accessed in the same way as the actors x, y positions or actors 'sprite' width... eg: player.x player.y pl;ayer.width OR player.fcount

what I do then is, on every actor I need a timer for, I add to the draw function
fcount=fcount+1;

This means every frame that is drawn adds one to fcount FOR THAT ACTOR. and only adds it when the frame is drawn.. so it does not depend on real time but actual frame rate of game, if the game lags, the count lags..

in the attached example I have the enemy actor changing direction after every 20 fcounts
fcount=fcount+1
if (fcount>20)
{
xvelocity=-xvelocity;
fcount=0 //reset counter to 0
}

Which means the actor will always change directions at the right place, at the right timing, even if game lags..

NOTE: EACH ACTOR HAS ITS OWN FCOUNT
to show how all actors can then use each others fcounts, the demo example shows the player actor updating the text actor called "time" but doing so in the 'draw actor' of the player

the player also accesses the enemies fcount to move itself 10 pixels each time the enemys count=10..

This means you could for example freeze a enemy for 10 fcounts, and the player could access the enemies fcount to find out when he could be shot at again.. etc that is, any actor can access any other actors timer for whatever purpose and can reset it to 0, jump it forward, etc etc

note: if you want to use it as a Game clock simply divide the frame count by the number of frames your game is running at and you will get a clock that depends on the game and not realtime, so it will not be effected by lag..

in the demo example the player actor updates the text actor with fcount/30 to give a 1 second timer.. (thirty frames a second)

this means ....if a player has 10 seconds (300 fcounts) to cross the lava, he will always get 10 game seconds..

In other words fcount can be used for anything timers do, but easier to set up, and more accurate.

hope that makes sense and is useful to somebody.. if not let me know and I will try to explain better or do a bigger demo

feral

note: if you need more times... just create more variables.. eg: sleeptime.... or holdbreathcount etc
User avatar
feral
 
Posts: 308
Joined: Sun Mar 16, 2008 6:27 am
Score: 47 Give a positive score

Re: A different approach to timers

Postby DST » Wed Jul 09, 2008 9:55 am

Indeed that is helpful. As you said there are only certain things you'd want to use this for, things that will mess up the game if they're off, like a timed event, or a timer that spawns something. With other things, you'd still want timers for the simple reason that you can make several timers and basically, the timer name is a variable.

One note on this, if you are worried about a game not reaching optimum frames, then we wouldn't want to add too much more work to that, what i mean there is that using this count method requires a drawactor script, which will slow the game down even more, so only use it for things that will ruin the game otherwise.
It's easier to be clever than it is to be kind.
http://www.lostsynapse.com
http://www.dstgames.com
User avatar
DST
 
Posts: 1117
Joined: Sun Apr 15, 2007 5:36 pm
Location: 20 minutes into the future
Score: 151 Give a positive score

Re: A different approach to timers

Postby segwego12 » Sun Jul 13, 2008 4:57 pm

You can also put two minutes in milliseconds in the timer

60 + 60 = 120

So

60000 + 60000 = 120000
http://www.freewebs.com/primewaregames/

The Primeware Games website

Projects
Era of Rome: Done
segwego12
 
Posts: 167
Joined: Mon Jul 07, 2008 2:48 am
Location: My Website, please come to my website.
Score: 3 Give a positive score

Re: A different approach to timers

Postby segwego12 » Sun Jul 13, 2008 4:57 pm

segwego12 wrote:You can also put two minutes in milliseconds in the timer

60 + 60 = 120

So

60000 + 60000 = 120000

And also

60000 x 2 = 120000
http://www.freewebs.com/primewaregames/

The Primeware Games website

Projects
Era of Rome: Done
segwego12
 
Posts: 167
Joined: Mon Jul 07, 2008 2:48 am
Location: My Website, please come to my website.
Score: 3 Give a positive score


Return to Game Demos

Who is online

Users browsing this forum: No registered users and 1 guest

cron