I am writing a javascript web game that has a 3 x 3 Viewport similar to the one Urban Dead uses. The "world map" is stored as a 100 x 100 2D array server-side (nodejs), each pair of coordinate defines a "room". So, the 3 x 3 viewport shows the name and content of 9 of the rooms.

User's location are stored server-side as coordinates. E.g. Bob = { x : 2, y : 3 }. So Bob's x-coordinate is Bob.x. The client (browser) can retrieve this and work out the coordinates of the other 8 rooms, and asks the server for the content of those rooms. These are then displayed in the viewport. This is suppose to look like the viewport in Urban Dead (top left corner).

Question

How should I think about making the viewport "refresh" or update? I am thinking of doing it this way...

1) When the player moves from coordinates (2,3) to (1,3). The client asks the server about the content of the 9 rooms again and re-draw/display everything.

2) When the content of one of the room changes, the server (nodejs) runs a client-side function that tells it to ask the server for the content of the 9 rooms and re-draw/display everything.

Being new to programming, I wonder if this implementation would be too naive or inefficient?

The former option would be the best imo, purely for the reason that as your map expands it will be easier for you to set-up trigger regions that cause your client to load specific areas of the map. You could even only load the rooms that they can see or have access to.

This would also be of benefit, for example, if you were to have multiple characters. Imagine you have your main character in one location, and a secondary character elsewhere. It would be far better for client to know where they are and to understand what each character can see and only request this information from the server. This is a much more expandable solution than having the server just constant broadcast all room information to whoever is listening.

With regards to changes in room content, this could be flagged as an event from the server to all clients - but based purely on room co-ordinates and minimal data. If this event covers one of the rooms the client can currently see, a request by that client for the room information can occur. So in part this involves something of your option two, but shouldn't broadcast much.

As an analogy, this is more akin to having clients/users requesting only the resources they want from a website at the time they want them and possibily signing up to mail alerts about content that's interesting to them. Rather than having the user sign-up to an RSS feed and being notified when anything changes on the site. The former is more optimal and can be controlled in specific ways, the latter is better if your user is interested in overviewing the whole content of the site (which is not the case usually in games -- unless you're designing bots that have to cheat).

Overall, after talking it through implementing part of both approaches would be useful. But if it's a choice the first one will give you more control.