Good evening, friends!

This is part two of the Loadworld development blog and the first official day of development! I will be honest, I have toyed around with Zelda-like ‘engines’ in the past and have a handful of helper scripts that I drop into all of my Game Maker Studio projects, so I’d like to take this entry to cover some of that stuff. It might be a little dry, but I hope that someone out there finds it helpful!

Helper Scripts

Whenever I open a new Game Maker Studio project, I typically drag a dozen or so of the same scripts into the folder. These are generic scripts that I use for comparing values and other simple, but extremely common operations. I’ll go over a few of the staples.

IsAny() compares the first argument against the following ‘n’ arguments. It returns true if the first argument is the same as any of the other arguments. This just makes things a bit more readable for me and can shorten code in some situations.

Checking if a state is one of several….
if (IsAny(_state, STATE_STUNNED, STATE_DEAD)) { _canMove = false; }

Checking if one of many conditions is true…
if (IsAny(true, flag1, flag2)) { // do thing }

Chance() accepts a percentage as an argument, and the odds of it returning true are that argument out of one-hundred. I use this all of the time. Everywhere.

10% this will return true…
Chance(10);

90% chance this will return true…
Chance(90);

Singleton() is a design pattern that isn’t really available in Game Maker, nor is it entirely necessary, but I’ll take the time to discuss it anyway. A singleton is an object that you want to have one of throughout the duration of your application’s run time. This script is called in the CREATE EVENT of the object that you want to only have one of. If you try to create a second copy of that object_index, the object will immediately destroy itself.

The Game Object

ALL of my projects start with the creation of ‘oGame’. This object is a controller that will eventually hold information like the map and availability of different items in your inventory, draw the HUD elements, and store a bunch of save file information. This object is marked as persistent in the editor. This means that the object will continue to exist even when you switch between rooms and/or views. Due to this, we will never need more than one copy of ‘oGame’; that is where the Singleton() comes in. I call Singleton() at the beginning of the CREATE EVENT for ‘oGame’ so that we never attempt to have two copies of globally used variables or accidentally write over save file information with a second instance.

I also use ‘oGame’ for debug functionality. For now, I will keep it simple. I implemented hot keys for restarting the game, closing the game, and easily moving between different rooms. To make things easier later, I put in a flag that tells me whether or not we are dealing with a release build. Wrap all of your debug code with a check for that flag so that we don’t have to hunt down and delete all of that code later.

I took some old code and played around with some sample movement. Next week we will take a look at the sample player code and fine-tune it for what we will need in Loadworld. For now, here is a GIF with some placeholder assets.

Until next time,
Z