Multiplayer Fails when HOST BROWSER is minimized

0 favourites
  • 7 posts
From the Asset Store
This is a single chapter from the Construct Starter Kit Collection and the Student Workbook from the Workshop.
  • Problem Description

    ____ A concise description of your problem here ____

    The code running the HOST of a MULTIPLAYER GAME is supposed to keep running in the background, even if it's not in the active tab. This is how C2 games worked for at least the last 3 years (from my experience).

    Recently, something changed. Now, if the HOST is not running in the ACTIVE WINDOW, the multiplayer game ceases to communicate position information to synchronize objects. Basically - the multiplayer aspects of the game, halt. This is bad.

    Attach a Capx

    ____ Upload a Capx to this post ____

    I tested this using your standard "MULTIPLAYER GAME" example where you control the little dude who shoots, just to confirm it was not my code. It's not my code. You should test with your standard example.

    Description of Capx

    ____ Concise description of what this CapX does ____

    It's your code. You know what it does.

    Steps to Reproduce Bug

    • Step 1: Run your MULTIPLAYER GAME example. Enter an alias. That's now your host.
    • Step 2: Run another TAB of the same game. I do this by just cloning the tab, running, and entering a new alias. Then, run a THIRD TAB of the same game. Another alias. You now have three little dudes - the host, and two clients. That's all you need to see the problem.
    • Step 3: If you PULL YOUR THREE TABS out so they are separate windows, so you can see them all at the same time. Moving any one of the dudes, causes that dude to move in all three windows. That's how multiplayer works. All good...
    • Step 4: If you OPEN ANOTHER TAB so the host tab is hidden, or minimize the HOST TAB... then, move one of the dudes in a CLIENT... guess what - it does NOT move in the other client. Basically, the data from the client to move and synchronize, halted. That's not good. That is a big limitation of the use of Multiplayer. It means if the person running the host changes to another window, everyone is frozen. It also means, making a host that runs efficiently, sitting the background without graphics, is not possible. Big limitation of C2 as a gaming engine with this new issue.

    Observed Result

    ____ What happens? ____

    Multiplayer stops sychonizing objects, when host tab is not active.

    Expected Result

    ____ What do you expect to happen? ____

    Multiplayer has always synchronized objects when host tab is not active - years and years it worked like that.

    Affected Browsers

    • Chrome: (YES/NO) YES
    • FireFox: (YES/NO) YES
    • Opera: YES

    Operating System and Service Pack

    ____ Your operating system and service pack ____

    Windows 8 and Windows 10 and OS... basically, any OS where Multiplayer currently works.

    Construct 2 Version ID

    ____ Exact version ID of Construct 2 you're using ____

    239 (64 bit) ---- basically, the current stable release.

  • Any update on this bug?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • The BUG is still happening.

    This makes CONSTRUCT 2 a fairly BROKEN PLATFORM for doing multiplayer games.

    The reason is simple - if you make a multiplayer game, and if the user who is running the host instance of the game switches tabs or minimizes their browser, even just for a minute, the game halts during that time.

    Basically, until this is fixed, Multiplayer using C2 is not viable for creating working games in the real world. Or you need to give some major warnings to the person running the host instance. But that's a hack.

    This could make C2 a non viable platform for multiplayer. Hopefully they get it fixed.

  • The problem is Chrome changed, not Construct 2.

    Chrome tries to suspend background tabs to save battery/CPU. For a couple of years we used a hack to force background tabs to wake up if they're a host. It looks like Chrome have clamped down on this and made it more aggressively suspend background tabs, which is causing multiplayer hosts to get suspended.

    There's not much we can do about this - it's the browser that is suspending the game, not C2. I reported the issue to Google here: - it may be worth starring the issue/adding some comments to show it affects you.

  • Thank you for this clarification, I believe all of us have tried as much as possible, and hopefully one day there is a best clue from scirra forum's friend.

  • BTW until this is fixed, I've heard there's a workaround - if a tab is playing audio, it's not suspended. This is a reasonable thing for a game to do, so if you play a quiet music track or something, and set the Audio plugin to play in the background, then it should also keep hosting the game. The multiplayer demos in C2 don't do this, but perhaps your own games can. Hopefully Google will fix this with a better solution soon.

  • Sorry if it is improper to revive an old thread, but I came across this information and felt this was relevant here. ... -download/ ... round_tabs ... x4OlE4/pub

    TLDR; Basically in the event you are running multiple hosts in multiple tabs with the intent of using a client to server style design, you can set a flag to disable background throttling.

    [quote:1nauq8zt]Chrome provides the --disable-background-timer-throttling flag for use cases like running test suites and other user-sanctioned heavy computations.

    We can't normally expect a end user to have this flag on if you are utilizing a peer to peer design though, so the workaround would be to play audio, as previously mentioned.

    Also note that the opt-out option is planned to change via FeaturePolicy in 2017 and be depreciated by 2020 (with suitable replacement), so stay on your toes to update your solutions as needed if you are serving a significant user base.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)