4 ms·

Open Match: Open source game matchmaker

32 points by Impossible 8y ago

0xFACEFEED 8y ago
Does this system implement an algorithm for determining skill over time or is that up to the user? If an algorithm does exist, how does it compare to TrueSkill[0]? My biggest criticism with matchmaking systems is they're too good. The skill rating is so accurate in such a short amount of time that every match is frustrating and/or boring. [0]: https://www.microsoft.com/en-us/research/project/trueskill-ranking-system/ https://www.microsoft.com/en-us/research/project/trueskill-r...
- deathanatos 8y ago
  > My biggest criticism with matchmaking systems is they're too good. The skill rating is so accurate in such a short amount of time that every match is frustrating and/or boring. I'm confused: wouldn't a boring game (too easy) or a frustrating game (too hard) be indicative of a bad matchmaking? Wouldn't good matchmaking always feel winnable, with a 1/competitors chance of winning? (That is, 50% for two players, 33% for 3, etc.)
  - sieabahlpark 8y ago
    It leads to no variance in play, if you only play with perfectly equal players every match will be more or less than same. Sometimes you need to include an outlier just to keep it from being mundane. Then again you could just add variance to the known game and it becomes u competitive because of chance.
  - kroltan 8y ago
    In theory, yes, but games with no hard time limit being played by equally skilled players can have long periods of counterproductive stalemates.
alexforster 8y ago
"It’s designed to be flexible (run it anywhere Kubernetes runs)" Is this the only supported deployment method? It's interesting if Google is OSS'ing cool projects to increase GCE/GKE marketshare.
- joeholley 8y ago
  It is the only supported deployment method, yes.
wink 8y ago
My naive view as someone standing on the sidelines and watching game companies, this sounds a bit odd. > Matchmaking is a complicated process, and when large player populations are involved, many popular matchmaking approaches touch on significant areas of computer science including graph theory and massively concurrent processing My impression is that a good matchmaking algorithm (especially in ranked ladder play) can make or break a game - so when you finally shipped your game, it's awesome - then the balancing comes. After the balancing... matchmaking can still ruin it, so it seems to be a very delicate process. To cut it short, not the thing you'd want to grab some random code from github (from Google especially, where you never know how long it will be supported... ah well, at least better than Facebook) - we're not talking "I'm taking a webserver battle tested by millions of users" code reuse. So either it's a new problem for you, then you don't need scale. Or you have problems scaling - then you probably already have some matchmaking algorithm you're happy with - so where does this thing come in? Applying some engineering framework approach in making your thing scale? Sounds like a very small niche. Honestly a little confused.
- joeholley 8y ago
  Open Match is not focused on shipping matchmaking algorithms aside from the provided example code, and is mostly unopinionated about what logic the developer runs to form matches. OM primarily aims to handle the code required to make a modern, scalable, highly-available web service so developers can instead focus on writing the matchmaking logic that matters to the game. As you pointed out, matchmaking is typically very snowflake-y and most developers will likely build their own logic and tweak it over time. In the future we expect that many simple matchmaking use cases for popular genres will be addressed by matchmaking functions contributed by the community (and we will contribute some as well as time allows). These will be a great place to start for new games and provide a nice base upon which to tweak and customize for many common game types.
  - wink 8y ago
    Thanks for the explanation, but then the README is just not very helpful. ¯\_(ツ)_/¯

32 points by Impossible 8y ago

Does this system implement an algorithm for determining skill over time or is that up to the user? If an algorithm does exist, how does it compare to TrueSkill[0]? My biggest criticism with matchmaking systems is they're too good. The skill rating is so accurate in such a short amount of time that every match is frustrating and/or boring. [0]: https://www.microsoft.com/en-us/research/project/trueskill-ranking-system/ https://www.microsoft.com/en-us/research/project/trueskill-r...

deathanatos 8y ago
> My biggest criticism with matchmaking systems is they're too good. The skill rating is so accurate in such a short amount of time that every match is frustrating and/or boring. I'm confused: wouldn't a boring game (too easy) or a frustrating game (too hard) be indicative of a bad matchmaking? Wouldn't good matchmaking always feel winnable, with a 1/competitors chance of winning? (That is, 50% for two players, 33% for 3, etc.)
- sieabahlpark 8y ago
  It leads to no variance in play, if you only play with perfectly equal players every match will be more or less than same. Sometimes you need to include an outlier just to keep it from being mundane. Then again you could just add variance to the known game and it becomes u competitive because of chance.
- kroltan 8y ago
  In theory, yes, but games with no hard time limit being played by equally skilled players can have long periods of counterproductive stalemates.

alexforster 8y ago

"It’s designed to be flexible (run it anywhere Kubernetes runs)" Is this the only supported deployment method? It's interesting if Google is OSS'ing cool projects to increase GCE/GKE marketshare.

joeholley 8y ago
It is the only supported deployment method, yes.

wink 8y ago

My naive view as someone standing on the sidelines and watching game companies, this sounds a bit odd. > Matchmaking is a complicated process, and when large player populations are involved, many popular matchmaking approaches touch on significant areas of computer science including graph theory and massively concurrent processing My impression is that a good matchmaking algorithm (especially in ranked ladder play) can make or break a game - so when you finally shipped your game, it's awesome - then the balancing comes. After the balancing... matchmaking can still ruin it, so it seems to be a very delicate process. To cut it short, not the thing you'd want to grab some random code from github (from Google especially, where you never know how long it will be supported... ah well, at least better than Facebook) - we're not talking "I'm taking a webserver battle tested by millions of users" code reuse. So either it's a new problem for you, then you don't need scale. Or you have problems scaling - then you probably already have some matchmaking algorithm you're happy with - so where does this thing come in? Applying some engineering framework approach in making your thing scale? Sounds like a very small niche. Honestly a little confused.

joeholley 8y ago
Open Match is not focused on shipping matchmaking algorithms aside from the provided example code, and is mostly unopinionated about what logic the developer runs to form matches. OM primarily aims to handle the code required to make a modern, scalable, highly-available web service so developers can instead focus on writing the matchmaking logic that matters to the game. As you pointed out, matchmaking is typically very snowflake-y and most developers will likely build their own logic and tweak it over time. In the future we expect that many simple matchmaking use cases for popular genres will be addressed by matchmaking functions contributed by the community (and we will contribute some as well as time allows). These will be a great place to start for new games and provide a nice base upon which to tweak and customize for many common game types.
- wink 8y ago
  Thanks for the explanation, but then the README is just not very helpful. ¯\_(ツ)_/¯