下载 App
游戏阶段性实现
结合你给的“先做可验收闭环、再逐步扩展”的思路，目前优先级需要重新调整。
不能继续围绕学生AI不断增加特殊判断。当前主要矛盾已经变成：
> 玩家动态建造了教室、厕所、操场，但老师、学生、保洁还不能根据房间能力和校园活动自动领取正确任务。
因此，推荐实施顺序不是简单的：
```text
房间能力服务
-> 活动服务
-> 任务服务
-> 人员调度
```
而是把它们拆成几个**可以直接看到、可以验收的小阶段**。
---
# 一、当前已经完成到什么程度
目前已有的基础设施：
```text
日程服务
-> 学生AI
-> 学生权重
-> 校园导航
-> 地点结算
-> 多阶段行为
-> 打断服务
```
已经能处理：
- 早读、上课、课间、午饭、体育、放学等阶段
- 学生选择教室、厕所、操场、食堂、医务室
- 简化的地点间移动
- 食堂、厕所、医务室、操场的多阶段行为
- 受伤、流鼻血、紧急如厕等临时打断
但当前仍是原型型实现：
- 目标房间 ID 仍有硬编码
- 只真正调度学生
- 不认识玩家动态创建的 教室1/厕所2/操场3
- 没有“课程实例”
- 没有通用任务对象
- 没有老师、保洁、校医的统一人员调度
- 导航当前是“按房间距离计算耗时”，还不是地图上可见的逐步寻路
---
# 二、重新确定开发阶段
当前项目处于：
```text
功能开发前期
```
当前主要矛盾不是：
- UI 是否足够漂亮
- 是否需要复杂A*
- 春季运动会细节够不够多
- 保洁动作动画够不够真实
当前主要矛盾是：
```text
玩家建造的校园空间
与
校园人员的日常活动
还没有形成动态闭环
```
所以第一阶段应只验证一个核心问题：
> 房间由玩家动态创建后，日程变化能不能让不同职业的人自动找到正确房间并执行任务？
---
# 三、推荐的实施总顺序
```text
阶段 0：整理动态地图读取边界
↓
阶段 1：房间能力服务
↓
阶段 2：最小活动服务
↓
阶段 3：通用任务服务
↓
阶段 4：人员调度
↓
阶段 5：学生 + 教师上课闭环
↓
阶段 6：保洁清扫闭环
↓
阶段 7：可视化调试工具
↓
阶段 8：扩展体育课、升旗、赛事
↓
阶段 9：真正路径图/拥挤系统
```
---
# 四、阶段 0：先统一动态地图来源
## 目标
确认游戏运行时读取的是玩家在地图编辑器里保存的动态房间，而不是当前静态示例地图。
## 需要解决
现在系统大量读取：
```text
数据/地图/校园主地图.lua
```
但玩家编辑出来的房间可能在：
```text
MapData.data.rooms
运行时地图存档
地图编辑器共享状态
```
必须先确定唯一入口：
```text
房间能力服务
-> 运行时地图数据
```
其他系统不能再直接：
```lua
MapData.GetRoom("classroom_2_3")
```
## 验收标准
玩家创建：
- 教室1
- 厕所2
- 操场3
运行时调试面板能够列出：
```text
教室：教室1
厕所：厕所2
操场：操场3
```
删除厕所2后，查询结果立即不再包含厕所2。
## 现在不做
- 不做人员移动
- 不做课程
- 不做卫生
- 不做A*
---
# 五、阶段 1：房间能力服务
这是下一步应最优先实现的模块。
建议：
```text
scripts/系统/房间能力服务.lua
```
## 它只回答空间问题
```text
有哪些教室？
有哪些厕所？
有哪些操场？
哪些房间可用？
哪个房间容量足够？
某个房间具有什么功能？
某个房间当前是否被活动占用？
```
## 推荐接口
```lua
GetRoomsByType(roomType)
GetRoomsByCapability(capability)
GetBestRoom(query)
IsRoomAvailable(roomId)
GetRoomCapacity(roomId)
GetRoomEntry(roomId)
```
## 房间能力来源
能力不应散落硬编码，应来自现有：
```text
scripts/数据/地图/功能空间类型注册表.lua
```
例如：
| 房间类型 | 能力 |
|---|---|
| 教室 | teachingcleaning |
| 厕所 | toiletcleaning_high_priority |
| 操场 | sportsassemblycompetitioncleaning |
| 食堂 | diningcleaning_high_priority |
| 医务室 | medicalrestdisinfection |
## 验收标准
调用：
```text
查找可上课房间
```
返回：
```text
教室1
```
调用：
```text
查找可体育活动房间
```
返回：
```text
操场3
```
调用：
```text
查找厕所
```
返回：
```text
厕所2
```
这里先不出现学生和老师。
---
# 六、阶段 2：最小活动服务
建议：
```text
scripts/系统/活动服务.lua
```
活动服务不直接控制人员，只生成“校园现在发生什么”。
## 首版只支持三种活动
```text
普通课程
体育课
课间
```
不要立刻加入：
- 春季运动会
- 篮球赛
- 足球赛
- 升旗仪式全部细节
- 社团活动
## 活动实例
```text
普通课程：
activityId
type = class
classId
teacherId
locationId
startTime
finishTime
priority
```
体育课：
```text
type = physical_education
classId = class_2_3
teacherId = teacher_sports_1
locationId = playground_3
```
课间：
```text
type = break
locationId = nil
```
## 活动生成逻辑
```text
日程阶段变化
-> 活动服务创建活动实例
-> 房间能力服务解析地点
-> 发布 activity.started
```
## 验收标准
上课铃响后调试面板显示：
```text
活动：二年三班文化课
地点：教室1
教师：张老师
参与者：二年三班
```
体育课开始后显示：
```text
活动：二年三班体育课
地点：操场3
教师：王老师
```
人员这时还不一定移动。
---
# 七、阶段 3：通用任务服务
建议：
```text
scripts/系统/任务服务.lua
```
这是降低耦合的核心。
活动服务不应该直接命令学生AI和教师AI，而是生成任务。
## 统一任务对象
```text
taskId
taskType
actorId
actorRole
targetRoomId
activityId
priority
status
createdAt
expiresAt
```
## 首版任务类型
只做：
```text
attend_class
teach_class
attend_sports
teach_sports
```
后续再加：
```text
clean_room
treat_student
patrol
inspect
```
## 任务状态
```text
pending
-> assigned
-> travelling
-> active
-> completed
```
加上：
```text
cancelled
blocked
```
## 验收标准
上课铃响后产生：
```text
学生阿杰：attend_class -> 教室1
学生小雨：attend_class -> 教室1
张老师：teach_class -> 教室1
```
不要求马上移动，但任务必须能被查询和显示。
---
# 八、阶段 4：人员调度
建议：
```text
scripts/系统/人员调度.lua
```
它只负责：
```text
哪个人领取哪个任务
任务优先级冲突怎么处理
人员是否空闲
人员角色是否匹配
```
## 不能直接负责
- 计算路径
- 执行食堂结算
- 修改课程表
- 画UI
- 保存云数据
## 角色与任务匹配
| 角色 | 可接受任务 |
|---|---|
| 学生 | 上课、体育课、集体活动、午饭 |
| 任课老师 | 授课、监考 |
| 体育老师 | 体育课、比赛裁判 |
| 保洁 | 清洁房间 |
| 校医 | 治疗、活动待命 |
| 保安 | 巡逻、校门检查 |
## 优先级
学生：
```text
医疗
> 校方处置
> 当前课程
> 集体活动
> 如厕
> 午饭
> 自由活动
```
老师：
```text
紧急处置
> 授课
> 集体活动管理
> 备课
```
保洁：
```text
紧急卫生事故
> 已认领清洁任务
> 高脏污房间
> 普通巡回清洁
```
## 验收标准
同一名学生不能同时持有：
```text
上课任务
体育任务
课间游荡任务
```
高优先级任务能取消或挂起低优先级任务。
---
# 九、阶段 5：第一个真正可玩的验收闭环
这是最重要的一阶段。
## 只做一个班
先限定：
```text
一个班级
一间教室
一名老师
三名学生
一个操场
一个体育老师
```
## 闭环
```text
早读阶段
-> 学生去教室1
上课铃响
-> 活动服务创建课程
-> 学生获得上课任务
-> 老师获得授课任务
-> 全部前往教室1
-> 到达后学生“上课中”
-> 到达后老师“授课中”
下课铃响
-> 课程任务完成
-> 部分学生去厕所2
-> 部分学生去操场3
-> 老师回办公室或走廊巡视
体育课开始
-> 体育活动创建
-> 学生去操场3
-> 体育老师去操场3
-> 到达后开始体育活动
```
## 验收标准
玩家直接看地图就能判断：
- 上课铃响后，学生和老师是否都去了同一间教室？
- 下课后，学生是否按个体需求分流？
- 体育课时，学生和体育老师是否都去了操场？
- 删除操场后，体育课是否显示“场地不足”，而不是继续去不存在的房间？
- 删除教室后，上课任务是否进入 blocked？
这才是第一版真正可验收的原型。
---
# 十、阶段 6：保洁清扫闭环
学生和老师的闭环成立后，再做保洁。
原因是保洁依赖：
- 动态房间发现
- 通用任务对象
- 人员调度
- 导航
- 地点占用判断
这些正好可以复用前五阶段。
## 最小保洁闭环
```text
房间使用
-> 增加脏污
卫生系统扫描
-> 生成 clean_room 任务
人员调度
-> 保洁认领任务
保洁导航
-> 前往目标房间
到达后
-> 清扫倒计时
完成
-> 降低脏污
-> 领取下一项任务
```
## 首版房间
只做：
```text
厕所2
教室1
操场3
```
## 清洁优先级
```text
厕所
> 教室
> 操场
```
实际优先级还会乘脏污度：
```text
任务分 = 房间基础权重 + 脏污度 + 等待时间
```
## 验收标准
- 厕所2比操场3更容易被优先清扫
- 同一间房只能被一名保洁认领
- 清扫完一间后自动领取下一间
- 删除目标房间后任务自动取消
- 上课中的教室可延后清扫，避免保洁穿过课堂
---
# 十一、阶段 7：必须同步制作调试工具
你给出的思路里，“同步做 Debug 工具”非常适合当前项目。
建议新增一个调试面板显示：
## 房间能力
```text
教室1：teaching / cleaning
厕所2：toilet / cleaning_high_priority
操场3：sports / assembly / cleaning
```
## 当前活动
```text
08:10 二年三班数学课
地点：教室1
状态：进行中
```
## 人员任务
```text
阿杰：前往教室1
小雨：上课中
张老师：授课中
保洁A：清扫厕所2
```
## 阻塞原因
```text
体育课：blocked
原因：没有可用操场
```
这比继续加入更多后台逻辑更有验收价值。
---
# 十二、阶段 8：扩展集体活动和偶发事件
前面的通用闭环稳定后，再加：
```text
升旗
广播操
篮球赛
足球赛
春季运动会
```
它们不应该再修改学生AI，而只是创建不同的活动实例和任务。
## 升旗
```text
活动类型：flag_ceremony
地点能力：assembly
参与者：全体学生
工作人员：班主任、校方人员
```
## 篮球赛
```text
活动类型：basketball_match
地点能力：basketball
参赛者：指定班级
围观者：其他学生中的一部分
工作人员：体育老师、校医待命
```
## 春季运动会
```text
活动类型：spring_sports_day
地点能力：sports + assembly
覆盖普通课程
持续半天或全天
```
---
# 十三、阶段 9：最后再做真正路径图
当前导航是“按房间中心距离计算耗时”，足够验证活动—任务—人员闭环。
不要现在立刻上复杂A*。
只有出现下面问题时才升级：
- 人员需要在地图上真实移动
- 墙和门必须影响路线
- 多个房间入口不同
- 人员会穿墙
- 大量人员需要拥挤分流
- 动态建造后路线需要重算
升级顺序：
```text
房间入口点
-> 房间连接图
-> A* 路径
-> 局部避让
-> 拥挤成本
```
---
# 十四、重新排序后的实际开发清单
## P0：立即实现
1. 动态地图读取边界
2. 房间能力服务
3. 房间能力调试列表
验收：
```text
能正确识别玩家创建的教室1、厕所2、操场3
```
## P1：紧接着实现
4. 活动服务
5. 课程活动实例
6. 活动调试列表
验收：
```text
上课铃响后生成“教室1上课”活动
体育课生成“操场3体育”活动
```
## P2：核心闭环
7. 任务服务
8. 人员调度
9. 教师基础数据
10. 学生/教师任务接入导航
验收：
```text
老师和学生能同时前往正确地点
```
## P3：保洁闭环
11. 卫生状态
12. 清洁任务生成
13. 保洁调度
14. 逐房间清扫
验收：
```text
保洁会按优先级逐个清扫厕所2、教室1、操场3
```
## P4：内容扩展
15. 升旗
16. 广播操
17. 篮球赛
18. 足球赛
19. 春季运动会
## P5：导航升级
20. 房间入口
21. 连接图
22. A*
23. 拥挤和避让
---
# 十五、哪些现有工作应暂时停止扩展
为了抓住当前主要矛盾，以下部分暂时不要继续深挖：
- 不继续给学生权重增加更多参数
- 不继续扩充操场受伤种类
- 不继续增加更多地点行为阶段
- 不继续增加更多日类型
- 不立刻做A*
- 不先做复杂比赛规则
- 不先做漂亮的人员动画
这些都不是当前核心阻塞。
---
# 最终结论
当前最合理的下一步是：
```text
动态地图读取边界
-> 房间能力服务
-> 房间能力可视化验收
```
而不是立即同时开发全部四层。
第一批验收目标应该非常具体：
> 玩家在编辑器中创建教室1、厕所2、操场3后，运行时系统能自动识别它们的能力，并在调试面板中正确列出；删除任意房间后，能力查询结果同步变化。
这个目标成立后，再做活动服务；活动成立后，再做任务与人员调度。这样每一阶段都能直接看到成功或失败，不会再次形成大量“看起来完成、实际没跑通”的半成品。
