2
\$\begingroup\$

I want to create a turn base multiplayer game where each player simultaneously takes his/her actions, and ends the turn. Both will see what the other player did afterwards and the next round begins.

Think of it as some kind of chess, but both players take turns at the same time without seeing it until both end their turn.

I though about a server software that creates direct TCP/IP connections to both players and communicates the necessary stuff like what the other player did, who lost/won ect. The usual stuff.

But thinking of TCP/IP port limitations this could mean a limitation of about 65000+ users per server? Meaning 32500 active matches per server?

Then I thought about some kind of dispatcher. Like a REST API server that generates a unique game id and all players call the service with their ID (e,g transferring everything with JSON or some binary data).

I am not quite sure which approach is the better one. Maybe I am wrong at some point? Running a background service for each match seems to be my approach for both solutions (GameManager Class instance creation or a new process gets started communicating via named pipes or localhost). Maybe someone has some experience with this or another great idea? :)

\$\endgroup\$
2
  • \$\begingroup\$ So the question is more focused on how to create a server for a video game, than how to communicate a turn based game with a server? If that's the case, it would be better to re-phrase the title of the question to attract the appropriate people. Also it would be useful to mention what game engine / library you are using, in case you are looking for a solution specific to your case. \$\endgroup\$
    – Tom Tsagkatos
    Sep 25, 2018 at 13:23
  • \$\begingroup\$ The language and stuff doesn't matter to me. I am using Unity now (tried Godot 3 and others) and the server will be written as a console application or ASP.NET or PHP. Depends on the best approach. It's more a question about the approach rather the technology behind it. And the possible limits. \$\endgroup\$
    – DoubleVoid
    Sep 25, 2018 at 13:38

1 Answer 1

Reset to default
4
\$\begingroup\$

First of all, 65000 peak current users is quite a lot. Many games don't even get near that number. Looking at the current player stats on Steam, there are just 7 games which broke that limit today. And if you think you are playing in the same league as CS:GO, DOTA 2 or PUBG, then you should be able to afford more than one gameserver.

But the number of available TCP ports is not a problem for the server anyway. The server only needs one open port per server application which is running on it. The number of simultaneous clients connected to the same server-sided port is unlimited. The 65000 port limit is only relevant for outgoing connections or if you want to run multiple servers on the same host.

Considering that there will be intervals of several seconds where no communication happens between client and server (an eternity for a large-scale client/server application), a REST API seems like a viable approach. You could even suspend the game-state to the database and only get it out after everyone sent their move.

But there is one problem: You might not be able to build your game without any push-events whatsoever. There will be some cases where you want to tell the player something while they are making their moves. For example that the opponent left the game or that all other players made their moves and are waiting for them to finally make up their mind about theirs. Or maybe you want to have chat? Push-events either require to maintain a network connection or that the player acts as a server. Many players might not be able to act as servers, because they are behind a NAT router. So the only solution is to keep the TCP connection with the player alive.

\$\endgroup\$
8
  • \$\begingroup\$ Hey, thanks for the answer. You are right, the REST API would need some kind of pooling for new messages every x seconds. Maybe I need some kind of matchmaking server that checks which one of my VMs is free. The chosen VM then creates a TCP/IP connection with both players. Another aspect is the memory usage I think. Since the GameManager instance is rather small it should be a problem to create a lot of them on one server. +1 for TCP/IP I think + Matchmaking/Dispatcher server. I don't want to pool every 3 seconds for new messages, seems wrong to me. :P \$\endgroup\$
    – DoubleVoid
    Sep 25, 2018 at 13:47
  • \$\begingroup\$ @DoubleVoid It might be wise to build your architecture in a way that you keep the option open to add sharding later. But for now it might be best to just create a monolithic server. Keeping it simple makes development easier. \$\endgroup\$
    – Philipp
    Sep 25, 2018 at 13:55
  • \$\begingroup\$ Yeah right. As of now I am just trying to get simple multiplayer going. Scaling it up will come later. My plan is to create the game logic core (used for Singleplayer with AI and Multiplayer). Then create the monolithic server (I tend to use TCP/IP) and then wrap things up and make it scalable. My boss wants me to implement bluetooth as well (mobile game with "local" multiplayer). Much to do...I will think about it a little more, if nothing else shows up I will mark your answer! Thanks :) \$\endgroup\$
    – DoubleVoid
    Sep 25, 2018 at 14:11
  • \$\begingroup\$ I knew I mixed something up there. Thanks for the info immibis! \$\endgroup\$
    – DoubleVoid
    Sep 26, 2018 at 9:42
  • \$\begingroup\$ @immibis edited. \$\endgroup\$
    – Philipp
    Sep 26, 2018 at 11:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .