I'm building a strategy game, where players can battle each other. As for now, I'm focusing on making 1v1 PvP battles, but I also want to build an architecture, that will allow for further extension by up to 3v3 battles.
The game I create is based on socket Client/Server architecture. Every player, that will enter the game and press the "Find match" button, will be placed in a separate battle against one of the other players.
However, I have so many questions about how to structure the sockets:
Do I need a separate socket ("room socket") for each simultaneous battle?
Who should create and bind the room socket? If it's a client, how the server can connect to this socket if the client's ports are closed? If it's a server, see p. 3
Is it possible to bind all of these sockets to one port? How the client can connect to "his" socket if the addresses and the ports are the same?
When and how to open "room sockets" so that each client will get a corresponding endpoint? How to write it on server-side?
How many sockets do I need for matchmaking queue ("welcome sockets")?
Am I to use multithreaded programming, or it is possible to go without it?
I will be grateful for any help with it
P. S. Since the language I'm writing my server on isn't too prevalent, I can't use any ready solutions
From your question I suspect you could benefit from reviewing the Beej Guide to Network Programming.
- Do I need a separate socket ("room socket") for each simultaneous battle?
I'm not sure what you mean by a "room" socket. If you mean that a different listening socket will be assigned per game, than that wouldn't be practical.
The normal way to go about is to have the server listen on a single socket (address / port) and each client will connect to the server's socket.
This means that the server will have a socket per active client + a listening socket and each client implementation will have a single socket (the connecting socket).
For a 1:1 game, the sockets can be "matched" to a couplet by the server, making that "couplet" into a room.
For a 1:many game you might consider using a pub/sub pattern by implementing "channels" and "subscriptions"... However, since (I'm assuming) a player can only enter a single game at a time, you might consider making an array or linked list of players per game.
- Is it possible to bind all of these sockets to one port? How the client can connect to "his" socket if the addresses and the ports are the same?
Yes, it's possible and this is how servers actually work.
A listening socket behaves slightly different than a connection socket, in the sense that a listening socket can "accept" connections and create a new socket per connection.
- When and how to open "room sockets" so that each client will get a corresponding endpoint? How to write it on server-side?
This is language dependent. Most languages have some kind of variation on the functions listen in the Beej Guide to Network Programming.
Generally a server will call listen and than create new client sockets using accept. A client will call connect and have a single socket.
- How many sockets do I need for matchmaking queue ("welcome sockets")?
For a 1:1 game you will need a single socket "queued" as it waits for the next available connection.
Of course, this might be more complex. If a client has a game requirement (i.e., only players level 10 and up), you might require an ordered list or another data-store to manage the queue.
- Am I to use multithreaded programming, or it is possible to go without it?
You can probably run thousands of games on a single machine with a single thread if you use an evented (non-blocking) design.
This really depends on how much work is performed on the server vs. how much work is performed on the client's computer.