Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change proposal for adding backfill, lobby based matchmaking support to Open Match #1149

Closed
sawagh opened this issue Mar 6, 2020 · 3 comments
Assignees
Labels
area/feature enhancement New feature or request tsc-discuss Issues that need to be discussed in the Open Match TSC or Community Meeting

Comments

@sawagh
Copy link
Contributor

sawagh commented Mar 6, 2020

Open Match's recommended matchmaking model (Match Functions generating complete matches) does not naturally lend itself well to backfill, lobby based matchmaking scenarios. Issue #1148 covers providing guidelines to implementing this scenario using existing constructs provided by Open Match.

However, based on TSC discussions, looks like the existing concepts may fall short of providing an efficient mechanism for implementing backfill, lobby based matchmaking at scale.

Please use this proposal to address the following:

  • Provide details of why the current recommendation for implementing these scenarios using Open Match is not sufficient. Additional context of scale may be useful (is this OK for some users but only has issues beyond a certain scale? or for certain scenarios?)
  • Propose changes to Open Match that can help support these scenarios natively as opposed to constructing them using existing concepts.
@sawagh sawagh added enhancement New feature or request tsc-discuss Issues that need to be discussed in the Open Match TSC or Community Meeting labels Mar 6, 2020
@sawagh sawagh added this to the v0.10.0 milestone Mar 6, 2020
@sawagh
Copy link
Contributor Author

sawagh commented Mar 19, 2020

Given we are a week away from v0.10 and we dont yet have a proposal, the implementation here wont make it to v0.10 - hence pushing this out to v1.0

Per the discussions around v0.10 planning, we prefer (as much as possible) to not break the v0.10 API going forward - so we should strongly consider making the proto / API changes here either additive - or backward compatible. The client written on v0.10 that does not need this enhancement should preferably not need to change.

Also, for v1.0, we should discuss in TSC, a process for marking new unstable APIs / changes. That way, even if we introduce this in v1.0, we should be able to communicate that this is a relatively new change and may not be as stable as the other API surface (giving us room to break it even post v1.0)

@sawagh sawagh modified the milestones: v0.10.0, v1.0.0 Mar 19, 2020
@calebatwd
Copy link
Collaborator

Update: We're still in discovery on this. We'll try and get that into the open :)

@Laremere
Copy link

Moving backfill discussions to a new issue:
#1240

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/feature enhancement New feature or request tsc-discuss Issues that need to be discussed in the Open Match TSC or Community Meeting
Projects
None yet
Development

No branches or pull requests

3 participants