Game stops when new tab is opened

I have a game, where time is critical. You see a puzzle and you have limited time to solve it. You can't even pause the game. But when player opens new tab in the browser - game is automatically freezed.

So player can easily cheat:

1. Open a puzzle,

2. take a print-screen,

3. open new tab (time counter stops),

4. solve a puzzle without time limits,

5. go back to the game,

6. execute his solution.

"Pause on unfocus" is set to "No" but this makes no difference.

This issue occurs only when player open new tab in the same window.

Is it possible not to stop a game when player opens a new tab?

Pause on unfocus is only for the preview.

You could play around with the wallclocktime expression maybe (it should continue to increase it's value no matter what I think)

I've been wondering that, myself. I always thought it was either a security thing or a just an engine limitation.

In the index html file of an exported project:

		// Pause and resume on page becoming visible/invisible
		function onVisibilityChanged() {
			if (document.hidden || document.mozHidden || document.webkitHidden || document.msHidden)
				cr_setSuspended(true);
			else
				cr_setSuspended(false);
		};
[/code:xzqc5vku]

you can edit this ofc

That's very helpful. Thank you.

I want a game to keep running even when the player is not looking (Cookie Clicker style).

I tried to change the HTML like lennaert said but it didn't work.

Any ideas?

The browser engine effectively pauses the game when you switch tab. You really don't want to work around this. It will unnecessarily drain battery on laptop and mobile devices, and freezing the game allows it to go in to low-power idle states.

You can easily check how much time has passed if switching away. Just check the wallclocktime expression in 'On suspend' and 'On resume' (Browser object triggers). So even if the game has frozen because the user switched away, you can still tell how much time they spent, *and* you get to save battery because the game properly froze.

The browser engine effectively pauses the game when you switch tab. You really don't want to work around this. It will unnecessarily drain battery on laptop and mobile devices, and freezing the game allows it to go in to low-power idle states.

You can easily check how much time has passed if switching away. Just check the wallclocktime expression in 'On suspend' and 'On resume' (Browser object triggers). So even if the game has frozen because the user switched away, you can still tell how much time they spent, *and* you get to save battery because the game properly froze.

What about multiplayer? Will I have to resync the whole state every time the user tabs away? Sounds like an enormous pain

I remember seeing somewhere that the FPS would drop to 10 or something, is that no longer the case?

What about multiplayer? Will I have to resync the whole state every time the user tabs away?

No, syncing is transparent and automatic, and there is nothing you can do to affect it anyway, it's all handled by the engine. The host will send all objects at least twice a second regardless of whether they changed. (This uses little bandwidth and is generally not a performance concern, especially compared to changing objects being sent 30 times a second.) If the user tabs away and the game freezes, then they tab back, the peer will get a full-state update from the host within 500ms. It's the same thing that happens for late-joining peers, they'll get the update very soon after joining and everything will appear in its right place. The game freezes but the browser does maintain background connections so the player is not disconnected.

For hosts it's a different matter and I didn't really want to talk about it because it breaks my own rule Since the host is basically the game server and has the authoritative state, switching tab would freeze the entire game for all connected peers. That basically ends the game; if you have 20 people connected, tough, all 20 people freeze. This is pretty bad and would mean casual gaming where people tend to flip tabs a lot would be prone to regular freezing. To avoid this I implemented a hack - for hosts only - where it keeps the tab alive in the background. Yes, this drains battery faster, but it is basically necessary if the tab is acting as a multiplayer game server, and I don't think it's worth ruining the game for everyone just to save a bit of battery in that case. Also it allows dedicated servers to run multiple hosts in different browser tabs. I think that's a special case and the only reason a tab should be kept alive in the background, so it's deliberately not supported for anything else. For all other purposes you should just compare the time that was spent suspended and play catch-up, and not waste battery.

> What about multiplayer? Will I have to resync the whole state every time the user tabs away?

> If the user tabs away and the game freezes, then they tab back, the peer will get a full-state update from the host within 500ms.

That's the general case, when you're allowing the plugin to do everything for you, right? What if I'm transmitting custom state through messages? Do events still run?

Let's say, for example purposes only, that I'm making a coop platformer. When one player reaches the end, a "next-level-load" trigger is fired for all peers. Let's also say, for example purposes, that a level load takes some non-trivial time. If one peer is tabbed away, it won't receive the trigger, thus delaying the game for everyone. Or everyone will load and start the next level while that peer will be stuck loading once it tabs back.

Did I misunderstand? Because if it were simply throttled to 10fps (or even 2fps), as long as logic continued it wouldn't be a problem, since I can always cram the full level loading operations into a single frame (a pretty slow frame, sure, but it won't matter)

The host will definitely keep going and running all events. I think triggers can still fire in background tabs, making it possible to respond to network events even while suspended. Perhaps give it a test and see what happens.