迷宫类游戏的交互事件-程序实现思路

过去的设计思路

常见的交互，是根据需求实现，策划提什么样的要求，程序就做什么样的表现
比如策划的需求会是这样的：

1. 点击场景的道具灯，灯亮
2. 走到机关门附近，UI上出现开门按钮
3. 点击开门按钮，门播动作，打开
4. 进入一个房间，房间外的NPC停止移动

如果完全按照策划的需求挨个实现，会耗费大量人力，工作也很重复。
比如道具灯做完，然后策划又要一个道具椅子，同样是点击场景，只不过响应变成了人播动作
代码也会写的很乱，来回的交互，冗杂的函数，如果场景的交互超过100个，代码基本就没法看了

常规项目的优化做法

好一点的设计，会做一个局部的优化，比如把“碰撞”这个常见的交互事件剥离，业务关注碰撞后的响应，如

1. 碰撞椅子坐下
2. 碰撞机关UI显示开门按钮
3. 碰撞鬼掉血

这样写出来的代码会给玩家角色添加各种各样的接口，满项目随意调用，只是策划需求恰好是碰撞触发，才看起来像是交互事件
另外，实际上碰撞只是触发的其中一种方式，不是全部

触发器-响应器

最终的修改结果：将交互分离出两种对象：触发器和响应器
触发器就是交互的方式，点击、碰撞、区域、UI、场景事件等等都是触发器
响应器是效果，UI动画、光影迷雾、对象的位移旋转、动作等都是效果

程序的开发工作集中在两部分：

1. 扩展新的触发器和响应器
2. 拆分策划需求，根据已有实现，配合策划组合出新的交互事件