0
\$\begingroup\$

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
\$\endgroup\$
  • 3
    \$\begingroup\$ Is it possible? Certainly. Is it feasible? That question is hard to answer, depends on what exactly you are doing. It should not have any limitations for your case and HTML5 canvas (with or without WebGL) has been used for a number of games. But as with most things in software development you will have to try and see. \$\endgroup\$ – UnholySheep Feb 7 '17 at 10:11
  • \$\begingroup\$ Do you plan to deploy your Haskell backend on a server or do you want to run it on the device and have it communicate with the frontend through the loopback interface? \$\endgroup\$ – Philipp Feb 7 '17 at 11:37
  • \$\begingroup\$ The idea is both. With same code you could run bots or multiplayer when the server is hosted or when it runs as a process in your device. \$\endgroup\$ – tonicebrian Feb 7 '17 at 13:44
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ How complex is to have this websocket open? It seems like I have to wrap the web browser and the native server in a native app? How difficult it is? To get the right startup order, to get the web server listen in an unsolicited port, any monitoring on the server from the hosting app.... \$\endgroup\$ – tonicebrian Apr 18 '17 at 14:23
  • \$\begingroup\$ @tonicebrian You don't necessarily need a webbrowser and/or webserver to have a websocket connection (although it makes little sense over a normal socket unless one of them has to be one of these). There are websocket libraries available for many programming languages. For details I would recommend you to ask on stackoverflow with proper information about your technology choices. \$\endgroup\$ – Philipp Apr 18 '17 at 18:43
  • \$\begingroup\$ I know, but if the server is going to be in Haskell and the frontend is going to be HTML5, someone should provide the HTML5 Canvas plus the WebSocket connection, no? \$\endgroup\$ – tonicebrian Apr 18 '17 at 20:25
  • \$\begingroup\$ @tonicebrian This appears to be a new question which you should ask as a new one. \$\endgroup\$ – Philipp Apr 18 '17 at 21:13
  • \$\begingroup\$ it is already in the original question -> So I've thought about an HTML5 Canvas talking to the Haskell core either through REST calls or websockets \$\endgroup\$ – tonicebrian Apr 19 '17 at 11:17
1
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ JRE bundling isn't really an issue any more. launch4j solves that neatly for many of us. \$\endgroup\$ – ashes999 Feb 7 '17 at 18:30

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.