performence of the evaluator

[keisni]

Hey All!I am trying to use open-match in our new Unreal game project.I read maybe 80% of the source code, and most of them are pretty good.Now I have some questions:
The synchronizer is a definitly a singleton. Is the evaluator also? Are multiple evalutor useful?
If the proposal pool is big, the evaluator must sore all of them. Is this a performence problem? Is map-reduce useful here?
CreateTicket just create random ticket ids. To avoid duplicate tickets for the same player, I modified this code to let ticketId represent playerId, and when inserting into redis, I use SETNX. Is this the right way to solve the problem?

[joeholley]

Sorry no one dropped you an answer here; I don't think there's much attention on this compared to the Slack channel. Quick answers:

• Synchronizer has to be a singleton. Evaluator generally should be too. There are some patterns (completely separate player populations that aren't allowed to play with each other, etc) that could benefit from running different Evaluators concurrently. However, in general, if you aren't 100% sure you understand why it would be advantageous, you shouldn't try to split up your evaluator logic.
• Evaluator performance will generally be a tradeoff in player queue times (slower evaluator, more comprehensive comparisons) versus fewer/lower quality matches (faster evaluator, less comprehensive comparisons). Since this decision must be made by each developer depending on the game, Open Match users are expected to write and tune their own Evaluator.
• PlayerIds as TicketIds is fine as long as it works for your game. Many customers do this. SETNX is also fine.