5 Ways Shade Hunters Uses Scripting and Why You Should Too
I’ve gotten questions about RPGMaker and what it can do for you as a game developer, especially at your career’s spawn point.
RPGMaker has the potential to be a terrific entry engine. It’s both a high-floor and low-ceiling engine, in a way. It’s low-ceiling because you can only create tile-based games with it, though some devs have pushed its limits and there’s a lot of room for visual creativity. But it’s high-floor in that you can program actions, build maps, import assets, design combat, etc. with RPGMaker’s system of basic commands, without having to build the underlying systems for them; they’re already there. If you’re good with logic and sequence, you can, in theory, create a great game without ever knowing a lick of code.
However, the engine also carries severe, sometimes silly limitations that make simple tasks complex. That’s why RPGMaker’s script tool is valuable. It integrates your manual code into the game and lets you execute simple tasks (or better said, tasks that are simple if you know code) that would otherwise be either impossible, taxing on performance, or just hopelessly unwieldy in this engine. (In the case of RPGMaker MZ, the version in which Shade Hunters was made, you would use Javascript.)
Here are a few tasks that scripts make life dramatically easier for us while making the game.
1. Creating events that react to the player
We wanted the security cameras in our game to follow the player, one of several small things we like to pay attention to.
In the picture below, the lefthand column shows how the logic would have to be planned out with just RPG’s top-level commands, while the right-hand column shows it done with a script. Both versions were tested and perform identically.
The lefthand version is awful for a number of reasons. For one thing, it’s far longer because RPGMaker only allows one math operation per line. You might also be able to spot the placeholder variable being used as an intermediate step in the math. Again, because of this engine limitation, you can’t modify X and use the new value but then use X’s previous value elsewhere; you’ve changed X in memory.
Because the lefthand version is longer, it’s harder to trace the logic and figure out what it’s doing. Imagine coming back to this event after a few months once you’ve forgotten how it works, or if it was written by someone else. The ability to quickly grasp the function of a slice of logic is a huge element of a programmer’s job, so best practice to write not only working logic, but readable logic.
Then consider the long-term implications. You’re using five engine variables in there. Are you going to reuse them in the next map? You’ll need to track what each does and wipe them at map’s end, and make sure no other events on that map (or anywhere else) use thosevariables. You could just use different variables on the next map, but now you’re talking about hundreds, possibly thousands of engine variables. No thanks. (As of this writing, Shade Hunters uses 97.) Either way, you’re skyrocketing your game’s complexity.
The righthand version looks intimidating, but that’s because you don’t know the engine’s script calls - and there happens to be an online resource for that. After that, you’re an understanding of variable usage and if-else statements away from writing code like this - a day’s worth of online courses. (I could have done with five lines of code instead of eight, but I drew it out a bit for readability.) Scripting is thus more desirable because it lets you declare temporary variables, perform multiple operations on one line, and then toss them.
Similar code is used in Shade Hunters for damage sources like fire and radiation clouds, NPCs that turn to face you, map enemies that rush you when you approach- basically anywhere we wanted something to react to the player’s position and/or distance.
2. Gaining random items
RPGMaker has a RNG (random number generator) that you can use for certain things, but again, the engine’s limitations often require you to be hilariously inelegant if you’re using the basic commands.
For example, since our game is a roguelike, opening a specific chest nets you a random item. Obviously the RNG is an ideal tool for deciding which item the player gets. But here’s how we’d have to work it using basic commands versus using a script:
The scripting is less code, less time reading for someone else, and less work if changes are needed later. Imagine if all the item numbers need shifted by just 1 for some reason; that’s a lot of irritating busywork on the lefthand side. Instead, use a script, and all you need to know is which inventory locations the RNG should target (1-6 in this case, which a simple comment can tell the next guy).
This is the simplest of tasks for which we used the RNG. Shade Hunters uses randomization for map selection, puzzles, crafting, skill discovery, and more, and it’s served us well to use scripts so that we can pass random numbers as arguments, as is done above.
3. Using better grammar
When a player gains an item, a message informs you of what you’ve gained. Problem is, some items’ names begin with a vowel, and it’s bad grammar to display “You got a Action Gem!” instead of “You got an Action Gem!” We wanted to avoid this issue.
RPGMaker’s basic commands only allow you to store integers in an engine variable; if you want to store a text string, you need a script. We wrote one that populates an array - a list of items stored as one variable - with item names that start with a vowel. It then checks if the earned item is one of these, and if so, concatenates an “n” onto the “a” to form the word “an”.
A simple task, but important to us.
4. Tracking unlocked secret areas
Engine variables themselves can be declared as arrays in RPGMaker, but you have to use a script. To track how many of the game’s 15 secret areas the player has unlocked, the game declares an array in an engine variable at game start that contains the IDs of the maps containing secret areas (no, we won’t spoil it for you with a screenshot!). When a secret is unlocked, the ID of its map is removed from that array. At game’s end, it counts how many map IDs, and thus how many undiscovered secrets, remain.
We use a similar technique to ensure that a player is not randomly given the same map twice in a playthrough, or that the gem selector roulette doesn’t flash through the same item twice in a row (boring!), or in a number of other things.
5. Programming cutscenes and “sidestep” events
Shade Hunters features cutscenes of varying complexity, some pretty elaborate, that require careful timing of dialogue, event movement, picture swaps, visual and sound effects, and environmental changes. In order for certain things to fire, you need triggers. You can use engine switches as triggers and set other events to “watch” for them, but it explodes the number of switches needed for the game. One particularly chaotic cutscene (you’ll know it when you see it) used to feature 18 separate switches being thrown from a controller event. It isn’t the best use of resources to reserve so many switches for just one scene, and if you want to reuse them elsewhere, you have to make sure they’re reset at scene’s end and track them throughout the game and…yeah, no bueno.
Scripts provide an alternative: self-switches. Every event in the game can carry multiple event pages and the engine allows for four self-switches that an event can use to jump itself between pages. But it can only change its own self-switches, at least by using the game’s basic commands. Scripts let you change one event’s self-switch from a different event. This way, one event can control numerous other events - even events in other maps! - without the need for a thousand switches.
Self-switches in scripts also came in handy when we started implementing “sidestep” events - events that move the player into secret areas or puzzle maps and then back to the original map in the same position and game situation. We realized that if you leave a map and come back, all its events respawn, even if they’d been previously erased via player interaction (looted chests, defeated enemies, etc.). That created an exploit by giving a player second crack at that map’s goodies, throwing off the game’s progression and balance.
So we learned to “return-proof” any map that contained such a sidestep event by installing self-switches in all its enemies and items. When used or defeated, instead of the Erase Event command, these events’ self-switches would switch to an empty page, no longer visible or interactable by the player once they returned. And the thing was, sometimes we needed to throw those self-switches from a different map using a different event. Scripts let us do this.
This is all novice stuff, but I hope it gives a good insight on how the use of scripts and the learning of code opens up more complex and interesting gameplay elements. This is what helps good RPGMaker products stand out. The engine is notorious for “asset flips” in which a dev slaps things together into a simplistic, cookie-cutter experience and tosses it onto Steam for a quick buck. Use RPGMaker instead as a stepping stone to higher things by taking the opportunity to learn code and tackle tougher goals. You won’t regret it.
Shade Hunters is available now on Steam and Google Play!