0
\$\begingroup\$

I have this 2D tilemap game 13x13 viewport (169 tiles drawn on canvas at a time) of a 150x150 map. Each tile is 32x32px. Obviously I only update the 13x13 viewport...

I want to update a canvas in real-time as the world-map will be handled server-side. At least the logic... the drawning... should it be server-side or client-side?

Now, I am using Socket.IO for real-time data. Based on that current player's x and y, the canvas is drawn from where that person is on the map.

I can do this two ways:

  1. (Server-side) Use node-canvas to draw the server-side via NodeJS and transmit back the new canvas. Is it possible? Because it seems I can only do it once via a PNG.

  2. (Client-side) Transmit the 169 array of the new tileset (when player moves or action happens). Doing the logic server-side and draw it on the client-side from the array received from a callback.

Client-side problem: The problem here is that transmitting that large of an array does take seconds (2-3) so there is some lag.

Server-side problem: There is no continuous streaming of a canvas being drawn from the server that outputs to client... is there? Or am I not looking hard enough at node-canvas npm module.

I am not using any JavaScript game framework.

What are my best options here?

\$\endgroup\$
  • 2
    \$\begingroup\$ If sending an array of 169 tiles takes a long time, then sending a PNG is going to take a lot longer. \$\endgroup\$ – user253751 Sep 28 '16 at 4:02
3
\$\begingroup\$

You should keep a copy of the map on both the client and the server. Send updates from the server that propagate to the client. But trying to send a chunk of the map every frame is a recipe for disaster. Drawing should be handled client side and logic handled mostly server side. You could certainly stream in data, but you should not do it once every frame, especially in a language such as javascript with little control over memory management. You could hypothetically stream video in real time (wouldn't be a simple thing to implement) but that is likely to look terrible, require a ton of bandwidth, and not work very smoothly (See OnLive).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.