In the previous platform, I have multiple worker roles running a collection of threads. Each thread is created to monitor and actively handle the interaction between 2+ players. This worked but I had to build in a mechanism to spawn a thread when a new game was started and to handle situations where the thread or the worker role might stop unexpectedly. The engine supports games that span multiple days so being able to load the game state on demand was also important.
I re-worked this to use the ability of the Service Bus to register a session handler in the worker role and to handle each game as a session (
). The advantage over the previous implementation was instead of having a thread per game always active and waiting for messages from players, I now have a mechanism to launch handlers (i.e., threads) as messages were published to the Service Bus. As the hosted games could span days, this was a huge benefit.
The project implements tic-tac-toe to show how a session handler could be used to spawn a game engine for new games and when games are started again after an elapsed period of time.
The persistence was implemented by using Azure Table Storage. This meant that game state only lives on the server so the messages from the clients (re., players) would only consist of the move they made. The result of the move would then be persisted into storage and the result pushed back to the players.