docs: generic architecture design

[johnbanq]

对于Allay服务端的整体设计，我的提案如下：

我认为整个东西的重点在于 网络协议/存储/游戏逻辑的划分，只要把握了这三大块的划分，剩下的都会简单的多，我认为可以这么组织：

我们把系统分成 网络协议/存储与生成/游戏逻辑 三大块：

网络协议：负责所有和网络协议相关的东西，例如资源包分发，登录流程等等等等。它负责处理底层协议细节，出来的是纯粹的和游戏相关的报文。

其具体可以组织成NetworkManager(顶层对象)，每个玩家的连接由PlayerConnection表示，PlayerConnection知道自己玩家的UUID，负责当收发包的中转者。

存储与生成：顾名思义，负责存储现有地形数据，与生成新地形。这里合并了生成，其目的是为了形成“所有地形都已经实现生成好了，只是要读出来”的抽象。

具体可以组织成LevelStoreManager对象，负责向每个LevelServer提供LevelStore对象，LevelStore提供基本的存储读写API（读写Chunk，读写实体等），操作全部用Future异步化，由游戏逻辑决定要不要等。

游戏逻辑：负责游戏逻辑本身，每个Level由一个LevelServer负责，其内包含了一个Level应当持有的所有状态，以及一个负责运行tick loop的线程。

高层次来看，tick loop要做三件事：处理客户端发来的包，跑游戏逻辑，把变化发回给客户端。

tick loop在每个tick开始，都先从当前Level所拥有的PlayerConnection中拉取到目前为止已经收到的包，然后调用当前Level内的PacketHandler进行处理，来做命令执行/游戏世界操作/等等等等。然后调用相关对象的tick函数做ticking，最后将需要发送的区块更新信息/背包更新信息发给感兴趣的客户端。发包不一定要在最后做，也可以按需求迁移（或者提供flush功能）。

其它东西（例如命令处理，表单，NPC对话框）都可以在Level层面用Manager解决

[smartcmd]

我觉得这玩意要不写个md放到仓库里面？感觉放在issue不太好

[johnbanq]

我觉得这玩意要不写个md放到仓库里面？感觉放在issue不太好

我觉得这就是个讨论，还没有正式成型变成文档，先放issue里吧。

[johnbanq]

一些关于游戏架构的设想。通过操作和状态分离，可以更好的封装底层存储和并发控制细节，也可以做到更好的可扩展性。

这个设计只能作为参考，真要实现必须要提出者带头。我这在可预见的未来都没空，还要帮忙重构PNX为后续抄代码铺路→_→