Multiplayer, best method?

[TheBlindG]

Hello!

I am struggling to understand which networking method is best for my type of game. In short, the game is like an advanced tic tac toe game, with ranking system. I think dedicated servers is best for this, but I'm abit lost, kinda new to networking!

I want a system like Hearthstone, where you search for an opponent, and if you win, you get rank points.

Thanks in advance

Best, Marcus

 

[The-any-Key]

I would suggest create the game server in nodejs to handle the game and lobby and run it on a linux vc.
Use a webserver with a sql database for the player name and rank system.

 

[TheBlindG]

I would suggest create the game server in nodejs to handle the game and lobby and run it on a linux vc.
Use a webserver with a sql database for the player name and rank system.

So a dedicated server hosted on a linux vc?

 

[andev]

I'm abit lost, kinda new to networking!

If you are new to networking, I advise you to not start your big idea now.

I am struggling to understand which networking method is best for my type of game

Try them all and learn how they work. Then you will truly know which method is best and will be ready to take this project on

 

[TheBlindG]

If you are new to networking, I advise you to not start your big idea now.


Try them all and learn how they work. Then you will truly know which method is best and will be ready to take this project on

Yeah, I am going to make small projects to test this out, tho, my "big project" is quite a small game, but the hard part is the matchmaking I know I want it, so I decided to tackle it early.

 

[MishMash]

Even though it may not be as fast, In general, I recommend using GM as a server for the actual game lobbies. The reason for this is that when you implement server-sided behaviour, it is far easier to do so within the context of GM. For example, if your game involves using GM physics, or GM datastructures which get passed around between the server and the client, this is all far far easier to do if the server and the client environment share the core code base. (These things are possible using a separate server, but that basically means writing lots of functions again inside the server).

A JS server however is ideal for something that is disjoint from the gameplay, such as the matchmaking server. Players would all connect first to the JS server, and that would forward them either some form of server list, or if you wanted to offer a quickjoin feature, a specific game to connect to.

Generally, a dedicated server is better, as it means all clients are treated the same. There are lots of ways to organise your networking code, so it is best just to start with something simple. Regardless of how it is done, the best way to think of a multiplayer game is that the server stores the one true state of the game, and clients simply act as a window into that game state, displaying it from their perspective. The client actions are like inputs to the server, much in the same way that keyboard inputs are inputs in the game state. You shouldn't really do much on the client side, unless you know what you are doing (to avoid desync and hacking potential). The client side should however contain the visual aspects, and any subsequent animations that happen as the result of an event. You will get better at programming in this style as time goes on, though generally you need to have your code structured into better layers than you might conventionally have.

For your game, given it is a simple tic-tac-toe game, a global JS server could manage all players and all games simultaneously, as it is quite basic. The information above was applying more to a larger GM game. A JS dedicated server in this case could quite comfortably handle 100s of simultaneous players and lots of simultaneous matches.

In terms of how you make a server like this, it boils down to a couple of components:
- General connection system which keeps track of players currently connected, and some amount of information about them. Including the "state" they are in.
- The state they are in would determine the following:
CONNECTED: has connected to the server
SEARCHING: Player has sent a request saying they are now searching for a match
IN_GAME: The player is in a match

- The server would maintain a list of active matches, and the players who are searching for a game. A simple matchmaker will simply check if there are more than 2 people searching for a game, if so, it'll remove them from the list and create a new match, changing both of the players state (and sending an update to the players as they do so). The match controller would then take over and broadcast updates to the 2 relevant players playing that game, equally whilst handling their interactions.

- When the match ends, the players get lobbed back into the CONNECTED state, and the server would tell them so.

- For permanent stats, login and rank, the server would need to have a login system and a new state LOGGING_IN, to verify the player has connected to the server, but is not verified. This will need to link to some back-end database. or some form of file system for permanent storage when the players are not connected. If you were to implement this in GM, it could be a simple case of creating an ini file per player, storing their stats.

 

[TheBlindG]

Even though it may not be as fast, In general, I recommend using GM as a server for the actual game lobbies. The reason for this is that when you implement server-sided behaviour, it is far easier to do so within the context of GM. For example, if your game involves using GM physics, or GM datastructures which get passed around between the server and the client, this is all far far easier to do if the server and the client environment share the core code base. (These things are possible using a separate server, but that basically means writing lots of functions again inside the server).

A JS server however is ideal for something that is disjoint from the gameplay, such as the matchmaking server. Players would all connect first to the JS server, and that would forward them either some form of server list, or if you wanted to offer a quickjoin feature, a specific game to connect to.

Generally, a dedicated server is better, as it means all clients are treated the same. There are lots of ways to organise your networking code, so it is best just to start with something simple. Regardless of how it is done, the best way to think of a multiplayer game is that the server stores the one true state of the game, and clients simply act as a window into that game state, displaying it from their perspective. The client actions are like inputs to the server, much in the same way that keyboard inputs are inputs in the game state. You shouldn't really do much on the client side, unless you know what you are doing (to avoid desync and hacking potential). The client side should however contain the visual aspects, and any subsequent animations that happen as the result of an event. You will get better at programming in this style as time goes on, though generally you need to have your code structured into better layers than you might conventionally have.

For your game, given it is a simple tic-tac-toe game, a global JS server could manage all players and all games simultaneously, as it is quite basic. The information above was applying more to a larger GM game. A JS dedicated server in this case could quite comfortably handle 100s of simultaneous players and lots of simultaneous matches.

