Worker mode question regarding synchronous methods

Post reply
0 favourites
  • 5 posts
From the Asset Store
Zombie Attack Series - Worker Survivor
$3 USD
Stick Survivor drawing for Zombie Attack Series with nice style and colors.
avidgame's avatar
avidgame

  • Hi Ashley,

    There seem to be some SDKs that do not support worker threads, like Photon Cloud's SDK.

    Here are some sample methods: 

    SDK.prototype.isConnected
SDK.prototype.isInLobby
SDK.prototype.isJoinedToRoom
SDK.prototype.isConnectedToGame
SDK.prototype.availableRooms

    These methods are in their SDK.js. The SDK.js is loaded through an external-dom-script dependency. However, there are methods that do not have anything to do with the DOM, which have properties that are only compared or parsed, hence synchronous.

    The issue is that I don't know a way for the domSide.js and instance.js to communicate synchronously. For instance, a condition called Is Connected or an expression called AvailableRooms().

    I could call PostToRuntime() every time the properties inside a method changes and recreate the methods inside the instance.js. However, most of the methods in the SDK are convolutedly hardcoded, there are no specific target where changes can be listened to, it would need an entire rewrite of the SDK, and that's not practical since the SDK will always be rewritten for every new version.

    I managed to workaround some simple SDKs like PlayFab. Although, SDKs or libraries like Photon can't seem to support it.

    Kindly advise. Thank you.

    Tagged:

  • Here is the Photon JS SDK for context, in case you are curious.

  • By far the easiest solution is to load the SDK on the runtime side (i.e. in the web worker). If all the SDK does is use fetch/XHR/WebSockets etc., there's no reason it can't run in a worker: all those features are available in workers too. It may be that the SDK only needs a few minor changes, such as replacing window with self or globalThis, and then it may just work. You should ask the Photon developers about it.

    The issue is that I don't know a way for the domSide.js and instance.js to communicate synchronously.

    It's currently impossible, because when the runtime is hosted in a Web Worker, it has to communicate through postMessage which is fundamentally async. You have to design around it. For example instead of directly accessing the "Is connected" state, post messages when the state changes to update a boolean on the runtime side, which can be accessed synchronously. This can end up being very complicated for more advanced state, and especially so when there is a real-time aspect. In Construct that was the case for both Audio and Multiplayer, and both were extremely challenging to implement in worker mode due to the complexity of async message passing and state management. In comparison, the WebSocket plugin was easy to implement since it just uses the same APIs directly in the worker. So it will be far easier to adjust the SDK to support workers, which from a glance, looks like it may be easy, so I'd suggest trying that first.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You have to design around it. For example instead of directly accessing the "Is connected" state, post messages when the state changes to update a boolean on the runtime side, which can be accessed synchronously. This can end up being very complicated for more advanced state, and especially so when there is a real-time aspect.

    Thank you for the suggestion, I have already implemented it like that on simple SDKs like PlayFab. It updates the properties of the instance.js side whenever there are changes with the properties used by the method from the domside.js. Therefore, allowing me to recreate the SDK's synchronous methods in the instance.js.

    However, my issue is from convoluted SDKs like Photon's where its properties are updated from multiple branching sources. Which I agree what you've said, it is very complicated for more advanced state, which is why I'm asking for advice on how I can solve it in this advanced case. Thank you.

  • By far the easiest solution is to load the SDK on the runtime side (i.e. in the web worker). If all the SDK does is use fetch/XHR/WebSockets etc., there's no reason it can't run in a worker: all those features are available in workers too. It may be that the SDK only needs a few minor changes, such as replacing window with self or globalThis, and then it may just work. You should ask the Photon developers about it.

    I followed your advice, and it seems to be the most practical solution. Thank you!

Post reply
  • 5 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)