Edit: Apparently it is deprecated:
Also there doesn't seem to be a way to detect the user's preferred layout before pressing any keys, that would make printing the instructions hard.
I am using a programmable keyboard that I’ve set up with a Dvorak-based layout. Here: https://configure.ergodox-ez.com/layouts/ENb6/latest/0
Games defaulting to WASD are fine as long as they allow changing the keybindings in the game.
I prefer that games do not try to detect keyboard layout because they’d probably get it wrong anyway.
Can you link to a physics engine that doesn't support variable timestep?
Box2D User Manual > We also don't like the time step to change much. A variable time step produces variable results, which makes it difficult to debug. So don't tie the time step to your frame rate (unless you really, really have to).
https://stackoverflow.com/a/21273467 (Bullet) > maxSubSteps: Should generally stay at one so Bullet interpolates current values on its own. A value of zero implies a variable tick rate, meaning Bullet advances the simulation exactly timeStep seconds instead of interpolating. This feature is buggy and not recommended.
Edit: The archived version of the (404-ing) Bullet Wiki also says "Bullet maintains an internal clock, in order to keep the actual length of ticks constant. This is pivotally important for framerate independence. The third parameter is the size of that internal step."
If a developer has implemented a third-party physics engine, they should refer to that engine's documentation.
If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framerate is too low.
But besides, if you are using a fixed physics engine you should not be using rAF. It's not meant for that. Your comment is just a bit tangential.
Pegging your fixed timestep engine to rAF could have the consequence of dropping frames when you have a large gap between two frames and enough physics frames get called at once that the next rAF window gets missed. If your performance is bounded by the physics simulation, you could potentially trigger a spiral of death and never catch up.
Of course there are ways to mitigate this, but that just further complicates things.
You have the right idea, adding each frame delta to an accumulator and triggering a physics step when reaches the appropriate value, however rAF is not the answer because it can create a potentially infinite frame delta.
It's usually best to not peg your fixed-timestep physics to rAF or at the very least, pause the game entirely when the window isn't focused.
Matter.js's Engine.update() takes a frame delta as an argument and uses Verlet integration  to make things work under the hood. You can optionally calculate a correction factor to be applied each frame in order to smooth out calculations with janky framerates, but if you can maintain constant FPS then it's not an issue.
Unfortunately, rAF() once again becomes a pain because of the lack of proper control over FPS capping, so monitors with higher refresh rates have a larger window for variable frame deltas. I'm hopeful that these shortcomings will eventually be addressed in the spec.
Damn. I just checked this and you're right: https://developer.mozilla.org/en-US/docs/Web/API/window/requ.... Learned something there so thanks for pointing this out.
I'd always believed that callbacks were locked at 60 fps, although I'm not sure why. Clearly this means all my own games will run at the wrong speed on machines with a higher refresh rate, and will probably appear jerky on displays with a lower rate (assuming such still exist).
Could you represent this map using just two components for each point? I don't see how.
To distinguish them from “true 3D” libraries, a name had to be found. 2.5D seemed fitting.
But I can quell that disappointment and say how cool and exciting this is (if your target gameplaying public is the kind of people who hang out on HN; those who haven't seen a terminal aren't going to grok the graphic style).
Its years since I've done a game jam like ludum dare, but I hope some of HN get inspired to enter that kind of thing! Good luck and happy coding!
For the physics, I'm basically colliding against a grid of tiles, so this might be a helpful tutorial to do the same:
The game reminds me of Monument Valley .
Someone farther up linked to Monument Valley , and that has a really pleasant rotating mechanic so that the player can have more than one view of a level / set-piece.
A little wave-collapse  function for automated level building.
I suppose I could go on. This does fall into the trap of "why don't we just ... ?" which I don't like. But I also like to dream a little.