Loadworld DevLog Pt. 2

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!

lodetheboy

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

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
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

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.

gamestep

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.

sample
Until next time,
Z

Advertisements
Loadworld DevLog Pt. 2

8 thoughts on “Loadworld DevLog Pt. 2

  1. Hi, Zack
    Thank you for blog, games and for market assets. The last ones are the best tutorial.
    Small addition about singleton info.
    Checking for singleton with native gml instance functions have some pitfall if one need to activate/deactivate instances. I had to write my own scr_instance_number().
    And what do you think about some possible decreasing productivity when using scripts?

    Like

  2. Michael Harris says:

    Awesome work! I was super excited to see the next installment! I learn so much from you and love the explanation. Keep up the good work!

    Like

  3. eduardosiridakis says:

    Can you put code to be executed after an if statement in GMS using only indentation (like in Python)? The code after if (!_gReleaseBuild) is inside curly brackets but the code after if (kPrev) isn’t. Is it because there’s only an if/else statement after that so it counts as an one-line statement?

    Like

  4. atnik says:

    I should definitely start making a helper script collection as well, as I tend to do everything all over for every project. I use stuff like your Chance() so often, but still don’t have a script for it. 😀

    Like

  5. GerPronouncedGrr says:

    This was not at all what I was expecting from the first (real first) entry in this series, but I found it enlightening. And the fact that I wasn’t expecting it really says more about my level of experience than anything else :p Thanks for doing this, looking forward to keeping up with it!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s