Latency on a node based massive multiplayer web lightcycle game

490 views
Skip to first unread message

Jos? Moreira

unread,
Jan 8, 2011, 5:06:42 PM1/8/11
to nod...@googlegroups.com
Hello,

i was thinking about what would take to develop a web based tron(tm) light-cycle game, where everybody who connected would play on the same 2D arena and by massive i mean something like a million square points arena or more, a "point" being 1 pixel * line thickess and players would move a point at a time (leaving a trail). I even thought about doing a 3D arena (x,y and z)

The math isn't really complicated and i have a good idea on how it could be done, at least something that would work. Each player would see a viewport (on HTML5 canvas) of the arena, data would be sent to the server and status would be downloaded to update the player's viewport (with other players moves). The server would also check collisions (when a player moved into another players trail and die a horrible virtual death).

The cycles would move on their own like in existing regular games and using the keyboard the player would change direction.

But since i never develop a web based game and implicitly a multiplayer one, i'm wondering about the implications of the latency.

On each game tick, let's say 1s, the player position would be updated (a point would be added to it's trail on a datastore), so to create something fluid, on that second a POST/PUT would have to be sent to the server, status would have to be updated, the response with updated viewport info downloaded, parsed and the canvas updated. And i'm guessing even moving 1s at a time could not be enough to create a fluid experience.

Since there are a lot of node projects with websockets and etc in the node community, can anyone more experienced shed some light (cycles :) on the issue?

Best 





George Miroshnykov

unread,
Jan 8, 2011, 5:32:04 PM1/8/11
to nodejs
Hello José,

I would say that regular HTTP methods won't work well for this kind of
interactive games and you should look into websockets.

As for the general approach to writing client-server games, I would
really recommend reading this article by Valve Software:
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

It's a bit outdated, but it covers lots of things you need to know
about client-server interaction.
Also it's not too technical: it explains concepts rather than throwing
code at you.

Regards,
George

Jos? Moreira

unread,
Jan 8, 2011, 5:35:34 PM1/8/11
to nod...@googlegroups.com
i figured its a job for web sockets/long polling. ill read it thanks

Stephen Belanger

unread,
Jan 8, 2011, 5:47:27 PM1/8/11
to nod...@googlegroups.com
One of the big things mentioned in there is state prediction. It is unreasonable to expect to update the server on positions and such as fast as the display frame rate, so you need to make some assumptions about what the remote clients are doing between updates. For example, if a player is walking forward at a particular speed it is probably safe to assume they will still be walking forward at that speed until the next update. It's unlikely that every player will be able to see each others' screens so it's not so important that states are exactly identical--they just need to be close enough to make it believable.

A neat trick I've seen done in FPS networking is that when a player shoots another player, the hit is calculated but not actually confirmed to the user until the next positioning packet is received from the target player to validate their position. If the position is off the opponent will quickly move to their next location, appearing as though they have dodged the shot when the game actually calculated that it was a hit initially.

On Sat, Jan 8, 2011 at 2:35 PM, Jos? Moreira <matrix...@gmail.com> wrote:
i figured its a job for web sockets/long polling. ill read it thanks

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Jos? Moreira

unread,
Jan 8, 2011, 6:02:24 PM1/8/11
to nod...@googlegroups.com
yes, its what the document refers as client-side prediction. it's all very interesting

Marak Squires

unread,
Jan 8, 2011, 11:24:42 PM1/8/11
to nod...@googlegroups.com
I'm pretty sure tmpvar is working on a solution for some of the problems you are describing. 

Floby

unread,
Jan 9, 2011, 8:17:26 AM1/9/11
to nodejs
I'm currently working on a real-time browser-embedded game (it's a
participation for the Mozilla GameOn challenge). I'm sharing the basic
code both server and client side since it's wirtten in JavaScript. I
also use some kind of state guessing to compensate the latency. I was
planning on releasing this part of the code but it's not optimal yet.
I've been reading a lot of documentation and articles about the Google
Wave protocol and it helped a lot, especially the one a Operational
Transform http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation
. In the end I didn't use this protocol but the concepts were good.

