Some thoughts:

• You mentioned GW is essentially a matchmaker. Would we want to link those games to a particular matchmaker queue? In that case we might include a queue id in the request. Maybe it's not such a big deal because GW is also a mod, so games will always be played on the GW featured mod right? Is there a particular logic for including the featured mod in the request message, or just future proofing?
• Maybe send map file path instead of map version. That would allow more flexibility with playing on maps that are not in the vault such as map generator maps. Plus I think the server already just uses the file paths everywhere.
• One issue we have in the protocol right now is that we are inconsistent about how we serialize factions. Sometimes it's by number, but we've been trying to move towards strings instead. I'm actually not convinced one way or the other, but it's something to think about.

• file path instead of map version: Agreed, I'd like to move to generated maps anyway.
• factions: Agreed, a more expressive protocol is better
• Matchmaker queue: We can do that. What would be the benefits? I don't know enough about the queue logic. The most critical issue I see with GW matchmaking is, that people start other non-GW games (ladder, custom) and then the matchmaking fails. Can we prevent that using matchmaker queues?

The main reason we have the game to queue association right now is so that we can look up a player's last few matches in that queue and make sure they don't get the same map twice in a row. But I imagine there are lots of useful statistics you can extract about the matchmaker if you know how many games are being generated by the queues. For GW this same thing could probably be achieved just by looking at the featured mod, but maybe it would be nicer to just have everything use the same system instead of writing special cases for GW.

The lobby server is able to prevent people from joining games while they're in queue and vice versa. However, that's because it knows when you join a queue and keeps track of that state internally. If the GW matchmaking is happening outside of the lobby server, then we might need to add some communication for when a player starts/stops searching. I'm not sure how that would even look. Like do you go to the GW tab and click "Join" somewhere?

I'm not sure how that would even look. Like do you go to the GW tab and click "Join" somewhere?

This is an open question for now. From a client perspective that makes most sense to avoid unintentional/forbidden user actions.

I'll add the field.

Your issue in the gw-backend repo mentions some more parameters:

• Additional mods or build restrictions
• Player's selected reinforcements

I think the additional mods should be OK since I would want the game_launch command to be able to support those anyways for other matchmakers. Probably same with build restrictions. But reinforcements are gw specific so I don't think they would be a good fit for this message. Those would have to be communicated to the client through the gw server.

Fine for me. Shared stuff goes into the lobby protocol, gw-specific stuff needs to be handled elsewhere.

I read through some of the rabbitmq tutorials in the docs and it looks like AMQP already has support for a correlation_id in the message properties, so I don’t think we need to reimplement this with the requestId field in our message. See the section on correlation id here:
https://www.rabbitmq.com/tutorials/tutorial-six-python.html

I think I'd prefer snake case keys for consistency. So far our other rabbitmq messages as well as other server messages all use snake case keys. The only weird thing is that our routing keys use camel case.

And the API is all camel case. We won't reach consistency across FAF. :( But I'll never understand the desire to add additional useless characters anyway.

I think we also want a game_name field as well for the game title.