Make 'something' fps independent by using dt is exactly what behaviors (bullet,platform,timers ...) and also 'wait' & and every X seconds do already.

Same system means same problems when crossing the limits.

(is 10 fps not a bit to low ?)

If you want to accurately measure time, use the system expression 'wallclocktime'.

But even then, you are, well, a little bit screwed. Say it runs at 10 fps. Then 1 tick will be one tenth of a second.

Or, comparing recent wallclocktime to previous wallclocktime happens every 1/10 of a second. So the error is a average not accumulating dt.

Still better then an accumulating error each tick, when going lower then 30 fps.

Sorry if sound confusing.

But, in the end. It might be better to optimise the game. So it dont run lower then 25 fps. That is the best solution.

And do you really want to support devices that are not even anymore supported by there manufactures ?

If I use "wait 1 second" but the game runs very slow on a slow device, the wait time will not be adapted to game time. Then it will wait 1 second even if the game runs slow.

Yes, and No. Wait is fps independent until the game reaches the minimum fps. Standard the minimum fps = 30 fps.

You can lower the minimum fps with the system action: system > Set minimum framerate.

But, if you do so, most position based conditions (is overlapping/on collision) will fail. As explained in the manual:

Set minimum framerate

Set the maximum delta-time (dt) value based on a framerate. The default minimum framerate is 30 FPS, meaning the maximum dt is 1 / 30 (= 33ms). If the framerate drops below 30 FPS, dt will still not exceed 1/30. This has the effect of the game going in to slow motion as it drops below the minimum framerate, rather than objects stepping further every frame to keep up the same real-world speed. This helps avoid skipped collisions due to stepping a very large distance every frame.

In general, everywhere you need the fill in a value in seconds or something/second, this is fps independent by nature. Timer behavior needs input in seconds, so it is fps independent, to the explained limits.

Uh no, instance variables are always personal for that instance.

Are the towers turrets and do you use 'on shoot' ?

You want to hoover with the game in pause ?

Set the game in pause ....

When mouse over an object set the timescale for that object to 1 ?

https://www.dropbox.com/s/9lb62efgvdeek ... .capx?dl=0

Why so difficult ?

Upgrade the towers. Including an instance variable for damage done by a bullet. Bullet has instance variable damage.

Right after spawning the bullet set its instance variable to the (up-gradable one) from the tower.

Compare on impact.

You dont want to change the animation for every member of the group every tick, mouse over it or not.

That logic is flawed and a bit slow.

Rather do this:

https://www.dropbox.com/s/v6n920bg2sos1 ... .capx?dl=0

https://www.dropbox.com/s/52m31rdjts0yg ... .capx?dl=0

I suppose the bullet gets destroyed on collision.

Then just ...

'Bullet' On collision with 'Sprite'

'Sprite' pick top

...... 'Sprite' destroy

...... 'Bullet' destroy

In the properties of the 8Direction behavior you change 'set angle' to 'no'. Now that behavior is not controlling the angle no more.

And it is up to you to code the angle. The sprite has actions to do that. 'Set angle' or 'Set angle towards position'. If it has to look in the same direction whole game, set that angle only once, preferable in a 'On start of layout' (system) condition.

One sprite will be the 'base', the others attach to it.

Use imagepoints on the 'base' sprite to mark where the parts sprite will be attached.

To attach, use the pin behavior, or a simple 'set position of part sprite to imagepoint on base sprite' every tick.

For easy creation and simple picking, bring base sprite and sprite parts in a container.

Each instance of a sprite has individual instance variables.

Well, almost every where you would use '.PickedCount" ... An else works nicer.