一些建议

[czp3009]

根据通常的游戏引擎设计, 游戏的每次更新称为 tick 而非 round.

tick 分为 图形帧 和 物理帧. 由于养蛊游戏的特殊性, 玩家自身没有直接的操作, 所以没有图形帧, 只有 物理帧.

物理帧 将执行当前地图内所有物体(GameObject)中的对应方法来完成本次更新.

tick 内部不再细分生命周期, 例如 tick 开始时执行移动, tick 结束时执行建造, 这会导致很多问题, 并非最佳实践. 任何操作都需要至少一个 tick, 部分操作在设计上可能故意延迟一 tick 执行(例如通常的 FPS 游戏中的开火操作), 这里还需要一个基于 tick 的 Schedule.

对于通常的 RTS 来说, 用户并非每时每刻都在下达指令. 例如 移动 指令. 游戏必须记住用户上一次下达的指令并在指令完成前或者用户对相同单位下达新指令前一直执行它. 同时这也意味着游戏本身需要有最基本的 AI, 例如自动寻路以及自动攻击.

对于养蛊游戏而言, 要求用户在每 tick 都给出指令 与 游戏记住用户的指令并不断执行 在理论上是都可以实现的. 例如著名养蛊游戏 Screeps 就采取前者(自动寻路也是每 tick 都要执行一次). 但是如果最终代码在用户的服务器上运行, 那么由于延迟等问题, 这是无法实现的.

最终代码在用户的服务器上运行是非常吸引人的, 但是考虑到难以设计的 API(有限地图的 RTS 尚会产生大量流量)(如果服务器主动推送 GameObject 变动), 以及用户服务器的配置差异导致的不公平, 恐怕实现起来会比较困难.

随机的出生属性是非常好的设计, 但是这不一定利于编程, 通常的最终代码会硬编码很多内容(例如游戏开局先造多少农民), 随机的各类 buff 将使得最终代码的撰写成本提高, 降低客户留存性.

根据其他的设计, 还需要决定游戏是 持续世界 还是 对局类 模式. 如果是对局类模式, 则还需要诸如天梯排名一类的, 让用户可以装逼的地方.

推荐不使用纯 TCP, 因为大多数语言的 Socket 部分不会自动处理 TCP 粘包和拆包, 这会增加使用难度. WebSocket 标准保证了收到的 Frame 一定是完整的, 但是 Websocket 没有指定数据传递的格式, 正文部分可以是任何自定义的 Text 或 Binary. 这在一定程度上也会使得最终用户手足无措(必须掌握一定程度的网络编程). 所以推荐使用 STOMP 作为应用层的数据传递协议(底层使用 Websocket 实现)(提供每种语言的 SDK 成本太大, 而且影响一些喜欢自己造轮子的用户的心情).

关于地图, 不知设计上是否考虑真实的天体物理, 是否有拟真的恒星, 行星, 卫星 模型. 航天器是否会受到引力影响从而可以做出眼花缭乱的操作, 例如利用行星引力弹弓快速投送战力. 这是非常令人期待的.

(斜眼笑