Web turn based game Architecture. With or without websockets?

Question

I have written a turn based game (Dominoes) using Scala and Akka actors, where a Server manage all the game state and the clients (Players) receive the new state every time one of them plays a card.

I would like to implement a web version for this but I am having hard time figuring out if this kind of schema needs or not using websockets to consume the messages being sent from the Server to all the players. There is no a heavy interaction between server and clients, but it is not clear for me how players will know that its their turn.

I have been reading some material (Reactive Web Applications, Akka and Play documentation and so on), on how to communicate actors. The Game server is a standalone app. Right now, the client app, when starts, connects to the Server using the preStart method:

...    context.system.actorSelection("akka.tcp://[email protected]:47001/user/gamelobby").resolveOne()(10.seconds).onComplete(x => x match {
            case Success(ref: ActorRef) => {
              //sends server message with the name of the player
            }
            case Failure(t) => {
              //fail case
            }
          }) 

On the material I have been reading, it is not clear for me how a client app would connect to the server using websockets. My two main concerns are: It is necessary to use websockets in this scenario? and if its so, how the server and the client will connect?

Answer 1

Websockets might be a good choice here. The alternative is polling which could require a really short polling interval for this situation. You should probably look into a library to help with this e.g. Cometd or Socket.IO. The main challenge with websockets is session management. These libraries also provide some other features that might be useful. Consider this. That should give you a feel for the experience of working with websockets directly. There's some good information in the accepted answer to this question.