我正在编写一个 3 x 3 视口的 javascript 网页游戏，类似于Urban Dead使用的。“世界地图”存储为 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 个房间的内容并重新绘制/显示所有内容。
作为编程新手，我想知道这种实现是否过于幼稚或效率低下？
我不会担心过于幼稚或低效的解决方案。困难的部分是使游戏具有可玩性和乐趣-稍后进行优化。
查看示例，要传输的数据量看起来并不是很大。您应该能够获取完整的 9 个房间集进行更新。
您是在间隔（轮询）从服务器中提取数据，还是以某种方式将更改从服务器推送到客户端？
问题是您是否关心通知 AFK，以及有关隔壁房间的信息有多重要。
如果您认为更新房间后策略会发生变化？在这种情况下，每次更新完成时都会更新。
如果玩家不在乎，则在传递到下一个房间时完成更改。
一种中间方式的解决方案是根据游戏每 10 秒或 30 秒请求一次“增量”更新（只是已修改的元素）。在这种情况下，我们的中央时钟可能会很有趣（多个玩家将同时更新），这创造了一个回合式的游戏玩法。
作为一个RPG玩家（纸质RPG）我会认为第三种是不错的方式。您甚至可以混合解决方案：当前房间的短时间更新和基于感知的时间（金光闪闪和聋子只会在重大事件时更新外部房间）。
前一个选项将是最好的 imo，纯粹是因为随着地图的扩展，您可以更轻松地设置触发区域，从而使您的客户端加载地图的特定区域。您甚至可以只加载他们可以看到或可以访问的房间。
这也会有好处，例如，如果您有多个字符。想象一下，您的主要角色在一个位置，而次要角色在其他位置。客户端最好知道他们在哪里，了解每个角色可以看到什么，并且只从服务器请求这些信息。这是一个比让服务器不断地向正在收听的人广播所有房间信息的解决方案更具可扩展性。
关于房间内容的变化，这可以被标记为从服务器到所有客户端的事件——但纯粹基于房间坐标和最少的数据。如果此事件涵盖客户端当前可以看到的房间之一，则该客户端可能会发生对房间信息的请求。因此，这在一定程度上涉及您的选项二，但不应过多广播。
打个比方，这更类似于让客户/用户在他们想要的时候只从网站请求他们想要的资源，并可能注册接收有关他们感兴趣的内容的邮件警报。而不是让用户注册 RSS 提要并在网站发生任何变化时收到通知。前者更优化，可以通过特定方式进行控制，后者更好，如果您的用户有兴趣浏览网站的全部内容（这在游戏中通常不是这种情况 - 除非您设计的机器人必须作弊）。
总的来说，在通过实施这两种方法的一部分进行讨论之后会很有用。但如果这是一个选择，第一个会给你更多的控制权。