Hi I am trying to build a realtime multiplayer game using node.js and socket.io.
嗨,我正在尝试使用node.js和socket.io构建实时多人游戏。
Now, implementing itself in terms of coding won't be so much of a problem, but coming from a traditional http request-response web programming model, I have no idea how expensive this would be in terms of traffic and server load. Basically during a game, a player's browser should track realtime mouse input events and keep broadcasting them to all other players in the same game.
现在,在编码方面实现自身不会是一个问题,但是来自传统的http请求 - 响应Web编程模型,我不知道这在流量和服务器负载方面会有多昂贵。基本上在游戏过程中,玩家的浏览器应该跟踪实时鼠标输入事件并继续将它们广播到同一游戏中的所有其他玩家。
Here's an example, let's say my avatar follows around my mouse pointer on the screen, and it should be broadcasted to rest of the players on the screen in realtime. I would do something like:
这是一个例子,假设我的化身跟随我的鼠标指针在屏幕上,它应该实时广播到屏幕上的其余玩家。我会做的事情如下:
// client side
$(document).on("mousemove", function(event){
io.emit("coordinate", {x: event.pageX, y: event.pageY});
});
and on the server:
并在服务器上:
// server side
io.sockets.on("connection", function(socket){
...
socket.on("coordinate", function(coordinate){
socket.get("username", function(err, username){
socket.broadcast.emit("move", {username: username, coordinate:coordinate});
});
});
...
});
I think this should work, but this requires the browser emitting several events per second to the server, which subsequently should broadcast them to rest of the players in the same game, and I am worried about the implication of this. One thing though is that the size of each fragment of data being transmitted is not that large (basically it's just an x and y coordinate). If this is too expensive, no matter how great this game is, I don't think I can ship it. Could anyone enlighten me? Thank you.
我认为这应该有效,但这需要浏览器每秒向服务器发送几个事件,随后应该将它们广播给同一游戏中的其他玩家,我担心这个含义。但有一点是传输的每个数据片段的大小不是那么大(基本上它只是一个x和y坐标)。如果这太贵了,无论这场比赛有多棒,我都不认为我能发货。谁能开导我?谢谢。
[EDIT] To clarify, I am not asking about how to make this architecture more efficient. I just want to know if this type of system is realistic enough in terms of system load (and maintenance cost) For ordinary web services I can just estimate the cost by looking at page view numbers but websocket is an entirely new field I am not aware of, so I wanted to ask.
[编辑]为了澄清,我不是在问如何提高这种架构的效率。我只是想知道这种类型的系统在系统负载(和维护成本)方面是否足够现实对于普通的Web服务我只能通过查看页面视图数来估算成本,但websocket是一个全新的领域,我不知道的,所以我想问。
5 个解决方案
#1
5
Caveat: all the numbers below are estimated and there are overheads in a good few places but should give you somewhere to start.
警告:下面的所有数字都是估计的,并且在好几个地方都有开销,但是应该给你一些起点。
If all you're doing is pushing data back and forth between connections then it seems unlikely the server will be your bottleneck. I think you'll hit your first wall with bandwidth (at the player end and/or the data centre end).
如果您所做的只是在连接之间来回推送数据,那么服务器似乎不太可能成为您的瓶颈。我想你会用带宽打到你的第一面墙(在播放器端和/或数据中心端)。
Assuming each user is pushing mouse data an average of 25 times per second that means that each one will be downloading players x 25 per second. Assuming each mouse movement message is 100 bytes and there are 20 players that means you're (naively) downloading ~50kb per second, which is quite high but achievable. I say naively because there will be overheads, but with a decent connection it feels achievable.
假设每个用户平均每秒推送鼠标数据25次,这意味着每个用户将每秒下载25个玩家。假设每个鼠标移动消息是100个字节,并且有20个玩家意味着你(天真地)每秒下载~50kb,这是相当高但可实现的。我天真地说,因为会有间接费用,但是有一个不错的连接,感觉是可以实现的。
The download bandwidth is linear with the number of players, so at 100 players it'd be more like 250kb/s at the client end and 22Mb/s at the server end.
下载带宽与播放器数量成线性关系,因此在100个播放器中,它更像是客户端的250kb / s和服务器端的22Mb / s。
If you need more players you'll need to find optimisations, e.g. trimming the messages, data compression, limiting the mouse sampling speed, etc.
如果您需要更多玩家,则需要找到优化,例如修剪消息,数据压缩,限制鼠标采样速度等。
#2
3
The one million dollar question is: I just want to know if this type of system is realistic enough in terms of system load (and maintenance cost). I think this is very relative. Relative to coding, hardware, quantity of users.
一百万美元的问题是:我只是想知道这种类型的系统在系统负载(和维护成本)方面是否足够现实。我认为这是非常相对的。相对于编码,硬件,用户数量。
The suggestion of Leon is good, only track the mouse click and dont track the mouse move. In this kind of game, every strategy to reduce the requests/responses are welcome.
Leon的建议很好,只跟踪鼠标点击并且不跟踪鼠标移动。在这种游戏中,每个减少请求/响应的策略都是受欢迎的。
Answering your question, i said again, it is relative, your startegy (using node.js and websockets) sounds good, and it could work for 1.000 user sumultaneosly, but could not work for 1.000.000, however,the same code, with a better hardware, could work for 1.000, 1.000.000, 1.000.000.000 users, it is a infrastructure question. I think the premisse is be carefully in your code to mantain the system lightwheigt, because if you know your code is good, the problem will be the hardware, bandwith, etc (and you could take care about this later.)
回答你的问题,我再次说,这是相对的,你的startegy(使用node.js和websockets)听起来不错,它可以同时为1.000用户工作,但不能用于1.000.000,但是,相同的代码,与一个更好的硬件,可以为1.000,1.000.000,1.000.000.000用户工作,这是一个基础设施问题。我认为在你的代码中要小心谨慎地维护系统轻量级,因为如果你知道你的代码是好的,那么问题就是硬件,带宽等等(你可以稍后再考虑这个问题。)
#3
1
Are the avatars really going to follow the mouse or are they going to move to locations on a map that are clicked? If the latter then you only need to transmit click locations to the server and the server only needs to broadcast avatar waypoints and travel speed to the clients.
化身真的会跟着鼠标移动还是会移动到点击的地图上的位置?如果是后者,那么您只需要将点击位置传输到服务器,并且服务器只需要向客户端广播化身路点和行进速度。
This still has limitations in terms of how many objects and players need to be managed but the server can collect a 1/10 a second or a 1/4 of a second worth of actions for multiple avatars and objects and share them out as a bundle thereby reducing the network, server, and client load.
这仍然需要管理多少对象和玩家,但是服务器可以为多个化身和对象收集1/10秒或1/4秒的动作并将其作为捆绑共享从而减少网络,服务器和客户端负载。
#4
1
I have done something very similar...
我做了一些非常相似的事情......
All players send data to the server at their own rate (hopefully about 30 frames-per-second) The server collects the data from each player, and sets the new state (player mouse position). The server has a timer running at 30 frames-per-second -- sends a single message to all players with all players mouse positions. It makes the payload larger, but only sends 30 packets per second -- no problem for node or modern browsers.
所有玩家以自己的速度向服务器发送数据(希望大约每秒30帧)服务器从每个玩家收集数据,并设置新状态(玩家鼠标位置)。服务器有一个以每秒30帧的速度运行的计时器 - 向具有所有玩家鼠标位置的所有玩家发送一条消息。它使有效负载更大,但每秒只发送30个数据包 - 节点或现代浏览器没问题。
Good luck with your game!
祝你的游戏好运!
Dan
PS -- Remember, you have to design for speed!
PS - 记住,你必须设计速度!
#5
1
Consider it this way.
以这种方式考虑它。
If you really want to build a massive multiplayer game with real-time updates, then according to the stats here, websockets if your best bet. (socket.io is a convenient library that provides fallbacks, but it should be configured to use websockets primarily.)
如果你真的想要建立一个具有实时更新的大型多人游戏,那么根据这里的统计数据,如果你最好的选择,websockets。 (socket.io是一个提供回退的方便库,但它应该配置为主要使用websockets。)
Richard made some solid estimates. However, there are two additional things you need to consider:
理查德做了一些可靠的估计但是,您还需要考虑另外两件事:
- maximum number of open connections (google for ulimit)
- parallelization (node.js runs on a single thread, and this will perhaps never change in the future; when broadcasting your changes, will an approx. O(n) performance be acceptable for your game?)
最大打开连接数(google for ulimit)
并行化(node.js在单个线程上运行,将来可能永远不会改变;在广播你的更改时,你的游戏可以接受大约O(n)的性能吗?)
#1
5
Caveat: all the numbers below are estimated and there are overheads in a good few places but should give you somewhere to start.
警告:下面的所有数字都是估计的,并且在好几个地方都有开销,但是应该给你一些起点。
If all you're doing is pushing data back and forth between connections then it seems unlikely the server will be your bottleneck. I think you'll hit your first wall with bandwidth (at the player end and/or the data centre end).
如果您所做的只是在连接之间来回推送数据,那么服务器似乎不太可能成为您的瓶颈。我想你会用带宽打到你的第一面墙(在播放器端和/或数据中心端)。
Assuming each user is pushing mouse data an average of 25 times per second that means that each one will be downloading players x 25 per second. Assuming each mouse movement message is 100 bytes and there are 20 players that means you're (naively) downloading ~50kb per second, which is quite high but achievable. I say naively because there will be overheads, but with a decent connection it feels achievable.
假设每个用户平均每秒推送鼠标数据25次,这意味着每个用户将每秒下载25个玩家。假设每个鼠标移动消息是100个字节,并且有20个玩家意味着你(天真地)每秒下载~50kb,这是相当高但可实现的。我天真地说,因为会有间接费用,但是有一个不错的连接,感觉是可以实现的。
The download bandwidth is linear with the number of players, so at 100 players it'd be more like 250kb/s at the client end and 22Mb/s at the server end.
下载带宽与播放器数量成线性关系,因此在100个播放器中,它更像是客户端的250kb / s和服务器端的22Mb / s。
If you need more players you'll need to find optimisations, e.g. trimming the messages, data compression, limiting the mouse sampling speed, etc.
如果您需要更多玩家,则需要找到优化,例如修剪消息,数据压缩,限制鼠标采样速度等。
#2
3
The one million dollar question is: I just want to know if this type of system is realistic enough in terms of system load (and maintenance cost). I think this is very relative. Relative to coding, hardware, quantity of users.
一百万美元的问题是:我只是想知道这种类型的系统在系统负载(和维护成本)方面是否足够现实。我认为这是非常相对的。相对于编码,硬件,用户数量。
The suggestion of Leon is good, only track the mouse click and dont track the mouse move. In this kind of game, every strategy to reduce the requests/responses are welcome.
Leon的建议很好,只跟踪鼠标点击并且不跟踪鼠标移动。在这种游戏中,每个减少请求/响应的策略都是受欢迎的。
Answering your question, i said again, it is relative, your startegy (using node.js and websockets) sounds good, and it could work for 1.000 user sumultaneosly, but could not work for 1.000.000, however,the same code, with a better hardware, could work for 1.000, 1.000.000, 1.000.000.000 users, it is a infrastructure question. I think the premisse is be carefully in your code to mantain the system lightwheigt, because if you know your code is good, the problem will be the hardware, bandwith, etc (and you could take care about this later.)
回答你的问题,我再次说,这是相对的,你的startegy(使用node.js和websockets)听起来不错,它可以同时为1.000用户工作,但不能用于1.000.000,但是,相同的代码,与一个更好的硬件,可以为1.000,1.000.000,1.000.000.000用户工作,这是一个基础设施问题。我认为在你的代码中要小心谨慎地维护系统轻量级,因为如果你知道你的代码是好的,那么问题就是硬件,带宽等等(你可以稍后再考虑这个问题。)
#3
1
Are the avatars really going to follow the mouse or are they going to move to locations on a map that are clicked? If the latter then you only need to transmit click locations to the server and the server only needs to broadcast avatar waypoints and travel speed to the clients.
化身真的会跟着鼠标移动还是会移动到点击的地图上的位置?如果是后者,那么您只需要将点击位置传输到服务器,并且服务器只需要向客户端广播化身路点和行进速度。
This still has limitations in terms of how many objects and players need to be managed but the server can collect a 1/10 a second or a 1/4 of a second worth of actions for multiple avatars and objects and share them out as a bundle thereby reducing the network, server, and client load.
这仍然需要管理多少对象和玩家,但是服务器可以为多个化身和对象收集1/10秒或1/4秒的动作并将其作为捆绑共享从而减少网络,服务器和客户端负载。
#4
1
I have done something very similar...
我做了一些非常相似的事情......
All players send data to the server at their own rate (hopefully about 30 frames-per-second) The server collects the data from each player, and sets the new state (player mouse position). The server has a timer running at 30 frames-per-second -- sends a single message to all players with all players mouse positions. It makes the payload larger, but only sends 30 packets per second -- no problem for node or modern browsers.
所有玩家以自己的速度向服务器发送数据(希望大约每秒30帧)服务器从每个玩家收集数据,并设置新状态(玩家鼠标位置)。服务器有一个以每秒30帧的速度运行的计时器 - 向具有所有玩家鼠标位置的所有玩家发送一条消息。它使有效负载更大,但每秒只发送30个数据包 - 节点或现代浏览器没问题。
Good luck with your game!
祝你的游戏好运!
Dan
PS -- Remember, you have to design for speed!
PS - 记住,你必须设计速度!
#5
1
Consider it this way.
以这种方式考虑它。
If you really want to build a massive multiplayer game with real-time updates, then according to the stats here, websockets if your best bet. (socket.io is a convenient library that provides fallbacks, but it should be configured to use websockets primarily.)
如果你真的想要建立一个具有实时更新的大型多人游戏,那么根据这里的统计数据,如果你最好的选择,websockets。 (socket.io是一个提供回退的方便库,但它应该配置为主要使用websockets。)
Richard made some solid estimates. However, there are two additional things you need to consider:
理查德做了一些可靠的估计但是,您还需要考虑另外两件事:
- maximum number of open connections (google for ulimit)
- parallelization (node.js runs on a single thread, and this will perhaps never change in the future; when broadcasting your changes, will an approx. O(n) performance be acceptable for your game?)
最大打开连接数(google for ulimit)
并行化(node.js在单个线程上运行,将来可能永远不会改变;在广播你的更改时,你的游戏可以接受大约O(n)的性能吗?)