I am working on a MMO poker game,
Currently the whole poker gameplay system would be handled by socket.io by calculating datas in database, the socket would listen to the client's emit and hit APIs to the database to calculate the cards' strength, pots, player's turn etc..., everything is being stored to the database after every action from player
However, i dont know if this is the good approach, some suggested me that i could calculate whole things in a socket functions, by collecting necessary datas from database, all actions triggred by players would be directly calculated by socket function and after the end of the game, the socket stores the result of the game to the database (there will be less processes in the database)
What are the pros and cons ? Which one will cause bottleneck ?
Related
I am developing a turn based mobile game which is a question - answer game. Basicly server will send a question to players (there will be two players in a match) then player 1 answers this question after that, player 2 will be answering too the same question in a limited time order. Players could use jokers such as extend the time or change the question. This is the basic logic of my game. So here is my question:
I will be using Node.js and Socket.io for the server side. You know whether a player losts the connection to the server or simply kills the app starts again during in a match, they should be rejoin the same match and they should see what happened in the game when they were not there. How should i store the game state in my server?
My approach:
There will be a Game class that stores every state of the game and manages the countdowns for turns with setInterval method etc. and when the match starts i will create them and store like this:
activeGames[lobbyId] = new Game(player1, player2, lobbyId)
So for example if a player uses a joker i will catch that request inside the socket.io then retrive my class like this:
var yourGame = activeGames[lobbyId]
yourGame.useBonus(player1, bonusType)
So all the status of the game will be stored inside the class. But with this approach if my server dies or restarts etc. all active matches will be dropped. So that is not a good thing. What do you suggest about this problem? How my server should store the active matches?
Ps: Matches will be lasted for 3 minutes. After that i don't need the match history or something like that. So i am not looking for a persistent database solution.
Generally, you would generate a token (preferrably a cryptographically-secure one) for each client. When a client joins for the first time, generate the game data, and associate that data with the token. Then, send that token to the client. When the client reconnects, it can send that token back to the server, which then re-associates the data with the client.
As for server issues, there are many ways to go about things. What I'd do is create a folder called temp or session or something, then store each game in its own temp file. When the server restarts, it checks the temp folder for game files, loads them, then clears their temp files. You can add handlers for unhandledException and unhandledRejection in NodeJS to save currently active games to their own temp files before the server crashes or shuts down.
I use socket on connection event. new players are created and seen, multiplayer array of objects in console, exists. However, not every event is seen properly (for example, 1. newest connections only see them self, while older see everyone on game. 2. I want also to show all players movements , real time. Dont know how node can handle that). For those issues in brackets, do I need to use Mongo DB or index DB to handle all data real time ?
You will need a database in order for your game to work in a distributed way i.e. so you can scale to more than more server / node process. If you are currently storing all connection/player data in memory, then this won't be accessible by other processes.
With regard to newest connections only see them self, while older see everyone on game I'd need to know more about how/where you store these connections.
For the second point, I want also to show all players movements , real time, I'll need more detail on how you are sending these movements from the client to server, & then broadcasting.
i search the "best practice" to create a simple multiplayer browser game. i have choose nodejs for the backend and maybe Phaser for the front. But i have a question about the algorithm.
In each tutorial the server respond after a client event. But a lot of generic article speak about a loop which send world data at regular interval to all client (for example the valve article).
So what is true ? What is the correct procedure ? It depends of the game type ?
For your information i want to do a simple twin stick shooter with a little world where we must survive as long as possible. And i want to do a cooperative game.
Thanks for help.
You need to distinguish between
updates directly affecting your player which are triggered by actions of other players
and updates which are triggered by actions of your player
If you build your app using Node.js, I assume you are going to work with one web socket connect per client.
You can send data over the web socket connection any time in both directions. There is no restriction at all, as long as the amount of data is moderate.
The server actively sending world data in a loop (implemented using setInterval in JavaScript) is definitely a good choice for informing players if they are affected by actions of other players. You can also use the loop to let the server respond to actions of your player.
If you assume the loop always informs the clients in the same order (e.g. client #1, client #2, client #3, client #1,... and so on), you could optimize performance by preferring clients that are active right now, and are doing heavy activity (that is "the server responds after a client event"). Particularly if you have many players in the game, this could improve user experience.
I'm currently creating a very simple Pong game in Java that is supposed to work over a network. I based the network design off a previous chat client-task I made earlier which consists of a server and a client. The clients connected to the server have separate threads waiting for them to send information to the server (clients are limited to 2 in the pong game obviously)
The way I designed the pong game is that all game logics are calculated on the server since it's such simple calculations and the data is saved in a PongData object that consists of 4 ints and one point (2 ints for players y-positions, 2 for the score and 1 point for the balls positions), this is then broadcasted to the 2 clients through a ObjectOutputStream and all the clients do is display it on the screen. Whenever they press a button on the client that is broadcasted through a DataOutputStream to the server.
When I run the game locally with a server and 2 clients it works perfectly but as soon as I run one of the clients on a separate computer it laggs very badly basically making the game unplayable. I'm unsure what the best practice to design games like these are, I've looked around stackoverflow and the internet and sending objects through UDP seems fairly complicated and most of all very unsafe but I'm not sure how to do it better through TCP without getting such a heavy lag.
Some additional information I can give is that the game loop thread carries out all the calculations, broadcasts the information and then sleeps for 10 ms before repeating it again which gives the game a good speed (locally at least).
Flush your streams, and call Socket.setTcpNoDelay(true) when creating the socket.
I am building a massively multiplayer game with Node.js and Socket.io. All players will move around on the same infinite map (think Minecraft). As the player moves I load the tiles that are visible to them. When players move their movement should be sent to all the players that can see them.
My question is; how should I go about structuring my sockets? Having one socket for all players doesn't seem like it would scale. I could shard the world into chunks, but I'm not sure how to manage the chunk boundaries. Since most players won't be able to see each other most of the time I'd prefer that each player's socket only get updates that are relevant to them.
I've read that Socket.io has a concept of "rooms" which are just sockets that get the same messages. Would it be feasible to have a separate room for each connected player to which I would add the socket of any other player who moves nearby? Then each time the player moved I could send a message to that room. How then could I manage when viewers leave or join the room?
Obviously this is a vague question, but I'm just looking for best practice advice. Links to articles on the subject would be appreciated.
This is one of the essential problems in designing MMO servers. Generally you want a socket per client and you implement logic to subscribe a client to a particular region.
Regions are a good way of setting up 'channels' to control data subscription. You could have discrete names for each region and use Socket.io rooms to subscribe players to a region.
After all this is going, things get much easer to handle. So if a player moves in a particular region, all the server has to do is send that 'Player Moved' event to all subscribers of all regions within X meters of the event.