3 ms·
That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receivi
by XCSme 6y ago
That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue.
Imagine having GTA 5 multi-player running in a background window, you would still want to hear the other people, hear the in-game sounds so you can come back to the game if something important happens, and also not have to simulate instantly all the events that you missed when you come back.
This also reminded me that we had problems with just playing a sound when a game started to let the players know they should come back to the tab. Players complained that sometimes the game does not notify them it has started, but it was just Chrome simply not executing JavaScript anymore.
- londons_explore 6y agoI think the Chrome developers are trying to tell you you shouldn't be using your users devices as game servers... How about when a tab is backgrounded, a server continues running the game and just streams an mp3 audio stream to the users device. Most devices can stream audio with the CPU actually turned off.
- XCSme 6y agoThe devices are used as game clients, not game servers. Streaming audio sounds like an interesting idea, so instead of the server sending an event and the client playing a sound when that event is received, the client would constantly stream a dynamically created audio file. This solution could work, feels a bit complex as you would still have to make sure stream catches up if user has a lag spike, instead of buffering the audio (timing should still be accurate). That being said, what it the game is single-player and there is no server? Then the client itself would have to generate the audio stream and stream it to itself, which wouldn't work if the background thread is throttled.
- setr 6y ago>That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue. I would imagine you could do a "catch-up" mode -- execute the simulation at uncapped FPS till the simulation reaches parity, and turn off ui/sounds/etc during it. Actually, if you didn't have such a mode already, I'm not clear on how the simulation would ever be able to catch up (eg most RTS's won't let you rejoin a match due to this)