Lots of cool stuff here. But on the last point about managing renders, for my money any browser game is in a state of original sin if its logic and render loops are tightly coupled.
The Right Thing To Do is to run logic and rendering at separate cadences, with rendering driven exclusively by requestAnimationFrame. Then when the browser is minimized, RAF stops firing and rendering is skipped entirely (on top of the other benefits of decoupling logic and rendering).
Hi, the game is already doing this. As mentioned in the article, logic tick is running at a much lower frequency than rendering loop (30/60FPS). When playing in the browser and is minimized, the game will simply pause - rendering and logic. Browsers will throttle timers which will cause inaccurate logic tick as well. Most idle gamers actually do not like this behavior [1] - people prefer the game to run in the background as well.
The "background mode" mentioned in the article is about the Steam version, which runs in Electron and I have to set `backgroundThrottle: false` flag. In this case, Electron will not throttle timers and I can safely disable rendering while leave the logic running.
I think idle games are a special case here, in that variable timesteps aren't necessarily a liability for them. In an ideal world, one would like all the systems in an idle game to be able to quickly simulate arbitrary amounts of time (for offline progression etc), and if the whole game is made that way then in principle one is immune to throttling. But I think games actually built that way are pretty few and far between.
Are the logic and the rendering loop in separate threads?
If so, how do you ensure that when the rendering loop reads the shared state, it sees something consistent (i.e. something that hasn't been updated by the logic loop in between the time when the rendering loop started accessing it, and the time when the rendering loop finished accessing it)?
I'd go further: for many games the right thing to do is pause execution entirely if the window is minimised or the user switches to another tab or application. Obviously not possible for online multiplayer games, but a good practice for single player.
Rendering can be but isn't always the most expensive portion of a game's execution, but if you have a lot feeding into that in terms of object updates and game logic you can find yourself chewing a surprising amount of CPU time, and therefore power, which isn't great if the host device is running on batteries.
Please have this setting be configurable if you do this. I hate when games pause when I alt-tab to another window on another screen while I'm waiting for something to finish in a game.
For many games, idle games are a special case though, I don't think anyone who plays an idle game would want the logic loop to pause. They typically take a long time to play so minimizing and checking back every now and then is a very common thing.
The Right Thing To Do is to run logic and rendering at separate cadences, with rendering driven exclusively by requestAnimationFrame. Then when the browser is minimized, RAF stops firing and rendering is skipped entirely (on top of the other benefits of decoupling logic and rendering).