offlineMode and its purpose


I thought I would start this thread to find out what the exact target use case for the offlineMode is or will be in the 1.0 version of the library.

My question yields from my experience working with the 0.93 actively on a project that will uses this library (cause we need a master client anyway) and which uses the offlineMode or was meant to use it. So far usage of the offlineMode yielded in more problems than it solved unhappily. Our application is purely RPC based, no serialization.

My problems with it are different ones, but one of the top problems is the fact that the offlineMode does not even do the basics that one would expect it to do to make any sense being called a network mode like the event handlers not being called (not a single one not even OnJoinedRoom or OnConnectedToPhoton) when in offline mode for example, which reduces its purpose to a questionably low level at the time if its in the end only a "complicated message redirector"


  • Offline mode. Good question.

    I really think this topic is difficult. In my opinion, the offline mode won't work in all cases. Example: If you start your game the moment 2 players are in a room, then this check won't work offline. No matter what callbacks we do.

    So, in some cases, you might want to ignore that mode and work around it.
    If you want to use it, it's a question of how to use and what to expect of the offline mode.

    In our few testcases, the offline mode did what we expected. But that's us.
    It's definitely not finished yet.

    You are missing some events. Do you use more than OnJoinedRoom and OnConnectedToPhoton? Which ones?
    We could trigger each of those when you enable the offline mode, if that helps.
  • At the time its OnPhotonPlayerXX events + OnRoomXX + OnConnectedToPhoton that are in use, with all the appropriate ones being "force called" through code that are along the flow in a position where they would "happen in the future" (the room ones after the join etc commands, the connect related ones after setting offline mode true)

    As you mention that it worked fine for your cases, would you mind sharing what those cases are were? Perhaps I'm thinking in too complex patterns, perhaps not, for me they are relevant cause these events will kick up uScript events for graphs that then are processed which themself often again send events (either master client -> clients or the other way round) and without the events the whole flow naturally breaks down, thats why I struggled over it as the documentation note
    Mike Hergaarden: At M2H we had to rebuild our games several times as game portals usually require you to remove multiplayer modes completely. Furthermore, being able to use the same code for single and multiplayer saves a lot of work on itself.
    implies that the larger part of it works, cause an online game won't do much without the OnXXXX handlers being called to execute the appropriate code.
  • For myself the offline mode already worked perfectly fine indeed: I do not rely on room logic. My only purpose is to reuse the gameplay code (RPCs/Instantiate/OnSerialize) without any nullreffs/errors/overhead. I never relied on reusing the same connection/main menu/room GUI code, which I suspect you do?
    These callbacks have been added to the offline mode LeaveRoom/JoinRoom etc. functions. I hope these callbacks solve most of your problems then?
  • Actually I started on the offline side as the idea was to use that for the local tests and to allow the users to experiment without a internet connection. I should mention that this is not for a game, but a platform where users will use uScript to create logic for the specific purpose and meaning of the platform and as such it would be very favorable if they can test the logic without a loopback to a photon server all the time or a requirement of a internet connection just to test it, but that only works if the offline mode works as a not connected mode for networking and at least widely behaves the same, as I've no intend to replicate a lot of stuff manually and risk to get regression bombed on each update of Photon obviously.

    I basically expected offline mode to be a direct loopback kind of interface with a 1 user - 1 room or lobby environment and seems that that expection is not really meeting with reality - perhaps I expected too much from it as it seemed to be intended as an easy replacement for unity networking users to photon where the same wouldn't cause the slightest problems and correctly fires the callbacks etc independent of if I go to a remote game or "to myself"

    Also it seems to have some strange anomalies too in offline mode that don't seem to plague the online mode (like a similar dreaded viewid not found issue that at times already cost the last nerve on unitys own networking. I so far couldn't track where it exactly comes from as there is only a single view at all and thats a scene one, no allocateviewid or anything at all. at times the issue is there and then without any change gone just to return an hour later)

    And you are right, I heavily rely on the events working correctly, as they trigger uScript events upon which the whole environment bases. No events from photon -> no code execution -> won't work
    So for me it has unhappily major overhead as I've to do the network layers work on notifying me of stuff that happens in response to my requests to the "server". Thats why I'm questioning the use, if offline disables everything aside of network instantiate and rpc and potentially the view serialization, then that might work for some, but other projects that are not as game oriented will not be able to call it "mode" anymore as it has nothing to do with the expected behavior of the networking anymore.

    I for the time kicked out the offline mode and use a photon server loopback to myself instead to avoid the overhead and really troublesome behavior deltas that you get when you start on offline and then go to online mode or rely on both working the widely the same, the code paths to get the events etc flowing correctly just got too complex to maintain for the very tight timeframe I've at hand for the first presentable version, but I'm looking forward to dive into it again afterwards when I have the time to potentially find better solutions to work around the offline mode limitations