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.
Related
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 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 ?
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 writing some NodeJS an application for some clients (mobile, single page app...). The application is game and quite social - users can have friends and game needs to sharing events between them in realtime. So I decided to use Socket.io.
How to effectively share events between connected sockets of user's friends? One user can be connected with more then one client (so he has more connected sockets).
Is it good idea to use socket.io "rooms" where each user has one room and when some event occurs, it is emited to each room of my friends?
How to effectively handle this?
For better notion you can imagine it the same way as facebook wall (or right panel of friends activity).
How would you handle it?
You could try solving this task with socket.io rooms but i think that would kill your application because of the overhead, for example
1000 users => equals => 1000 rooms ( 1 room for each user )
thats 1000 connection without anyone particularly listening to friend activity.
So the approach above already seems like not scalable.
I would try publish/subscribe pattern which is not very difficult to implement, you can use a micro library or Backbone with .listenTo or even socket.io with Redis pub/sub.
A user would have the option to listen or stop listening to a friend events.
One user would not get a ton of notification for simple friend event.
and the list goes on depending on your application behavior.
Some questions that have interesting information.
What should I be using? Socket.io rooms or Redis pub-sub?
Node.js, Socket.io, Redis pub/sub high volume, low latency difficulties