Hanging around: Event sheets

The event sheets. It’s here that the inner working of the game are constructed. It’s also where all the crippling bugs will be hiding. Let’s take a closer look.

I can't promise that it's any more interesting at full size, but feel free to look.

Boxes! Words! Confusion!

So, here’s an event sheet. I’ve cropped off the rest of the UI and just left the events themselves, which I’ll go through in a moment. Event sheets are essentially reusable chunks of code – we set each of our layouts (levels) up to include any necessary event sheets. This saves us duplicating code for every new level, and means we only call code that’s needed for each layout – no point putting a load of enemy AI code onto our title screen, for instance.

The above image is the entire code for grabbing at the edge of a platform. It’s contained in the “Player Movement” event sheet, where we’ll store most of the code for player movement beyond the default stuff that the Platform Behaviour does for us anyway. It’s also in its own Event Group called “Edge Grab” – Event groups are useful because they can be switched on and off at runtime. If we ever want to take away the player’s ability to edge grab, we can simply turn this off. It also keeps the events sheets much neater and tidier to work with.

Let’s run through this line by line. The first event sets two new objects to always follow our PlayerBox – one ‘tick’ is one pass of the event sheet, so every time the playerbox is updated, so to are our new detectors. In order to be nice and clear, they’re called PlayerEdgeDetectLeft and PlayerEdgeDetectRight. This way, I’ll hopefully not forget that these are important.

The next two lines are a series of conditions used to check if the player should grab a ledge. The first condition reads “is falling”. This is a check to make sure that the player object is in the air and is falling downwards. The next condition checks to see if one of our detectors is overlapping an object with the “solid” attribute. If it is, the game knows the player is next to a wall, but does not yet know the extent of that wall.

We’re only interested in seeing if the player is at the top of a wall or solid object, and this is where our third condition comes in. “Overlapping at offset” is a simple check run by the game to see if a collision would be triggered at a certain point from an object. In this case, the game checks to see if PlayerEdgeDetect would trigger a collision three pixels above itself (0,-3). If this did trigger a collision, then we know the player is not at the top of the “solid” object. So in order to run this event when this condition is false, we’ve inverted the condition (note the =/= symbol).

So now, if the EdgeDetect is in a wall, but the offset above it is not, the game registers this as the top of a solid object and responds accordingly by setting one of PlayerBox’s private variable, “grabbing edge”, to 1. Private Variables are stored numbers or strings you specify within an object. In this case, we’re using a number – When “grabbing edge” is 1, the player is holding an edge. When “grabbing edge” is 0, he isn’t.

This may help explain the edge detection process better than words. Or it might not.

The final condition, “trigger once” means that the actions, or outcomes, of the event, are only run once while these conditions remain true. Once one of these conditions is false, the event can be run again. This simply prevents us getting stuck on the wall when we try to dismount.

We’ll now use our “grabbing edge” variable as a condition in event 4. When “grabbing edge” is 1, we do not want the player to fall to the ground or be able to move freely – so we’ve forced his x and y speed (a value measured in pixels per second) to 0. Our PlayerBox now hangs from a ledge when the necessary conditions are met. Our final two events deal with dismounting the wall. For now, there are two ways to do this – By jumping off or dropping down.

And that’s pretty much it. I suspect there will be updates to this code in the future – we might want more ways to get off the wall, for example. We might also want to make some ledges impossible to grab, so we’d need an extra condition check in events 2 and 3 for that. But it works nicely for now, and it’ll be easy enough to expand when we need to.

Don’t expect me to do this with all the code, as we’d probably die of boredom before then, but I’ll probably post up examples like this from time to time. Who knows, someone may even find them useful tutorials or something. Feel free to make use of any events I post up here, by the by.

Next time, I talk about the necessity of having at least two jetpacks in the game.

Advertisement