Understanding Timer-based movement (it seems bad?)

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    AFAIK timer-based movement only affects:
    (1) clickteams built-in non-physical movements (bouncing ball movement etc.)
    (2) animation speed of active objects

    Does it affect anything else?

    and it does (2) by skipping frames? So (in case of framedrops) you are essentially trading animation slowdowns for choppiness?
    Which is fine and comes down to personal preferences I guess,
    However, this seems to break the event Current frame of Active object = N ("Compare current frame of Active object to a value") wich may not activate in case of dropped frames/poor performance. Is this a known sideeffect or is it a bug? If it's known I find it weird that it isn't made more clearer, it took me a while to understand why my game was skipping events when stresstesting the framerate.
    To compare:

    Timer-based movment ON
    Pros:
    *Perceieved fluidity in animation and (built-in) movements.
    *"allows you to define the frame rate of the movements and animations independently from the frame rate of the application" -CF 2.5 help doc

    Cons:
    *breaks certain events (in case of dropped frames)

    Timer-based movement OFF
    Pros:
    *No skipped frames in animation
    *Movement and animation speed tied to framerate

    Cons:
    ?

    I'd say that all the pros (for both ON and OFF) are debatable and could be argued as cons depending on what you'd prefer. All pros would also only be applicable when frames are dropped/application slows down.

    All-in-all pretty weak pro arguments for using timer-based movements imho, since most advanced users will use their own custom movements anyway and you should strive for never having any dropped frames but, in the case of this happening it would still be preferable for the game to stutter than for game logic to break. I realise that this option might be geared towards beginners but considering the severity of the con I find it weird that this is the default setting. I guess it also might not matter if you are not using any events concerning animation frames.

    To conclude, my game (hopefully) never drops frames and is always running at 60fps, is there any point in using Timer-based movement? What are the cons of not using it/anything I'm missing?

    Hi,

    Not sure this is answering your question, but I'm using "timer-based movements OFF" on certain active objects because I'm using logic based custom time-scale to create on-demand time-slow effects without changing the frame rate. Also, I'm working with very high frame rates for perf debugging purposes which are therefore extremely volatile. It's only affecting "visual effects" whose animation frames are not tied to game logic, so it doesn't have much impact other than animation speed consistency (I think). Everything tied to game logic, as you suggest should be handled differently, I think.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login