JUMP! 概观

设计理念

系统里大量牵涉到接口的使用，以下将会讲解几个用到的接口模式。

注意: 接口实现者必须遵守约定，接口才可以正常运作。

主系统提供事件(tag)供其他系统监听(加上tag)，当该事件触发时便会调用那些监听了的命令函数（但不保证任何顺序，如需确保一定程度的先后顺序，即priority，请使用多个event）。那些事件如果判断为处理完毕，则可以设置特别的假名分数来避免之后的其他命令函数继续执行。

比如道具系统以及胜利、失败检测等也是使用了事件监听模式。

注册器是一种特殊的事件监听器，只会在初始化的时候运行。其运行目的在于注册信息到主模块（在本系统的用途则是注册道具、marker以及游戏模式。），并同时设置自己的ID以便之后处理。

主系统里不定义某命令函数，由别的数据包以类似事件的方式提供，并在系统加载时检测执行数（通过result）。如果结果并非1（0，即无定义；>1，即发生冲突）则报错。

这是用于把核心模块无法实现的功能（得视乎实际地图的功能）分拆，并确保不会发生冲突的方法。

自然，function名称都冲突的话就没撤了...

部分功能我们开放接口，但我们同时会提供默认实现，供用户选择是否覆盖。

这功能会与功能提供者配合，但不会在无定义时报错，而是设置为使用默认实现。

以下更清楚定义几个名词，方便下文使用：

而检测加载和宣示存在的方式都十分简单。宣示存在就是设置一个特殊假名（其名称不应该和其他系统发生冲突）到指定分数。假如那假名为某个分数，就代表曾经被加载过。

本系统的状态改变如上，使用记分板假名储存状态数据。

使用接口进行设计能简化设计难度，但也会造成多余的调用。我们会使用内部命令函数的方式来避免部分执行。

简单来说，这实际模式就是把命令函数实际内容放在别的函数里，当前函数则改为条件检测（实际上的条件检测未必只是一条命令，以下只是简化版）。

 
1
# bla:function1
2
execute if 条件... run function bla:function1_internal
3
# bla:function1_internal 就是内部命令函数，也就是实际命令。

部分检测十分麻烦，如哪个模式才需要检测有没有玩家存在，或默认实现的检测。但是我们可以安全的估计这些结果在一段时间内是不会改变（前者为游戏的一回合，后者为再次加载前），故此我们可以把这结果暂存到别的分数，简化检测，需要时才重置结果开始检测。

系统主要建基于接口以及约定。主系统提供了流程处理以及默认机制，用户可以使用数据包来替换机制、增加功能，从而扩展系统。但是那些数据包必须遵从主系统的约定，否则可能会出现未知错误。