Build a prototype using placeholder art assets ; if the concept is good and the game plays well, it'll be easier to find an artist to join you.

Lots of "game ideas" never reach the point of a product release and are aborted during early stages, therefore unless you're already a well-known developer, no one will join an "idea" only on the prospect of possible future commissions.

'Not sure what you are experiencing, but all official examples/tutorials (top-down action shooter, pong) work perfectly for me ; I'm using Chrome and Opera, try using a different browser as you may get better multiplayer support maybe

The good news is that you can rely on behaviours

I believe Ashley said in other related topics that "Every X seconds" is not affected by the framerate, it runs based on real-world time rather than ticks. Therefore I am assuming it must be running on a less accurate timer (system clock, maybe ?), or using a parallel scheduler.

The only flaw in your example, if my analysis is correct, is that you were using a less accurate method (world time) to time a more accurate method (tick based).

I'm pretty sure you should be able to replace "every x seconds" in your example with a Timer behaviour, which would then be tick based, and then get consistent results.

Basically, see "every x seconds" as a way to schedule high-level events, e.g. "every ~20 seconds spawn a new monster", not as something to be used for animation or frame times.

As for "sub tick", I can definitely see cases where that can be useful (usually used for particle effects, etc.) but that's usually very specific and hard to make generic.

I modified the example further, to log the system time every time the dt bar completed a full circle ; the difference between each iteration is less than 0.0001s which is within expected margin given the frame time.

I'd say blame the "every x seconds" ; use it for gameplay stuff where accuracy doesn't matter (e.g. "spawn an enemy every 2 seconds" ; it doesn't really matter if it's 1.9 5 or 2.05), but not for timing behaviours

I think the example is flawed ; it assumes that "every 1.0 seconds" is actually accurate and uses this as reference. I wouldn't rely on "every x seconds" for anything that needs to be accurate, as there's little in the documentation about the scheduling of these triggers.

I modified the capx to just keep the rotate behaviour, and change the dt logic to a simple :

Every tick > set angle to Self.Angle + rotateSpeed * dt

The accumulated dt error is minimal and the behaviour and dt bars overlap perfectly from a visual point of view ; this proves the behaviour logic and dt logic are consistent with each other.

Yeah, what puzzles me if the kind of error you get ; several degrees on just a single rotation, that's just plain weird and would not be explained by floating point error accumulation

What I mentioned before certainly doesn't explain the massive inaccuracy you're getting. You could be getting 90.00000001 instead of 90, but 93 or so, that's just odd

Framerate is also indeed definitely to be considered and could easily explain why things don't appear aligned properly. The animation shows a major error though, I'm still suspicious... I'll check the .capx if I get the chance !

Though I disagree with the following statement : "summing up dt will make it add 1 every second" ; I would correct to "summing up dt will make it add ~1 every second" with "~1" being "approximately 1, i.e. 1.0+epsilon", as inaccuracy will accumulate over time.

Having an automated correcting factor built-in would implicitly mean knowing what the exact value actually is. That's just not possible ; you only get values from sensors and timers to a specific accuracy defined by the limitation of the hardware. And having C2 try to compensate to ensure that we have sum(dt, 0.0, 1.0) = 1.0 would introduce time dilation unrelated to the frame time which would break all consistency in the simulations.

And why over 1 sec ? That's arbitrary, and in a different example we might prefer time consistency over 0.1 sec, or maybe 60 sec, etc. The definition of dt is not to accumulate exactly to 1.0 over 1 sec ; it is to represent the time elapsed since the last frame, and one doesn't guarantee the other.

If you know that after x seconds your value should be 123.456, great, you can have a correction factor for your simulation ; but only you know that.

Plus it's an egg/chicken problem ; assuming you want to enforce that after 1 sec your sum(dt) is indeed 1.0... how do you know that exactly 1.0 sec has elapsed, since your measured timer value is inherently inaccurate as it's limited by its frequency and the encoding of floating point values. Exact floating point values just don't exist in computer science ; and you might be surprised to know that the floating point value "1.0" is NOT actually equal to the exact value "1.0" on many common platforms

I haven't used IE11, but maybe vsync enabled in some browsers and not others ?

This is normal behaviour ; accumulating floating point values will also accumulate errors and encoding inaccuracies and will never give an exact number. Which is why we never test for equality between floating point numbers ; you never have "1.0 + 1.0 = 2.0", you always have "1.0 + 1.0 = 2.0 + epsilon". When using floating point values, always work with ranges and threshold.

If you know the expected result (like in your behaviour), add a manual correcting factor or snapping mechanism for key values.

Also, dt doesn't guarantee proper timing, it guarantees framerate independence. "Proper" timing is a very loose concept that should be considered only in the context of a specific platform, as the timing logic differs widely depending on the hardware.