谢谢了

但是我的GM8的父对好像有bug，用不起。

受教了，支持楼主

现在我们举个例子来说说父对象的一个实际例子。
看这个名为oParent的object：

如图，这个object的三个基础事件的内容分别是Create定义变量，Step判断鼠标左键按下，以及Draw绘制自身和文字。效果是，绘制自身，再绘制text所储存的文字；同时如果鼠标左键在区域内按下，就执行0号用户事件并跳转到target_room所指定的房间。假设现在还是上文所说的20个按钮：

如图，只要oChild1到oChild20均选择oParent作为父对象，它们就只需要在Create定义自身不同于其他19个的两个变量，即要绘制的文字，和点击后要跳转到的房间即可，剩下了大量工作。
有人可能会问，我不需要这些子对象，我只需要那个oParent，然后对text和target_room的赋值可以在房间中实例的Creation Code中写呀。是的，的确，但是如果这20个按钮除了这以外还需要执行一些自己独特的代码呢？这样Creation Code就做不到了。
至于这个User Defined 0事件，即用户事件，我们在后面说。
子对象会毫无保留地执行父对象中的相同事件的内容。此处，oChild1到oChild20的Step事件和Draw事件是空白的，因此会自动执行oParent的Step和Draw事件；而因为它们的Create事件不是空白的，覆盖了oParent的Create事件，所以需要一句event_inherited()来执行oParent的Create事件。

下面再来说说用户事件。可能很多新人会很好奇，添加事件的时候，Other分类下的User defined是干什么用的？

就如F1中所说，这些用户定义事件永远不会由GM自己触发。唯一触发这些事件的方法是使用event_perform函数或event_perform_object函数。
那么这些东西有什么用呢？
User defined这里面的User(用户)指的不是玩家，而是开发者。表示这些事件是由开发者自己定义的，而非GM定义的。但是，在GM开发的游戏中绝大部分事件都已经由GM定义并包含了，为什么还需要其他事件呢？其实，用户事件一个很大的用处就是用在父对象与子对象的继承中。
脑补一下，GM引擎在运行的时候，每一帧都会调用每一个object的实例的Step事件，反过来说，即所有object的实例在每一帧都会自动执行由GM引擎定义的Step事件。想想看，这一过程是不是有点眼熟？在上一节中，我们是不是刚讲过子对象会自动执行由父对象定义的对应事件？所以，是否可以把GM引擎视为所有object的父对象？我们假设GM引擎内部这个元素为所有object的父对象，那这个元素定义了所有这些GM内置的事件，Create、Destroy、Step、Draw、Collision等等。也就是说，子对象的事件是父对象定义的。那我们自己的父对象是否也可以给它的子对象定义事件呢？当然可以！这就是用户事件。

同感，对于需要频繁碰撞计算伤害，组队之类的应用很有价值

依然延续上面的类比。
GM为Create事件定义的条件是，当一个object的实例被创建时触发；为Step事件定义的条件是，当一个object的实例在每一帧的时候被触发；为Draw事件定义的条件是，当一个object的实例在每一帧需要更新绘制内容时触发；为Key Pressed事件定义的条件是，当某个键盘按键被按下时触发。当我们使用用户事件的时候，也需要决定其触发条件。
如之前在说父对象的时候20个按钮的例子，在oParent的Step事件中判断条件“鼠标左键按下且光标在范围内”成立，就触发0号用户事件(User Defined 0)。于是乎，虽然我们不能给0号用户事件命名，但是实际上，它可以被称作“选关按钮单击”事件。当然，根据只有子对象才会执行父对象对应事件的原理，在非oParent子对象的object中0号用户事件还是没有意义的空白事件。于是乎，在0号用户事件被触发时，oChild1到oChild20中User Defined 0事件中的代码就会被执行。

再说说事件管理器(Event Manager)思想。
这是个什么东西呢？这不是GM里的一种功能，而是一种思想。大致意思如下：

如图，物体A、B、D有可能会遇到情况X(橙色)，物体B、C有可能会遇到情况Y(绿色)，物体D可能会遇到情况Z(紫色)，而物体E专门用来处理情况X，物体F专门用来处理情况Y，物体G、H均能响应情况Z。此时我们需要一个中介，那就是事件管理器。有了这个中介，就不用让情况X发生时让物体A、B、D自己分别取寻找物体E来处理，也不用让情况Z发生时让物体D自己去分别寻找物体G、H来告诉他们要响应。
----------------------------------------
举个例子，脑补一个突突怪物的游戏，当最后一个小怪死亡时，我们假设发生如下事情：1. 销毁死亡的怪物的实例；2. 左上角的计分板加100分；3. 计分板旁边的击杀数提示增加1；4. 刷出Boss。我们假设计分板、击杀数提示、怪物生成器是3个独立的object。此时，可以这么写：

例子中的情况这样写仿佛并没有什么问题。但是当有很多会死亡的物体(例如，有很多类型但无法完全共用父对象的实体，不但有怪物，还有可以被摧毁的炮台等放置物，可以被摧毁的怪物的盾牌等)，或者死亡之后要执行操作的物体很多（例如还要刷新主角技能，提升主角血量，更改场景元素等）时，这样写就十分麻烦。此时我们就需要一个事件管理器。

我们这样安排这些物体：

我们来解释一下这些东西。首先是oEntityParent，是游戏中所有实体，即可移动的“活物”，的父对象。在Create事件中它声明最大生命值为100，生命值为最大生命值，击杀得分为0。在Step事件中，判断如果实体生命值小于等于0，就触发0号用户事件。
再看继承自oEntityParent的oEnemy。Create事件中首先用event_inherited()自动执行oEntityParent的Create事件，同时还把自己的击杀得分设为120。同时，添加了User Defined 0事件，当被触发(即hp小于等于0)时，销毁自身，并执行一个自定义脚本。这个脚本在后面说。
再看继承自oEntityParent的oTurret。Create事件中首先用event_inherited()自动执行oEntityParent的Create事件，同时还把自己的击杀得分设为70。而且，还声明了一个自有的exists_time变量用来表示炮台在场上剩余的帧数。oTurret的死亡条件由于不同于oEntityParent(因为在场时间清零时也算死亡)，所以重新写Step事件来覆盖oEntityParent的Step事件。
接着是那段自定义脚本event_invoke。

这里面出现了oEventManager，传说中的事件管理器。为了方便理解，我们先看oEventManager再回来看这段脚本。

事实证明，事件管理器object本身并不复杂。我们来看看。sender变量表示事件的触发者，在event_invoke脚本里也体现了，会把调用事件的实例ID赋给sender，这样我们的事件管理器便知道是谁调用了这事件。在这个例子中，常量ev_enemy_die的值等于ev_user0，这样，当oEnemy或oTurret调用event_invoke(ev_enemy_die);时，oEventManager会收到触发死亡事件的敌人或炮台的id，并且自己的0号用户事件会被触发。在此再来执行加分、加击杀技术，如果死亡的是敌人而不是炮台则刷出Boss等。既省事又逻辑清晰。
------------------------------------------------
注：事实上标准的事件管理器中，要接受事件的监听器(Listener)应当自己向事件管理器注册(Register)以使事件管理器在执行某一事件时能通知到对应的监听器。但此处为了简化过程省略了监听器。

顶顶顶

赞一个

666

技术贴是要顶的！

但是我遇到一楼这样的问题一般就会用一个obj完成，然后在房间编辑时给他定义序号