Matching type serial matching not working

Options
[Deleted User]
[Deleted User] ✭
in Photon Server
When I use function joinRandomOrCreateRoom function with serial matchmaking mode it first lands me in the same room again then on the second call I get in the new room.

Best Answer

Answers

  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @mohit_mittal,

    Thank you for choosing Photon!

    There is no "joinRandomOrCreateRoom", it's either JoinRandomRoom or JoinOrCreateRoom.
    My guess is that it's JoinRandomRoom since it accepts MatchmakingType.

    In order to help you we need more details:

    - client SDK used and client SDK version
    - server environment: are you connecting to Photon Cloud or to a self-hosted Photon Server?
    - what's the expected behaviour vs. actual behaviour?
    - minimal repro steps
  • [Deleted User]
    [Deleted User] ✭
    edited July 2019
    Options
    Hi @JohnTube Sorry, the function was 'joinRandomRoom'.
    PhotonNetwork.JoinRandomRoom(
    matchmakingParams.Hashtable,
    4,
    MatchmakingMode.SerialMatching,
    TypedLobby.Default,
    null);

    -Photon Unity Networking v1.86
    -server environment - photon cloud
    -I am in a room of 4 people , there exists another room with only one user in it. I call joinrandomroom -> i leave the current room and again join the same one. I again call joinrandomroom -> then i join the room with one user in it. It should have gone to the single user room on the first call itself.
    -repro steps - 1.have a room max capacity set to 4.
    2.make the room full with 4 people.
    3.make a new room with new user.
    4.try making any user from the first room join a random room.
  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @mohit_mittal,

    -repro steps - 1.have a room max capacity set to 4.
    2.make the room full with 4 people.
    3.make a new room with new user.
    4.try making any user from the first room join a random room.
    Make sure to wait sometime between 3 and 4 so that the 2nd room is ready to be joined.
  • [Deleted User]
    [Deleted User] ✭
    edited July 2019
    Options
    @JohnTube

    I tried it, but still happens.
    also note that it happens only for the first time, then calling the joinrandom again the user joins the seconds room as it should.
    According to our QA team it used to work earlier, this issue is replicating in our existing app as well.
  • JohnTube
    JohnTube ✭✭✭✭✭
    edited July 2019
    Options
    Hey @mohit_mittal,

    Could you send us a minimal repro project to developer@photonengine.com?
    Add a reference to this forum discussion in the email if you do.
  • [Deleted User]
    [Deleted User] ✭
    edited October 2019
    Options
    Hi @JohnTube,

    Out of context :Sorry, couldn't follow up on this for quite a while as this bug was sent to our backlog for a while, but now it was picked up again in the current sprint, so I must solve it.

    Tested the same thing on the photons sample scenes on PUN v1.99 and was able to reproduce the same thing in that as well. Reproduction video and build links below
    Video link:https://drive.google.com/file/d/1ALeWm-g4cB0V6wOs4y7Wn94H69tPKs5I/view?usp=sharing
    Build:https://drive.google.com/drive/folders/1X7Z1KqG__htnEO9urpopwp2hupH1PlET?usp=sharing

    So for reproducing it I just changed matchmaking type to 'serial' instead of 'fillroom' in PhotonNetwork.cs 
    
    public static bool JoinRandomRoom()
    {
        return JoinRandomRoom(null, 0, <b class="Bold">MatchmakingMode.SerialMatchmaking</b>, null, null);
    }
    And made a mac build, copied it 5 times and ran 5 clients to test this.
  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @mohit_mittal,

    Thanks for the report and the video.

    I think the behaviour is expected and normal.
    Serial matchmaking distributes players across rooms sequentially one after the other which is what you see in the video with player "testa" (same client build, same nickname but different UserId every time as it gets a GUID from the server).

    I will ask my colleagues @chvetsov and @stefan for confirmation.
  • JohnTube
    JohnTube ✭✭✭✭✭
    edited October 2019
    Options
    I got confirmation from @Stefan

    when the first player leaves the game and tries to join its the first time that 2 games are available (player 5 opened the second game)

    player 1 is matched to the first game in the list
    leaves again, calls join again, is matched to the second game
    we don't store the information in which game the player was before. we can only match player 1 to the first game with the first join call (regardless of serial matchmaking)
    next join call matches to the next available (matching) game and so on
  • JohnTube
    JohnTube ✭✭✭✭✭
    edited October 2019
    Options
    More info from @Stefan (we will probably add it to the documentation):

    the server-side logic is quite simple.
    • FillRoom: always take the first match in the list (oldest game).
    • SerialMatchmaking: take for each join call the next node than for the call before (we have a pointer to the last result and take the next in the list). This is also never per player, we have no list for results we returned to a certain player. If the same player calls join 10 times or it 10 different players call join (once) makes no difference.
  • [Deleted User]
    [Deleted User] ✭
    edited October 2019
    Options
    Hi @JohnTube

    I still do not understand, why 'testa' won't join 'teste' as the mode is serial matchmaking, should not he join 'teste' rather than joining the same room again on the second attempt.

    Also I didn't get this
    SerialMatchmaking: take for each join call the next node than for the call before (we have a pointer to the last result and take the next in the list). This is also never per player, we have no list for results we returned to a certain player. If the same player calls join 10 times or it 10 different players call join (once) makes no difference
  • [Deleted User]
    [Deleted User] ✭
    Options
    Hi @JohnTube

    Now I get it, thanks for clarifying my doubts. Really appreciate it.

Cookies,
anyone?

We use cookies and related technologies to enhance your experience, show you personalised content and analyze performance and traffic on our website. By clicking on the „Accept All“ button you consent to the use of non-functional cookies and the subsequent processing of personal data to optimize our website and services as described in more detail in our Privacy and Cookie Policy.

By clicking on the „Customize or Deny all“ button you can decide otherwise. Clicking on the „Customize“ button will take you to a page where you can configure the usage of non-functional cookies (and related technologies) or deny all of them. You can access these settings at any time and also subsequently deselect cookies at any time in the footer area of our website.

ACCEPT ALL

Cookie Overview

We use the following categories of cookies and related technologies to enhance your experience, show you personalized content, and analyze performance and traffic on our website. We respect your right to privacy and accordingly you can chose to not allow some types of cookies (and related technologies). Click on the different category sliders and change our default settings to manage your cookie settings.

For more information on the specific cookies/related technologies we use and on how we use these, please see section 15 E. of our Privacy and Cookie Policy.

ABSOLUTELY NECESSARY

Authentication cookies we use are required to run our services … Cookies are required: Link

FUNCTIONAL AND MARKETING COOKIES

These cookies collect anonymous data and allow us to optimize our website and user experience. These cookies are listed here:

ANALYTICS

Help us to understand how visitors interact with our services, enables us to analyze and improve our services (also through third party analytics).