- 1-6 players per game - Round based - Only one player can be active at a time - Multiple games happen at the same time - Optimally, non-technical players can spin up their own server to play on (e.g. via Electron app) - Optimally relatively cheap
For communication I was thinking about websockets, but this would limit the amount of parallel connections / games a lot.
I am thankful for every comment mentioning libraries / stacks and why I should consider them.
Supports compression easier, less issues with proxies, multiplexing etc. And have found that they're much more simple to play with!
It's a board game engine and has multiplayer support. There's also boardgame.io which looks hipper (npm), but I didn't see any screenshots of games being played.
Regarding scaling, there's articles about lots of stacks doing 1M websockets on a host; if that's limiting you, you've got a lot of players, so that's a nice problem to have.
But answering your question, the nice thing about turn based is that you don't really need everything to be synced all the time. So it can be really easy on your network just by sending which actions each player took on their turn. Simulation can be all done in each client device.
Just be careful to sync the random seed at the start of the game (and only use the synced random on things that happen the same amount of times on each client. Leave animations and other visual random effects, with a separate random that is not seeded).
Another thing that you need to consider is how are you going to handle reconnects. You have 2 options. You either have a way to query every state of each component, parse it and send it. Or you can have the actions saved and "replay" the game on re-connection. The first option is faster to reconnect but the second option is easier to implement and has the benefit of being able to replay a given game for debug.
With all this info in mind, any kind of messaging system will be enough for your application, especially if you plan on doing this a hobby. I would prioritize something that you are already familiar and its easy to implement. Websocket seems like a good and easy option, and you can easy scale by adding another server if needed in the future, since you don't need every user on the same server, just need every player in a room.
HN Discussion:
- https://hw.leftium.com/#/item/30442072
- Unity + mirror (multiplayer library) for the server client. The library documentation will help with a mental model of a multiplayer game. Export the binary of whatever your target OS will be. I prefer linux. - Unity for the game client. I prefer webGL export for the client so I can host the HTML/JS/WASM like a normal static site. However; you can (also) export windows, Mac desktop apps too. - nginx to host the static site and reverse proxy to the multiplayer - systemctl units for nginx, and the multiplayer binary on some linux OS. I prefer Ubuntu.
For the code; it's all about developing a mental model of what things exist in your system and what interactions those things have with each other.
It being me, there is a CICD system somewhere running tests for pretty much anything.
- React Native frontend
- .Net Core backend
- NGINX webserver, on a bare metal Linux VM of course
- SignalR for web sockets
- Mysql for long term data storage
- Redis for caching
- Mailgun for sending app emails
Did I miss anything?
I have developed several 2d games with it, as a hobby, used a python server for mp, it was very intuitive and understandable. And it is completely free, no ads or restrictions.