1

The system should match players to game rooms. When the room is ready it moves to a game server.

  1. Each game start request can have a list of prefered game servers and
  2. specifies exactly game mode (deathmatch, 5vs5, ...);
  3. a game mode can have min/max player count settings and timer (e.g. waits 30 sec for 10 players or for 5 players next 60 sec);
  4. there is a "friends deathmatch" mode - players get matched with their friends.

I think about different approaches.

  1. Have a list of all the matching requests and iterate it each time new item gets added or when any item signals timeout. But there could be too many waiting users (especially because of "friends deathmatch" mode) to iterate the whole list.

  2. Or have a list of rooms. New requests either get matched to any exisiting room or create a new one.

    a) the system can keep a user simultanously in multiple rooms (for features like prefered game servers and "friends deathmatch" mode) and remove him from all the rooms when any of his rooms starts;

    b) or is it better to determinate exactly one room for user preliminary?

I think I need to have each matching option as a seperate class and then combine them to avoid Dictionary<Dictionary<.., List<... nightmare but Im still not sure how to do it exactly.

Now I'm trying to implement 2-a in such way:

I make all matching rooms to derive from

public abstract class MatchingRoomBase
{
    /// <summary>
    /// Performs matching and returns Room if completed, otherwise register the request in the internal list
    /// </summary>
    /// <returns>Completed room with game mode, users, teams and bots specified</returns>
    [CanBeNull]
    public abstract Room RegisterAndTryMatch(MatchingRequest request);

    /// <summary>
    /// Removes the request from the internal list
    /// </summary>
    public abstract void TryUnregister(MatchingRequest request);


    /// <summary>
    /// Creates a clone of internal room structure but without any requests registered
    /// </summary>
    /// <remarks>This is usable for friends deathmatch mode when each friend can dynamically create a matching room (with its correct structure)</remarks>
    public abstract MatchingRoomBase CloneEmpty();
}

Then I can have intermediate rooms like decorators (e.g. GameModeDecorator should forward calls only for specific game mode requests) and "multi room" nodes (e.g. ServerSplitNode should call RegisterAndTryMatch on each of room in the internal list [of requested prefered servers] until any returns not null result). A user can be added to multiple rooms simultanously but when he gets matched the system should invoke TryUnregister to remove him from the whole hierarchy.

But where do timers go? Should I have additional Update method on MatchingRoomBase which "finalizes" all timed-out rooms? [I would prefer to avoid events here because they lead to frequent dynamic adding/removing subscriptions (with CloneEmpty) which can affect performance.] But what if one user gets registered in two rooms and both timeout at the same Update pass?

Or what approach can be used?

  • This might be more appropriate over on gamedev.stackexchange.com. They probably have quite a few questions about how to do matchmaking well. – Ixrec Mar 23 '15 at 22:48
  • @Ixrec The question is related to programming, not gamedesign. I'm not asking what matchmaking algorithms to use but how to implement the specified. – Vlad Mar 23 '15 at 22:53
  • I believe gamedev.stackexchange.com is just as much about concrete algorithms and implementation details as it is nebulous game design principles, but yes this question should be on-topic at either site. – Ixrec Mar 23 '15 at 23:05
  • 1
    I'm voting to close as "unclear what you're asking." Please provide more details behind the different approaches in order to make the question more constructive. I believe the question is fundamentally on-topic for Programmers, but you need to provide additional information on how you are evaluating potential algorithms and what aspects you are prioritizing over others. I'll happily rescind my close vote once those details are provided. – GlenH7 Mar 24 '15 at 0:57
  • 1
    @GlenH7 I added more details on 2-a implementation because I think it's the most suitable here. – Vlad Mar 24 '15 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.