Is it possible to write a game with a HTML5+REST service architecture?

Question

As a side project I'd like to program a board game similar to Twilight Struggle. For this pet project I'd like to satisfy several non functional requirements:

1. The core logic must be written in Haskell
2. If I succeed, I'd like to sell it in platforms like Steam, Google Play and Apple Store.

The Haskell requirement limits me a bit about the range of frameworks to use and the Haskell+SDL2 route doesn't seem very mature when talking about porting to mobile platforms (maybe I'm wrong but I haven't found any easy tutorials on the topic).

So I've thought about an HTML5 Canvas talking to the Haskell core either through REST calls or websockets. The HTML5 canvas will be contained in a Cordova application or similar when in the mobile. What do you think about this approach in terms of:

• feasibility
• robustness
• portability
• software engineering
• whatever other concern you might have

Answer 1

The problem with REST is that it is based on HTTP, which is not a protocol designed for low latencies or minimizing traffic. When you just want to send a few bytes, the HTTP header will generate huge overhead. Keeping a websocket connection open is far better when it comes to overhead (although not as good as "naked" sockets), but they still have the weakness that they are still based on TCP. When you are developing an action-paced game, you should be using UDP.

So if you were writing an action-game, then your approach might not give you satisfying results.

But your game is turn-based. (At least it looks like that. If it has some quick reaction mechanics, disregard this advise). In turn-based games, latency is usually not a problem. Players won't even notice when the move from the other player comes several hundred ms late. They will just assume the opponent needed a bit more time to think about their move. So in this case it is completely appropriate to use a REST-based webservice for communication between client and server.

Although I would still rather consider Websockets, because with REST the server can not notify the clients that something happened unless they ask. There are workarounds for that, but they are quite ugly (like delaying a response until something happens or bombarding the server with several update requests per second). With websockets, the server can push messages to clients whenever it needs to.

Answer 2

The first aspect I would consider is deployment. You need to check into how easy it is to deploy your end product to the platforms you list. As an example, Java is generally considered highly portable (write one, run anywhere!), but anecdotally, figuring out how to bundle up a game executable with a JRE for release on Steam is complex. Keep in mind any third party libraries you might need - if you're using anything that isn't stock, you may find that your base langague & libraries are portable, but get stuck because some game dev related library (sound, UI, graphics, AI, etc) isn't.