Game Name bug (?)

Hello!

I've created 2 unity projects
with different names set in
if (!PhotonNetwork.connected)
            PhotonNetwork.Connect("88.198.99.164", 5055, "GameName1");

I launch 2 projects, and player1 appears in the same room with player2.

I thought Room Lists are separated by setting the name of the game :?.

I hope I did well while trying to explain the problem :).

thanks,
Slav

Comments

  • Or should I handle different game names myself?
  • that would be bad and a serious troublemaker if it wouldn't correctly seperate it, very bad actually
  • I don't quite follow - both join GameName1 and you don't expect them to be in the same room?
    Or one joins GameName1 and the other GameName2.. they should then not be in the same room.
  • Are you sure, that for both game-names, which you pass to Connect(), there actually are applications with the according name running on the server, to which you are connecting?
    If you try to connect to gameName1 and there is no such application on the server, then the server will default to application Lite.
    I guess, that both your projects end up in Lite and so they are in the same application and can enter the same room.
  • Oops,
    I had an impression Lite can handle different game names when I use Unity Networking Plugin! :?
  • Lite can handle different game names... :?
  • Kaiserludi
    Kaiserludi admin
    edited September 2011
    gnoblin wrote:
    Oops,
    I had an impression Lite can handle different game names when I use Unity Networking Plugin! :?
    Well, different room-names, yes, but it can also handle them, when not using Unity networking plugin. There would not be much sense in the concept of rooms, if there couldn't be different ones. But for applications: Lite IS an application itself, so you either end up in Lite or you don't, but Lite does not handle applications at all.

    There are applications and you will connect to one, when calling Connect(). In case, that the application, which you have connected to, is Lite or inherits from Lite, you can join a room inside of Lite.

    These are two completely unrelated concepts, first one belonging to Photon, second one to Lite, and they should not be mixed up.

    Best to avoid names like "gameName" at all and talk about appID and about roomID, to not mix these two concepts up.
  • oh.. i see it - finally.. it boils down to:
    1) the param of Connect is the application Id, not the game / room name
    2) to use different rooms with the photon unity plugin you change the game/room name at PhotonNetwork.JoinRoom/CreateRoom
  • Ok...
    What should I do to be able to test 2 different games on the same server with LoadBalancing (Master/Game1/Game2) setup with Unity Networking plugin?

    I am still a bit lost here :oops: .

    thanks,
    Slav
  • gnoblin wrote:
    Ok...
    What should I do to be able to test 2 different games on the same server with LoadBalancing (Master/Game1/Game2) setup with Unity Networking plugin?

    I am still a bit lost here :oops: .

    thanks,
    Slav
    That depends on what you mean with 2 different games:
    a) 2 different applications: set up 2 different applications on the server and pass the one,l you want to connect to with Connect()
    b) 2 different matches of the same application: pass the one, you want to join with JoinRoom()/CreateRoom()
  • Kaiserludi wrote:
    a) 2 different applications: set up 2 different applications on the server and pass the one,l you want to connect to with Connect()

    I think I need this one!
  • As its now me who is puzzled I am seeking clarification here on if Unity Photon Networking actually does what it is meant to do, replicate Unity Networking basics on Photon or not.

    By that I mean that in Unity, the name and rooms are on two different layers of grouping and only the existance of both makes it work out reasonably well (otherwise you get a totally useless flood of room names at worst)

    In Unity Networking, rooms only exist for the Application Name you connected to, the listing will not show rooms created for other applications. As such you can have RoomName1 in App1 as well as in App2 without them colliding or even existing for each other.
    From what I got from this discussion it seems that in Unity Photon Networking, the Room names must be unique independent of the application id or did I missunderstand that?
  • You definitely have misunderstood that.
  • Missunderstood in the sense that Application Name provided in PhotonNetwork.Connect(...) actually generates such a separation which enables different such applications to have the same room name?

    Well I'm actually happy that I'm wrong there as thats definitely favorable for our use case, would otherwise either have needed to expand our logic in various areas :)
  • dreamora wrote:
    Missunderstood in the sense that Application Name provided in PhotonNetwork.Connect(...) actually generates such a separation which enables different such applications to have the same room name?

    Well I'm actually happy that I'm wrong there as thats definitely favorable for our use case, would otherwise either have needed to expand our logic in various areas or modify the unity photon networking and server side given thats possible at all (haven't looked at photon 3 rcs yet only working with the unity photon networking at the time)
    1.:
    Yes, adding custom server code is still possible with Photon 3.

    2.:
    An application does not even know of the rooms, which are open in another one, t goes even further, an application does not even have to use the concept of rooms at all.
    You can think of it as different layers:
    More low-level there is the Photon layer: This is the socket-server, which knows of operations, responses, events, supported datatypes, applciations, etc. but no room-logic at all.
    On top of it more high-level there are applications like Lite, LiteLobby, MMO and your custom applications, if you have set up such.
    The application Lite implements the room-logic. LiteLobby inherits this logic and so can your custom application. MMO, for example does not inherit this room-logic, nor does it reimplement it, so it does not know annything about rooms at all (it uses a different concept an shows an alternative to room-based games).
    Now, if you have you connected to Lite or another application, which inherits from Lite, you can Lite specific high level logic like joining rooms.
    If there are two different applications running on the same Photon server, both providing a room-logic, then you can use the same-room-name in both of them of course, as they do not know each others internal logic like rooms, if you don't explicitly let them communicate with each other.
    But normally you don't want 2 applications, which implement redundant logic.
    It is more like having a solution or workspace and multiple projects in it: You rarely want to add multiple projects, which provide the same fuctionality, to your workspace, but rather split completly different functionalities into different projects. It's similar with applications: it does not make sense, to have 2 instances of Lite running on the same server, but it can make sense, to have two different custom applciations running, which both inherit from Lite, but add different custom functionality to it.
  • dreamora
    dreamora
    edited September 2011
    See and now I'm puzzled again ;)

    We talk about totally different meanings of Application here.
    You talk about Photon Application, which I'm well aware of how they work as I've worked with Photon since the days it was called Neutron Realtime and available to a handfull developers at best cause Neutron didn't serve the realtime needs the project I was on back then had.


    I'm unsure where the mix up comes from though, but if I would have to guess then its potentially related to you not needfully being in deep touch with how Unity Networking works which I was under the impression is being what Unity Photon Networking tries to replicate on Photon as it even offers a converter for Unity Network to Unity Photon Network

    So to be clear here: I talk of the application name we specify in the Unity Photon Network PhotonNetwork.Connect, which in Unity Networking generates a "seperated room list just for this application" and GetRoomList (or its counterpart) in UnityNetwork only will show rooms for the application we ask for. It will not list the rest.
    The corresponding Unity Network function, to be specific, would be RequestHostList (gameTypeName : String) - where gameTypeName specifies the "virtual application" name, the one at least I expect to provide along the PhotonNetwork.Connect call as it does not offer any other capability for such a limitation later on nor does GetRoomList offer me to specify a filter predicate thats server executed (when I do it on the client the point of seperating is gone as any halfway incapable wanna be hacker can read the full unfiltered list then).

    So given that above explanation hopefully shows what I'm talking about and looking for am I right to assume that this is a delta in Unity Photon Networking vs normal Unity Networking or a functionality simply missing?
    To me it seems that this is totally impossible to gain such a behavior as Unity Networking offers it without creating different physical applications on Photons itself which seems like a total overkill when its used with Unity Photon Networking where it basically replaces a master server and NAT punchthrough capability with a full message redirector (the photon server)

    Seems like one of the next things I need to implement is some basic predicate capability into GetRoomList or expand connect to offer me a the possibility to specify the 'gameTypeName' to replica of the master server based room list filtering.


    PS: The current documentation potentially document what Connect does and what not. I'm still on 0.93 as the 1.0 policy server did not work (impossible to get it to verify the security of a unity webplayer) which prevented me from updating my installation to it, unsure if newer versions now have solved the problem again, thats a thing i will look into later today or tomorrow.
  • If I understood this correctly, unity networking applications are like lobbies in Lite lobby?
    Then I think you are right, dreamora: The functionality is currently missing.
    Looks like we should look into this.
  • When calling the PUN CONNECT function you need to specify a unique application ID. Such as "Crashdrive". Lobby/room information is only shared when using the same application ID. You will not be able to se or connect to games if two clients use different application IDs.
    If you are developing 1 game, you'll want to use only 1 application ID ( "Crashdrive").

    PUN implements the "old" Photon lobby/room concept. However, lobbys are not supported currently; a lobby is automatically joined after connecting to the masterserver (networkingpeer line 739). So, PUN doesnt make any real use of lobbys right now.

    If you want to seperate your rooms per gametype (e.g. TeamDeathMatch), either add properties to your rooms and filter your room listing OR change your appID to like Crashdrive_TDM. If we add lobby support you could use CRASHDRIVE as AppID, then TDM as lobby and finally MyRoom as room title.
  • Boris wrote:
    If I understood this correctly, unity networking applications are like lobbies in Lite lobby?
    Then I think you are right, dreamora: The functionality is currently missing.
    Looks like we should look into this.

    *happyness* :)
  • Boris wrote:
    If I understood this correctly, unity networking applications are like lobbies in Lite lobby?
    Then I think you are right, dreamora: The functionality is currently missing.

    It has many similarities to lobbies indeed when it comes to the room / game handling and listing yes.
    Now that information gets me somewhere, also in the context of where I might "cheaply get away expanding it" for the time being

    Thanks Boris


    @Leepo: using distinct AppIDs isn't an option cause our usage makes this impossible, as you can't add "fake applications" at photon runtime just for the sake of "room seperation" yet it would be exactly whats required as the networking will serve a platform, not a game.