I'm using Socket.IO for the communcation between clients and server.

Thanks for the reading George, I should have looked for this a month
ago!

Jos? Moreira

unread,
Jan 9, 2011, 10:20:14 AM1/9/11
to nod...@googlegroups.com
there's a heavily informational post on HackerNews about the subject here http://news.ycombinator.com/item?id=2084157


Scott Wilson

unread,
Jan 9, 2011, 1:00:46 PM1/9/11
to nodejs
Hi,

I have a project that provides shared state and presence propagation
using operational transform (DMP) and websockets in Node. It uses the
Google Wave Gadget API on the client side:

https://github.com/scottbw/wave-node

This provides a generic framework suitable for developing many simple
multiplayer games. There is a silly nethack-style multiplayer dungeon
exploring demo in the "examples" folder as well as the usual chat and
presence demos.

S


On Jan 9, 1:17 pm, Floby <florent.j...@gmail.com> wrote:
> I'm currently working on a real-time browser-embedded game (it's a
> participation for the Mozilla GameOn challenge). I'm sharing the basic
> code both server and client side since it's wirtten in JavaScript. I
> also use some kind of state guessing to compensate the latency. I was
> planning on releasing this part of the code but it's not optimal yet.
> I've been reading a lot of documentation and articles about the Google
> Wave protocol and it helped a lot, especially the one a Operational
> Transformhttp://www.codecommit.com/blog/java/understanding-and-applying-operat...

Floby

unread,
Jan 10, 2011, 4:58:34 AM1/10/11
to nodejs
HI Scott,
I was very interested at first when I was looking for wave
implementation in node. But; unless it has changed since then, I
didn't quite understand how to manage users and add any hooks server
side with you library. Anyway the wave protocol didn't fit well
eventually.

On Jan 9, 7:00 pm, Scott Wilson <scott.bradley.wil...@gmail.com>
wrote:

Scott Wilson

unread,
Jan 10, 2011, 11:46:59 AM1/10/11
to nodejs
Oh well!

I didn't add any specific server-side hooks as it seems to work nicely
enough just developing the applications client-side and using the Wave
Gadget API.

I can see though having a server-side user management hook would be
useful too depending on how its deployed. At present it just lets the
client register itself. I guess I'm just always wary of adding too
much functionality to a framework...

Floby

unread,
Jan 11, 2011, 6:41:20 AM1/11/11
to nodejs
I understand.
I've always wanted to play around with wave, but Java gives me severe
eye rash. So I'm not erally familiar with the concepts of wave, that's
maybe why I didn't find my way through your module.

On Jan 10, 5:46 pm, Scott Wilson <scott.bradley.wil...@gmail.com>

Michael W

unread,
Jan 11, 2011, 1:03:43 AM1/11/11
to nodejs
(from hackernews)

Armegatron has a little triangle around multiplayer opponents that
describes where their light cycle could be with respect to the moves
they could make until their packets reach you. It's quite interesting;
go grab http://armagetronad.net/screenshots.php and play a network
game to see how it works.
See also: http://wiki.armagetronad.net/index.php?title=Lag

Bobby

unread,
Jan 12, 2011, 2:22:47 PM1/12/11
to nodejs
Here's another good game networking article, from the developers of
Unreal:
http://unreal.epicgames.com/Network.htm

On Jan 8, 5:32 pm, George Miroshnykov <laggy.l...@gmail.com> wrote:
> Hello José,
>
> I would say that regular HTTP methods won't work well for this kind of
> interactive games and you should look into websockets.
>
> As for the general approach to writing client-server games, I would
> really recommend reading this article by Valve Software:http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_...

José Moreira

unread,
Jan 21, 2011, 9:39:29 PM1/21/11
to nod...@googlegroups.com
i used to play this :) my idea is something similar but where you can move in 3D, with everyone on the same room

Stephen Belanger

unread,
Apr 7, 2011, 1:11:06 AM4/7/11
to nod...@googlegroups.com
Looks like someone else had that same idea.

i used to play this :) my idea is something similar but where you can move in 3D, with everyone on the same room

--
Reply all
Reply to author
Forward
0 new messages