In terms of how you make a server like this, it boils down to a couple of components:
- General connection system which keeps track of players currently connected, and some amount of information about them. Including the "state" they are in.
- The state they are in would determine the following:
CONNECTED: has connected to the server
SEARCHING: Player has sent a request saying they are now searching for a match
IN_GAME: The player is in a match

- The server would maintain a list of active matches, and the players who are searching for a game. A simple matchmaker will simply check if there are more than 2 people searching for a game, if so, it'll remove them from the list and create a new match, changing both of the players state (and sending an update to the players as they do so). The match controller would then take over and broadcast updates to the 2 relevant players playing that game, equally whilst handling their interactions.

- When the match ends, the players get lobbed back into the CONNECTED state, and the server would tell them so.

- For permanent stats, login and rank, the server would need to have a login system and a new state LOGGING_IN, to verify the player has connected to the server, but is not verified. This will need to link to some back-end database. or some form of file system for permanent storage when the players are not connected. If you were to implement this in GM, it could be a simple case of creating an ini file per player, storing their stats.

Wow, thanks alot for this detailed information! I will start with just a server i host myself and 2 clients that can connect locally and go form there. I want a singleplayer mode and ultimately, the rankexd multiplayer, but if I feel that itll too hard currently, when I don't have much experioence with netcoding. I might just stick with some simple host and play.

But if I get this right, I should have the client be able to play the isngleplayer game and store the "progress" locally, like their decks (it is like tic tac toe but with some deck building). And then use the server to handle multiplayer and send their decks to the server and the server creates the deck in game for them?

P.S. Sorry for spelling errors, if any, visually impaired here! Tried my best ot get everyrhing correct xD

 

[MishMash]

Wow, thanks alot for this detailed information! I will start with just a server i host myself and 2 clients that can connect locally and go form there. I want a singleplayer mode and ultimately, the rankexd multiplayer, but if I feel that itll too hard currently, when I don't have much experioence with netcoding. I might just stick with some simple host and play.

But if I get this right, I should have the client be able to play the isngleplayer game and store the "progress" locally, like their decks (it is like tic tac toe but with some deck building). And then use the server to handle multiplayer and send their decks to the server and the server creates the deck in game for them?

P.S. Sorry for spelling errors, if any, visually impaired here! Tried my best ot get everyrhing correct xD

If you care about security and being protected from hacking, then for a game like this, even single-player progress/matches would need to happen via multiplayer. I haven't played hearthstone, but i imagine if it does have a single player training mode which allows you to gain progress, that AI is still likely running on their servers. This is simply done for game integrity. Deck management and other things are all stored and rewarded on the server side. As otherwise, a client could simply use a program like cheat engine, or even just modify the files to get whatever they want.

However, for the time being, given that you want to start simple, then yes, doing this is fine if you just want to get the functionality working ! It is best to start simple and work your way up as networking can be difficult to organise unless you have done it before. It will take time to develop an alternative way of structuring your projects and even organising interactions between the server and the client without practise. So yeah, start small, and work your way up. Eventually, knowing how to handle these systems will come more easily.

The top comment about it being invalid to design them locally is only true if there are unlocks/progression, or restrictions on deck structure. If the player has access to all the cards from the get go, and there are no rules/limits for the deck, then it is fine for the client just to send the deck over and for the server to accept it. If there are limitations on structure, you can get the server to run a validation function (For example if you are only allowed 3 of one particular card), the server could then report back that your deck is invalid, which would require the player to go back in.
For these sorts of things, validation is normally done both on the client side and the server side. The client side is to stop the client accidentally making something incorrect in the first place, the server side is to prevent that affecting subsequent actions. (Naturally, the only way it could therefore be wrong on the client is if someone had externally tampered with it)

Again, not a huge need for you to worry about that now, but its good to start thinking about security early on, and equally, just to get into good habits as fast as possible. Sometimes I see people who have been working on multiplayer games for years and they still have bad habits. It took me a while to break my own, especially when it came to allowing the client too much freedom

 

[TheBlindG]

If you care about security and being protected from hacking, then for a game like this, even single-player progress/matches would need to happen via multiplayer. I haven't played hearthstone, but i imagine if it does have a single player training mode which allows you to gain progress, that AI is still likely running on their servers. This is simply done for game integrity. Deck management and other things are all stored and rewarded on the server side. As otherwise, a client could simply use a program like cheat engine, or even just modify the files to get whatever they want.

However, for the time being, given that you want to start simple, then yes, doing this is fine if you just want to get the functionality working ! It is best to start simple and work your way up as networking can be difficult to organise unless you have done it before. It will take time to develop an alternative way of structuring your projects and even organising interactions between the server and the client without practise. So yeah, start small, and work your way up. Eventually, knowing how to handle these systems will come more easily.

The top comment about it being invalid to design them locally is only true if there are unlocks/progression, or restrictions on deck structure. If the player has access to all the cards from the get go, and there are no rules/limits for the deck, then it is fine for the client just to send the deck over and for the server to accept it. If there are limitations on structure, you can get the server to run a validation function (For example if you are only allowed 3 of one particular card), the server could then report back that your deck is invalid, which would require the player to go back in.
For these sorts of things, validation is normally done both on the client side and the server side. The client side is to stop the client accidentally making something incorrect in the first place, the server side is to prevent that affecting subsequent actions. (Naturally, the only way it could therefore be wrong on the client is if someone had externally tampered with it)

Again, not a huge need for you to worry about that now, but its good to start thinking about security early on, and equally, just to get into good habits as fast as possible. Sometimes I see people who have been working on multiplayer games for years and they still have bad habits. It took me a while to break my own, especially when it came to allowing the client too much freedom

Once again, big thanks! I'm starting to develop my first test server/client structure today! You've helped alot!