数字化管理 / 案例：屋顶击打破坏推演 → 提出任务
01 · TASK / 提出任务
一棒打中屋顶，接下来会发生什么？
保持建筑初始状态、击打位置和方向不变，只改变攻击力度：软件应先算出哪些部分先损坏、随后如何掉落、最后留下什么残损状态。
我们要处理的不是一张"损毁后的图片"，而是随时间展开的变化过程。
轻击
最先发生局部瓦片破损
随后发生少量碎片掉落，损毁停止扩展
最后留下小范围缺损
中等力度
最先发生命中附近的屋面破开
随后发生部分屋面与碎片继续下落
最后留下局部屋顶塌落
重击
最先发生命中附近的多个部件损坏
随后发生损毁向周边扩展，更多部件脱落
最后留下较大范围屋顶塌落
⚠ 教学提示：三种表现为供讨论的设计设想，不是实际仿真结果，也不代表真实古建筑一定按此规律损坏。
数字化管理 / 案例：屋顶击打破坏推演 → 发现缺口
02 · GAP / 发现缺口
模型告诉软件"长什么样"，还缺什么？
三维几何与外观模型可以确定屋顶的形状与部件位置，但不会自动给出哪些部分能破损、怎样分离、分离后怎样运动。破坏系统需要另外建立或配置以下内容：
Q1 · STRUCTURE
建筑由哪些相关部分组成？
哪些是瓦片、屋面和支撑部分？哪些部分连接在一起？
Q2 · STATE
它们现在是什么状态？
建筑是否完好？哪些部分已经受损？哪些部分已经脱落？
Q3 · INPUT
这次怎样击打？
打在哪里、朝哪个方向、使用多大的攻击力度？
Q4 · RULES
受到击打后，按什么规则变化？
什么条件下破损？某部分脱落后是否影响相邻部分？碎片怎样移动、碰撞和停止？
数据缺口
新增的不是"有数据了"，而是把任务需要的属性、状态、关系和变化规则也纳入计算。（如 Unreal Engine 支持分别设置部件破坏条件、保持固定的部分及破碎后的运动方式。）
数字化管理 / 案例：屋顶击打破坏推演 → 观察推演
03 · SIMULATION / 观察推演
不是换一张破损图，而是计算一段变化
推演的关键是"上一刻影响下一刻"：后续变化取决于前面已经发生了什么，而不是给完整模型换上一张破损贴图。
STEP 01
悟空击中屋顶
输入命中位置、方向与攻击力度
STEP 02
计算哪些部分受损
依据破坏条件判断命中范围内的部件
STEP 03
更新建筑状态
已脱落的屋面不再被视为"完整连接"
STEP 04
据新状态继续计算
相邻部件连带影响、碎片运动与碰撞
STEP 05
得到最终残损状态
输出本力度下的完整损毁过程
教学示意分支播放效果 ≠ 当场推演仿真回放 ≠ 实时推演以"按当前情况计算"为讲解对象
⚠ 边界提示：三条力度分支均为教学示意；"开发阶段仿真后回放"与"游戏运行时实时推演"需要区分，但不把第二种思路说成游戏制作的唯一方式。
数字化管理 / 案例：屋顶击打破坏推演 → 检验设计
04 · VERIFICATION / 检验设计
能算出损毁，不等于方案就合适
比较不同力度是在测试不同输入条件；判断是否采用某套设计，还要明确希望达到什么效果。给开发者设置三项要求：
CHECK 01
力度差异可辨认
轻击与重击应有可以辨认的区别，但不是越夸张越好。
CHECK 02
符合游戏设定
只破坏屋顶的攻击不应让整栋建筑消失；会下落的碎片不应长期悬空。
CHECK 03
不破坏后续游戏
场景要求继续战斗或离开时，损毁不能意外堵死唯一出口。
验证逻辑
模拟得到的是运行结果；验证需要将结果与预期条件比较，据此决定保留方案，还是调整易损程度、损毁范围或残骸处理方式。（如 Unreal Engine 功能测试框架支持记录结果并按预期判断通过与否。）
💡 一句话概括：不是把效果"做出来"就结束，而是改变条件 → 观察后果 → 判断设计能不能用。
数字化管理 / 案例：屋顶击打破坏推演 → 讲评
05 · SUMMARY / 讲评收束
只有几何与外观表示，软件可以处理建筑的形状；
结合相关状态和变化规则，软件才能推演建筑受到击打后的变化；
再加入判断要求，才能检验这个游戏设计是否合适。
SHAPE → STATE + RULES → SIMULATION → VERIFICATION
本节要点
知道"长什么样" ≠ 知道"受到作用后怎样变化"；改变条件、观察后果、对照预期，才是完整的数字化管理闭环。