同步前后端联调与文档更新
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# 多线程联调协作方式
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
## 目标
|
||||
@@ -320,3 +320,4 @@
|
||||
|
||||
而不是先把协作体系做复杂。
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 故障恢复机制
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于说明当前客户端在“游戏进行中非正常退出”场景下的恢复机制。
|
||||
@@ -241,3 +241,4 @@
|
||||
|
||||
**保证玩家在异常退出后可以继续当前对局,但不承担恢复所有临时界面状态。**
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 游戏规则架构
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于说明当前项目中“游戏规则”在文档、配置文件、样例 JSON、解析代码和运行时规则引擎之间的实际组织方式。
|
||||
@@ -382,3 +382,4 @@
|
||||
|
||||
**`doc/config` 管公共规则全集,`doc/games/<游戏名称>` 管玩法规则与配置子集,`event/*.json` 管可运行样例,客户端解析配置后交给规则引擎执行,并由轻量恢复层处理异常退出后的续局。**
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 新玩法建议方案
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于整理当前阶段值得考虑的新游戏玩法方向,重点回答以下问题:
|
||||
@@ -444,3 +444,4 @@
|
||||
如果只优先选一个最值得推进的新玩法,建议先做:`幽灵追逐赛`。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 玩法设计文档模板
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于定义后续所有玩法设计文档的**统一写法**,保证玩法规则、全局规则块、配置落点和最小样例能够一起沉淀,为后续 JSON 配置管理和后台装配提供稳定输入。
|
||||
@@ -413,3 +413,4 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 程序默认规则基线
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于定义当前客户端在**不依赖活动配置细项**时,程序层应该内建的默认规则。
|
||||
@@ -441,3 +441,4 @@ HUD 属于公共程序能力,不属于某个玩法专属实现。
|
||||
|
||||
当前阶段应以这份文档作为**程序默认能力基线**:先把最小流程、弹层职责、HUD 结构和距离反馈定死,再决定哪些内容值得进入配置层。
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 运行时编译层总表
|
||||
> 文档版本:v1.0
|
||||
> 最后更新:2026-04-02
|
||||
> 最后更新:2026-04-02 08:28:05
|
||||
|
||||
|
||||
本文档用于定义当前项目推荐的“运行时编译层”结构,也就是把系统默认值、玩法默认值、活动配置、玩家设置编译成统一运行时 profile 的中间层。
|
||||
@@ -247,3 +247,4 @@
|
||||
|
||||
这样配置越多,系统越不容易乱;后续后台做复杂了,也还是有一层中间结构兜住。
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user