[clarle]

Interesting, the app itself is a web app. From the architecture docs:

> The game client is a Backbone.js + Marionette application which runs in the browser.

And for the main game server and matchmaking:

> The Game server is a Socket.io WebSocket server which handles multiplayer games.

> The worker uses Kue to poll Redis-backed queues for tasks like game creation and matchmaking.

[distortionfield]

I settled on a pretty similar stack for a browser based TCG simulator last year. Redis with Go, GraphQL and Vue; its a speedy development stack.

[spoils19]

Very interesting. Like many other forum readers here, I wonder if the game would have seen more success if it was programmed using a commercially available engine, or even manually using C / C++. Despite outcries of the opposite opinion, the technology absolutely influences the effectiveness of the product. (See: Rollercoaster Tycoon and its immense legacy)

[winrid]

I played the game years ago, and I suspected it was web based due to the animations etc appearing to be CSS. However, it never stuttered or was slow.

[chii]

> wonder if the game would have seen more success if it was programmed using a commercially available engine, or even manually using C / C++

i don't see how a technology choice can influence commercial success tbh. It's not like there's performance issues that are fixable in C/C++, nor is there platform issues for porting (like for consoles, which is hard to a javascript stack to achieve).

The main reasons for commercial failure is due to game design, marketing and product/audience fit.

[crummy]

I played the game briefly upon release. I did not suspect it of being web based and to be honest I can't imagine how it would have been different were it to be made using traditional methods. The turn based gameplay seemed well suited to the choice of technology.