我正在编写一款javascript网络游戏，它有一个类似于Urban Dead使用的3 x 3视口。"世界地图"存储为一个100 x 100的2D阵列服务器端(nodejs)，每对坐标定义一个"房间"。因此，3 x 3视口显示了其中9个房间的名称和内容。
用户的位置作为坐标存储在服务器端。例如Bob = { x : 2, y : 3 }。所以Bob的x坐标是Bob.x。客户端(浏览器)可以检索并计算出其他8个房间的坐标，并向服务器询问这些房间的内容。然后这些将显示在视口中。这看起来像Urban Dead中的视口(左上角)。
问题
我应该如何考虑使视口"刷新"或更新？我正在考虑这样做。。。
1)当玩家从坐标(2,3)移动到(1,3)时。客户端再次向服务器询问9个房间的内容，并重新绘制/显示所有内容。
2)当其中一个房间的内容发生变化时，服务器(nodejs)运行一个客户端功能，"告诉"它向服务器询问9个房间的属性，并重新绘制/显示所有内容。
作为编程的新手，我想知道这种实现是过于天真还是效率低下？
前一个选项将是最好的imo，纯粹是因为随着地图的扩展，您将更容易设置触发区域，从而使您的客户端加载地图的特定区域。你甚至只能加载他们可以看到或访问的房间。
这也将是有益的，例如，如果你有多个字符。想象一下，你的主角在一个地方，而次要角色在其他地方。客户端最好知道他们在哪里，了解每个角色可以看到什么，并且只从服务器请求这些信息。这是一个比让服务器不断向收听者广播所有房间信息更具扩展性的解决方案。
关于房间内容的更改，可以将其标记为从服务器到所有客户端的事件，但完全基于房间坐标和最小数据。如果此事件覆盖客户端当前可以看到的某个房间，则该客户端可能会请求房间信息。因此，在某种程度上，这涉及到你的选择二，但不应该广播太多。
作为一个类比，这更类似于让客户/用户在他们想要的时候只从网站请求他们想要的资源，并可能注册他们感兴趣的内容的邮件提醒。而不是让用户注册RSS订阅源，并在网站上发生任何更改时收到通知。前者更优化，可以通过特定的方式进行控制，如果用户有兴趣浏览网站的整个内容，后者更好(游戏中通常不是这样——除非你设计的是必须作弊的机器人)。
总的来说，通过实施这两种方法的一部分来讨论它将是有用的。但如果这是一个选择，第一个会给你更多的控制权。
我不会担心过于天真或效率低下的解决方案。困难的部分是使游戏可玩性和乐趣-稍后进行优化。
从这个例子来看，要传输的数据量看起来并不是很大。您应该能够获取完整的9间客房进行更新。
您是以一定间隔(轮询)从服务器中提取数据，还是以某种方式将更改从服务器推送到客户端？
问题是你是否关心AFK收到通知，以及关于隔壁房间的信息有多重要。
如果你认为房间更新了，策略会改变吗？在这种情况下，每次进行更新时都会进行更新。
如果一个球员不在乎，那么当传球到下一个房间时，就会做出改变。
中间的解决方案是根据游戏的不同，每10秒或30秒要求一次"delta"更新(只是修改过的元素)。在这种情况下，我们的中心时钟可能很有趣(多个玩家将在同一时间更新)，这创造了一种回合式的游戏。
作为一名RPG玩家(纸质RPG)，我认为第三种方式是一种好方法。您甚至可以混合使用解决方案：当前房间的短时间更新和基于感知的时间(一个聋哑人只会在重大活动时更新外部房间)。