Revision as of 00:07, 7 February 2013
Inheritance is a concept in in object-oriented (OO) programming where one object's code or behavior is reused in another object. Within Game Maker, and related projects, inheritance refers to an Object inheriting entire events and collision behavior from a parent object. If an object does not define a parent object, no behavior is inherited from any other objects. Any number of objects may inherit from a single parent, allowing for an inheritance hierarchy.
In order to use inheritance, you must first have two objects, which will be the parent and the child. In the child object's properties, you simply select the desired parent. Events and behavior will be inherited not just from the immediate parent, but from the parent's parent (if one exists), and their parent, and so on, all the way up to the object which does not define a parent (the root parent).
Note that there must not be a parenting loop - one object K cannot select a parent that already inherits behavior from that object K. For instance, if < denotes inheritance (left inherits from right), and we have objects A, B, C, and A < B < C, then C cannot inherit from A or B, since both of those objects already inherit from C, so it would cause a parenting loop.
Event Inheritance[developer confirmation required]
In Game Maker, and currently lacking from ENIGMA, events defined in a parent object but not defined in a child object will be implicitly inherited. That is, the child object will have the event with the same code. This is implicit, so you will not see it in the Object editor - you must simply recognize it from the fact that a parent is defined.
If it is undesirable for an event to be inherited, for instance, if you want to define your own behavior, or simply do not want the behavior to occur for that specific object (and its children), you may override it by simply explicitly defining the event, and this will cause the event to not be inherited.
If you have an event explicitly defined, but also want to perform the inherited behavior for that event, you may use explicit inheritance, simply by using either the Inherit Event Action, or using the code function event_inherit().
In addition to inheriting events from the parent (such as collision events), any object with a collision event with an object that has children will also have that event triggered by one of the descendents. Note that their sprites and collision masks will still be according to that object's properties, and are not inherited.
For instance, suppose < denotes inheritance (left inherits from right), and that we have objects A, B, C, and K, such that A < B < C. If K defines a collision event for C, then that event will be triggered for any of C's descendents in addition to C itself, so A, B, and C will all trigger the Collision with C event. If K defines a collision event for B, it will trigger for A and B only. Likewise, if K had a child J and defined no events, it would behave exactly the same (with the same collision events triggered by the same objects).
If collision inheritance is undesirable, you will have to add a condition inside the event's actions/code to only handle the specific object, and either ignore or exit otherwise. The following code (and equivalent DND) should get the job done[developer confirmation required]:
As mentioned before, multiple objects can inherit from a single parent, creating an inheritance tree or hierarchy. Normal tree/hierarchy terms apply. For instance, given that < indicates inheritance (left inherits from right), and we have objects A, B, C, D, E, and F, we can say F < D < B < A, E < B, C < A. Note that both D and E inherit from B, and both B and C inherit from C, meaning that A and B have 2 immediate children each. This can be represented graphically as follows;
-- insert graphic of the following rotated 45 degrees --
A - B - D - F \ \ C E
One feature currently lacking in Game Maker and ENIGMA that is usually available in other OO languages is Multiple Inheritance, in which one object may inherit behavior from multiple objects. This would allow a set of objects to exhibit similar behaviors in one context, and another behavior in another context, or where a few objects may have a "drifting" behavior where they may belong to one set of objects in one context and another set of objects in another context.
This could especially be useful in collisions, where a player will interact with one set of platforms, and NPCs will interact with an overlapping set, but not a superset (e.g. some platforms only apply to the player, some platforms only apply to NPCs). Currently such behavior is usually emulated by creating additional collision events for individual platforms, which creates clutter and duplicate code, making the code difficult to maintain.