One of the most powerful options within the object properties is
the ability to assign a parent. Every object in the game can have a
parent object, but what does this mean? Well, when an object has a
parent, it can share code, actions and events with that parent.
This is called "inheritance" and an object that has a parent is
called a "child". But that's not all! You can also do checks and
run code on parent objects which automatically include the child
objects too which saves a lot of time and energy. Another way to
look at a parent object is as a way to "group" objects together
under the same umbrella and have them share certain things without
loosing their own identity. Now, this may seem a bit complicated to
understand so let's give some examples:
Say you have a player object and four different enemy objects. Now,
you want the player to die if he touches any of these four objects
and this would normally entail four collision events with four sets
of actions or code, one for each of the enemy objects. BUT if we
make a parent object for all the enemies, then we can create
one collision event with the parent object only and it will
trigger no matter which one of the four "child" enemy objects touch
the player. Handy stuff! In the actual GameMaker: Studio
object you would see something like this:
Another example would be if you have a game where you want to
create 10 different objects and have them behave in the same way.
Well you would create one parent object and in that have all your
behaviour actions or code, and then you would create your ten
objects with no actions or code, but different sprites, and assign
them your parent object. Now, when you place these instances in a
room they will all behave the same, but look different.
Finally you can use parenting to "mix and match" events and
behaviours. Say you want two monsters: one that moves up and down,
while another that move left and right, but you also want the two
of them to have the same health and shoot at the player. In this
case you can see that almost all events should have the same
actions except for one or two that govern movement. So, again, we
can make one object the parent of the other, but in this case we
also define certain events for the child object. These events
"override" the parent events, meaning that whenever an event for
the child object contains actions, these are executed instead of
the actions contained in the event of the parent. If you also want
to execute the parent event you can call the so-called "inherited"
event using the appropriate action or code.
As indicated, wherever you use a parent object, this also implies
the descendants (or "children"). This happens when, in an action,
you indicate that the action must be applied to instances of a
certain object. It also happens when you use the with()
statement in code (see further on in the manual), and it works when
you call code functions like instance_position,
instance_number, etc... Finally, it works when you refer
to variables in other objects too, like, in the above monster
example, if I set the monster 1 speed to 10, then the monster 2
speed will also go to ten as it is a child object of monster 1.
It is actually good practice in most cases to create one base
parent object and have this base object contain all the default
behavior but never use it in the game. Rather use all the
children objects and only use the parent in situations like those I
have outlined above. You should also realise that parents can have
parents too! Obviously you can't create a cycle of "parent1 is
child of parent 2 is child of parent 1" but you can create what is
called "object hierarchy" where "parent1 is child of parent2 is
child of parent3". This is extremely useful to keep your game
structured and you are strongly advised to learn to use this
mechanism.
Now you can see why parenting can really save a lot of time and
work, and why it is one of the most useful tools in the GameMaker
arsenal. So take your time to get to know this function as it will
really help you in the long run!