Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Unity 2022.2 is now available as the latest Tech release.
    Dismiss Notice
  3. We are making some changes to the DOTS forums.
    Dismiss Notice
  4. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Feedback Quick Join is rubbish

Discussion in 'Lobby' started by spinaljack, Aug 15, 2022.

  1. spinaljack

    spinaljack

    Joined:
    Mar 18, 2010
    Posts:
    946
    So a couple things I don't like about quick join:

    1. You're limited to 1 call per 10 seconds for what is basically a lobby query which has a higher rate limit
    2. If there are no matches to join it doesn't automatically make one
    3. If it fails to join a match it doesn't automatically try and join the next one and if you want to try again better be ready to wait 10 seconds

    You can make your own, better quick join system using normal query / join / create calls and without the rate limits.
     
  2. veleek_unity

    veleek_unity

    Ben Randall Unity Technologies

    Joined:
    Aug 25, 2021
    Posts:
    36
    Hey spinaljack, Thanks for the feedback, definitely a bunch of reasonable things to think about. Since there's lots of text below, I just wanted to throw out here that you can reach out to me in the Unity Discord channel as well (Veleek#3000) if you have any other questions or follow ups based on the following.

    1. Yes, the limit for this is rather low. We're looking into adjusting this and we're planning on making a change in the next few weeks. See below, for a more in-depth discussion about the what and why below.
    2. This was an explicit design decision made by the team. As part of a create call, there's a whole bunch of extra metadata that you need to provide and in many cases this data isn't available if the client is quick joining and it doesn't make sense to require them to specify things like "Max Players" or "Lobby Name" if they're not going to be used if they QuickJoin. We considered adding an optional "Create if no match found" flag to the QuickJoin request and allow the caller to specify all this data as part of the QuickJoin request, but determined that it was easier for the developer to implement the flow on their side to either automatically call Create if quick join fails or redirect the user to a UI to create a match otherwise. If we continue to get feedback that this is a scenario that developers want to be handled automatically we could consider doing so (and may do so just by wrapping the API in the client SDK instead of adding something on the service side).
    3. I'm not sure exactly what problem you're referring to here. Quick Join should, essentially, find a whole bunch of lobbies that match and attempt to join them one at a time until one succeeds (or it times out). You may be running into a specific edge case that we're not handling, but if you can provide more detail we're happy to dig into it. Also, the rate limit changes we're looking into should help out with this even in the cases where you're failing unexpectedly.


    Okay, so now just a bunch of extra talk about the what and why for QuickJoin:

    Originally we used to internally retry in the Lobby service where it would spin for 10 seconds repeatedly searching for and attempting to join rooms, so it made more sense to limit the number of calls to once per 10 seconds to avoid concurrent requests. This has since been change to only 1 second mostly because we think that if we don't succeed within 1 second, we're probably not going to succeed later and we don't want to make the client wait around needlessly.

    QuickJoin has different rate limits that Query and Join combined because it actually ends up being a bit more computationally difficult to implement internally. However it has a few major benefits that you don't get by implementing it on your own:
    * It's less expensive for you as the game developer because you don't have to pay for the large query response body each time as well as each subsequent join attempt.
    * In a game with a large population using Quick Join, you're more likely to succeed because you won't be continually attempting to join rooms that already filled up in the time between when you queried for rooms and submitted a join request.
    * We're in the process of making some optimizations that should make it more consistently successful, and faster using some specific patterns for accessing the database that you can't do externally (or would result in FAR too many requests to be useful).

    Hope that all makes sense and I'm happy to help troubleshoot anything further
     
  3. veleek_unity

    veleek_unity

    Ben Randall Unity Technologies

    Joined:
    Aug 25, 2021
    Posts:
    36
    A rate limit change has been pushed to update the limits from 1 request / 10 s => 6 requests / 60 s. This will make it easier for you to debug in the short term while not changing the rate limits. We are still in the process of evaluating some the performance improvements and we will likely make further changes to improve the rate limiting when that's complete.