08.11.2012 Views

Designing Games with Game Maker - YoYo Games

Designing Games with Game Maker - YoYo Games

Designing Games with Game Maker - YoYo Games

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Persistent objects<br />

Secondly, you can make an object persistent. A persistent object will continue existing when<br />

you move from one room to the next. It only disappears when you explicitly destroy it. So you<br />

only need to put an instance of the object in the first room and then it will remain available in<br />

all rooms. This is great when you have a main character that moves from room to room. Using<br />

persistent objects is a powerful mechanism but also one that easily leads to errors.<br />

Parents<br />

Every object can have a parent object. When an object has a parent, it inherits the behavior of<br />

the parent. Stated differently, the object is a sort of special case of the parent object. For<br />

example, if you have 4 different balls, named ball1, ball2, ball3 and ball4, which all behave the<br />

same but have a different sprite, you can make ball1 the parent of the other three. Now you<br />

only need to specify events for ball1. The others will inherit the events and behave exactly the<br />

same way. Also, when you apply actions to instances of the parent object they will also be<br />

applied to the children. So, for example, if you destroy all ball1 instances the ball2, ball3, and<br />

ball4 instances will also be destroyed. This saves a lot of work.<br />

Often, objects should behave almost identically but there will be some small differences. For<br />

example, one monster might move up and down and the other left and right. For the rest they<br />

have exactly the same behavior. In this case almost all events should have the same actions<br />

but one or two might be different. Again we can make one object the parent of the other. But<br />

in this case we also define certain events for the child object. These events "override" the<br />

parent events. So whenever an event for the child object contains actions, these are executed<br />

instead of the event of the parent. If you also want to execute the parent event you can call<br />

the so-called "inherited" event using the appropriate action.<br />

It is actually good practice in such cases to create one base object. This base object contains<br />

all the default behavior but is never used in the game. All actual objects have this base object<br />

as parent. Parent objects can again have parents, and so on. (Obviously you are not allowed<br />

to create cycles.) In this way you can create an object hierarchy. This is extremely useful to<br />

keep your game structured and you are strongly advised to learn to use this mechanism.<br />

There is also a second use of the parent object. It also inherits the collision behavior for other<br />

objects. Let us explain this <strong>with</strong> an example. Assume you have four different floor objects.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!