这样，每秒绘制的面积，玩家移动时可能是80～100个屏幕面积，而玩家不移动时可能只有50个屏幕面积。游戏中，玩家停下来打怪、打字、整理物品、释放技能都是站立不动的，因此 大量的时间里都不会触发地面的绘制，对性能的节约很大 。
服务器端
由于目标是js实现一款多人网游，所以服务端使用Node，使用socket与浏览器通讯。这样做还有一个好处，就是一些 公用的逻辑可以在两端复用 ，例如判断地图上某个坐标点是否存在障碍物。
Node端的玩家、场景等游戏相关数据全部存储与内存中，定期同步至文件。每次Node服务启动时，将数据从文件读取至内存。这样可以玩家较多时，文件读写的频率成指数级上升，从而引发的性能问题。（后来为了提高稳定，为文件读写增加了一个缓冲，“内存-文件-备份”的方式，以免读写过程中服务器重启导致的文件损坏）。
Node端分接口、数据、实例等多层。“接口”负责和浏览器端交互。“数据”是一些静态数据，例如某个药品的名称和效果、某个怪物的速度和体力，是游戏规则的一部分。“实例”是游戏中的当前状态，例如某个玩家身上的一个药品，就是“药品数据”的一个实例。再举个例子，“鹿的实例”拥有“当前血量”这个属性，鹿A可能是10，鹿B可能是14，而“鹿”本身只有“初始血量”。
3.场景地图的实现
地图场景
下面开始介绍地图场景部分，仍然是依赖 Easycanvas 进行渲染。
思考
由于玩家是始终固定在屏幕中心的，所以玩家的移动，实际上是地图的移动。例如玩家像左跑，地图就向右平移即可。刚才已经提到，玩家处于3个canvas中的中间一层，而地图属于底层，因此玩家一定遮挡地图。
这样看起来是合理的，但是假如地图中有一棵树，那么“玩家的层次始终高于树”就不对了。这时，有2种大的解决方案：
地图分层，“地面”与“地上”拆开。将玩家处于两层之间，例如下图，左侧是地上、右侧是地面，然后重叠绘制，把人物夹在中间：
这样看似解决了问题，其实引入了2个新的问题：第一个是，玩家有时可能会被“地上”的东西遮挡（例如一棵树），有时又需要能够遮挡“地上”的东西（例如站在这棵树的下方，头部会遮挡住树）。另一个问题是渲染的性能消耗会增加。由于玩家是时刻在变的，“地上”这一层需要频繁重绘。这样做也打破了最初的设计——尽量节约地面大地图的渲染，从而导致canvas的分层更加复杂。
地图不分层，“地面”与“地上”在一起绘制。当玩家处于树后的时候，将玩家的透明度设置为0.5，例如下图：