I'm currenly developing a game in Javascript. It's a Single Page Application so every change should be pulled from the server without page refresh. I'm currently wondering how I should handle the 'resources in stock' (like wood, food and gold).

I know there are more questions like this around here (regarding websockets and Ajax requests) but I'm currently looking for the best solution in my specific case.


Resources are produced every second. So for example, every minute 100 resources are produced. This should be updated live. I know, in this case it's not necessary to really update them live. I mean, I can simply calculate how much resources are produced in the current time minus the last updated time.

So no problem here, but there are a lot of different factors regarding the production of resources:

  • If a player is attacked, the enemy could have robbed some of his resources. So after an attack, the resources should be updated too.
  • If a player is attacked, and one of his 'productionbuildings' are damaged, he, for example, doesn't produce 1000 resources a hour, but 800 resources instead. So after a building has been demolished, the application should know the new building level to calculate the right amount of new resources.


So, how should I update the resources for the user? These are the options I think could possibly work:

  • Ping a script on the server, which calculates and updates the resources, every 5 seconds.
  • Set up a websocket stream and trigger it after each activity (after an attack, demolished building, ...)

Are there any other options? What would be the best way?


3 Answers 3



There are pros and cons to each method of synchronization you gave that depend on a couple of factors. First, is your game singleplayer or multiplayer, second, how real-time is your game? If your game is only single player, you may want to consider having a client side only game which would make things simpler. However, assuming you need a server backend to validate what the client does, here are some points.

Pulling & non-realtime game elements:

For non-realtime games, pulling would work just fine. The client could send updates about what the player did over the last few seconds to the server and in the same update, the server could send an updated game state back to the client. To smooth out the updates the client can model the updates that the server is performing, but refer back to the server whenever it pulls for updates.

Pulling & realtime game elements:

Using pulling in a realtime game is a little trickier because you would have to increase the pulling frequency significantly so that other players (or NPCs) won't appear glitchy. This would in tern cause an increase in traffic and html connections have a certain amount of overhead with each request.


Now lets talk about Sockets! If I remember correctly websockets are just a thin layer over a tcp connection which means it doesn't have all the overhead that the pulling approach has of establishing an html connection. This makes it ideal for realtime games because you can send more two-way communications with less overhead. Also, websockets have the additional benefit of allowing the server to push updates to the client whenever it needs to. Most modern browsers support websockets too (http://caniuse.com/#search=sockets).

Also Note:

Also keep in mind that if you are building a multiplayer game or a game that publishes scores that others can see, you should probably make sure that your server verifies all the actions that the client says it does. Basically, it's best to program most of the game logic on the server and have a 'thin' client that transmits the player actions to the server. If needed, the client can run the same logic as the server to make for a more immersive experience for the player.


Overall, I don't see any reason not to use websockets.

Good luck with your project.

  • \$\begingroup\$ The main reason to not use websockets is that there aren't as many options for implementing a websocket-based service on the server-side than there are options for creating a classic http webservice. But when you are using a server-sided technology which offers good support for websockets, then that's a non-issue. Another problem is that many proxy servers don't forward unencrypted websockets. An easy workaround for this is using wss (websockets over https). \$\endgroup\$
    – Philipp
    Jan 27, 2017 at 9:54
  • \$\begingroup\$ I think you might be thinking of "polling", not "pulling" in this context? \$\endgroup\$
    – uliwitness
    Jan 28, 2017 at 16:36

I would advise using socket.io because of the ease of learning it and that it will be great to have updates live.

I use socket.io for each multiplayer game.


The best way to calculate the resources is to use times and events.

Just imagine you have your timestring


the first line is last time the user was online, the second line is the time when the user comes online now. so now you can calculate the time difference in seconds for example. if you know how many resources are produced per second you just need to multiply difference * production.

now events


each time, something happens to the player (building upgraded,got attacked, building downgraded) you store the data in events table.

so when the player got attacked or goes online,you loop through events and calculate again with time difference.

as long as you store on each request the current datetime you can calculate everything without to pull or use websockets.

beside websockets working only in a non persistent world, you a player can log off and get resources, websockets are useless here.



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .