Technology choices for Multiplayer RTS game implementation RRS feed

  • Question

  • I'm looking for some advice, suggestions, guidance, ideas ...

    I'm currently building an asynchronous multiplayer (PBM-style) game, but I'm considering modifying it to also be playable as an RTS game.

    I’m looking for some advice on the best strategy (on technology choices) for managing incoming requests and outgoing responses.

    The game can have 1 - 100 simultaneous players in a single game.  In theory, there can be hundreds or thousands of games playing at the same time.

    Player interaction is being managed through commands and event-sourcing.  Each action a player takes creates a command that is processed against the master data, and triggers the creation of events that are used to process each players 'view' of the game data.  Since this needs to happen in real time, the latency needs to be kept as low as possible in order to prevent game lag.  Each single game will have between 5MB and 50MB worth of data.

    My thoughts for an implementation strategy are:

    1. Use Webapi for the service end points (or azure functions if they are sufficiently responsive)
    2. Drop all incoming messages onto a queue for processing, with 1 queue for each active game.
    3. Run azure functions to process the data from each queue (if they are sufficiently responsive)
    4. Use SignalR to push JSON data back to the UWP client with any updated data changes created during the processing of the incoming messages.
    5. Use Azure SQL for storing game data, using 1 database per game.

    Do these technologies sound like the right choices?  Does anybody have any other thoughts on what might be a better solution?


    Wednesday, October 4, 2017 7:58 PM