Looking for a new game-making tool? Writer John Harris celebrates the value and history of video game construction sets, and offers a guide to using one like RPG Maker FES to prototype your own ideas.
There are lots of ways to make computer games.
In the old days, people hand-forged instructions on punch cards, fed them into a reader, and in that way input a program that allowed you to play Tic-Tac-Toe.
Assemblers were common in the 8-bit era, as were grotesquely inefficient interpreted languages like BASIC. C arrived on the scene and became the great default, along with its successor language C++. Nowadays C# sees a lot of popularity, seeing as how it’s used by Unity, but there’s also Javascript, Java, Ruby, Lua, Python, Inform and other things.
One of the more neglected ways to put a game together, these days, is what we might call the construction set package. In the 8-bit era these were more common (and where I got the name from), with popular releases like Pinball Construction Set, Adventure Construction Set, Racing Destruction Set, and Shoot-em-up Construction Kit.
Later there were the Bard’s Tale Construction Set and SSI’s D&D-based Unlimited Adventures, which still has a following to this day. But while less visible now, perhaps, construction sets are still with us, particularly in the form of the RPG Maker series.
(I can’t leave UA without a cursory exploration of that rabbit hole: Here’s an Unlimited Adventures file archive, a collection of adventures based on classic D&D modules, the open source Dungeon Craft UA-workalike adventure editor, and for completeness my own Metafilter post about it. There! Now I can move on.)
The popular appeal to a construction set is that age-old pipe dream of computerdom: enabling people to make something interactive without coding. Programmers often have little idea how appealing this is to the common user. They fail to see what most other people think: learning to code is difficult, time-consuming, obscure and full of traps.
Programming languages can seem designed to gatekeep people unwilling to memorize cryptic commands and syntax. Error messages usually point to the precise space that compilation failed, and only report how it failed, which is frequently unhelpful in determining where the true error lies. Once you’ve learned one language, you find out you really want to use a library only available elsewhere.
In short, learning to code sucks, so the promise of software that allows someone to get by without having to bother with it is great. It’s fueled the rise of things like YoYoGames’ GameMaker Studio product, even though what it provides is actually indistinguishable from coding, just with a drag-and-drop interface. More recent versions even let you drop the DnD stuff altogether and just write text scripts like glob intended. (Lest it seem like I am dumping on GM, I’ve used it for four projects to date, and I can tell you from direct experience that you can make really cool things with it.)
Anyway, GM is not a construction set in the sense that I mean, but more of an integrated IDE. RPG Maker is closer to the ideal of a purpose-built editor geared to produce one particular kind of game, in its case JRPGs in the mold of the 16-bit classics. And even if you aren’t as afeared of coding as some, it can be useful, even to professional game designers, to have a quick way to make an RPG-styled thing in their game design toolbox.
"If you have the hot coal of an awesome idea burning a hole in your cerebellum, it can help to make a toy version of it as quickly as possible...and RPG Maker, in its area, has the advantage of rapid iteration."
For it takes time to make a game, and to make a crazy idea with unusual mechanics takes even longer. If you have the hot coal of an awesome idea burning a hole in your cerebellum, it can help to make a toy version of it as quickly as possible. Often these ideas don’t pan out; the sooner you can test it, and the less energy you expend towards it, the sooner you can find out if there’s actually a diamond in the middle of that coal, or if it’s all ash after all. And RPG Maker, in its area, has the advantage of rapid iteration. Once you’re familiar with its capabilities and know what you can do with it, it’s usually not that hard to make a working model.
For other users, who are coding averse…RPG Maker will not save you from coding entirely. Its events feature is basically scripting by another name. But at least it presents your options in the form of lists, reducing the amount of memorization you have to do. And, although it’s kind of a looked-down-upon genre, people have sold and do sell their RPG Maker productions on Steam.
Because it’s fairly easy to use, this means there’s many products there that seem to be cash grabs, and for a new project, being visible above them and not being dismissed as another poor quality game may be difficult. But some people have managed to do surprising things with it. Maybe you can do something new of your own? Maybe I can help you to do so.
RPG Maker’s been around for quite some time. Wikipedia tells us it dates all the way back to 1992, with RPG TsukÅ«ru Dante 98, for the Japanese PC-9801 microcomputer. PC Gamer published a nice article (by Glada Zavarise) about its rise, how it spread around the Western gaming world through piracy and a series of unofficial fan translations, and how now you can easily buy versions dating back to 2000 through Steam. It also notes that, despite some standout RPG Maker productions like To the Moon, Space Funeral and OFF, the common consensus is that most RPG Maker projects are lazy resource dumps out there just to take your money.
Freebird Games' award-winning To the Moon is a notable example of a game made with RPG Maker
I can report that there is some truth to this. Yet, it need not be so. Packages of pre-made art are a godsend to small and one-person teams, and need not mean that the game itself isn’t interesting.
"Packages of pre-made art are a godsend to small and one-person teams, and need not mean that the game itself isn’t interesting."
Whatever the reasons for coding being a barrier to people who want to make games, it is a fact that it is. Lowering the barriers to production means you’ll get a lot of people throwing something on Steam that they didn’t really put much effort into, but it also means sometimes you get some real gems, amazing pieces of outsider art that are greatly worth your time, that couldn’t have been made without the lowered barrier to entry that it provides.
So then, how do you use a package like RPG Maker well? How do you give your project a leg up over the others? How do you prove to them, to the world, to yourself, that your project is the one in one hundred that justifies the genre?
I’ve toyed around with RPG Maker a bit. And I’ve had some – just a little – experience in the past with getting around the limitations of construction kit software. Now, I don’t claim to be an expert. All I can offer is the process I have used in the past, my research, and whatever communication skills I have in relaying them to you. May they serve you well.
RPG Maker FES, for the Nintendo 3DS, is the most recent release in the series. The most popular RPG Maker titles have been those on PC, which are generally easy to use and also permit the use of outside tools for creating resources. By contrast, console releases like this one put strict limitations on memory use, often limiting (or even restricting) your ability to create your own visual and audio content, and are generally a narrow sieve into which to poor your ideas. For our purposes, to examine the process of finding out ways to get around toolset limitations, that’s perfect.
Knowing how it’s limited is the first step in overcoming those limits. RPG Maker FES, running entirely on a 3DS, has some fairly drastic limits compared to the PC version, but you can do some nice things with it once you understand where the borders are.
It is rare that the documentation for a product explicitly tells you what can’t be done with it. Limitations are left, like dog poop in tall grass, for you to happen upon unexpectedly, sometimes letting you get halfway through implementing a promising game mechanic to discover that it’s been impossible all along. This happens frequently with this kind of thing, and I don’t think there is a way to avoid it completely, except to know as much as you can about the software’s limitations going in. Since the software won’t tell you what those limits are, that requires research. To the Google mines!
Through experimentation, reading the game’s built-in manual (which is not very helpful), and a fair amount of web searching, I’ve been able to determine these facts about RPG Maker FES’ capabilities, which I list here, along with ways to make up for them.
Map sizes
All the RPG Maker systems use 2D maps along the lines of classic 16-bit JRPGs. FES supports three sizes of map: 32, 64 or 128 tiles square. For comparison’s sake, 128x128 is smaller than the world map of the first Dragon Quest.
The system supports up to 100 maps in each game however, so creators may be able to get by by joining them together.
Art and music
This one’s huge: There’s absolutely no way to bring your own resources into a project. You are limited to the character and monster art, map tiles, effects, sounds and music included in the software and DLC. Over time, publisher NIS has updated FES with additional resources to put into your games. And there’s a good variety of tiles to choose from. You can even mix tiles from different sets, like including sci-fi and modern graphics in your fantasy game.
Still, this means, if you play a lot of FES projects, you’re going to see the same graphics again and again. The fact that some are paid DLC means that those resources will be less commonly encountered, but still, because the maximum available art and audio is limited, there is only so much you can do with it. Your characters can only look like one of the included choices, and only a small fraction look like typical JRPG heroes. Meaning, get used to Spiky Blonde-Haired Anime Guy, because he’s going to be starring in a lot of adventures.
But in one way, this is a blessing. Because you cannot have character art that’s not provided for you, you aren’t expected to have it. Your game cannot be accused of using default assets, because everyone has to use them! While that’s unfortunate, it does take the most time and effort-consuming parts of creating a game off your hands.
What can you do to alleviate this? Well, you can focus on characters other than the standard anime hero and heroine types. You can tell the story of the monocled elderly guy on the third row of the graphic selector, who for some reason has decided to spend his declining years beating up slimes. And you can change things up and use heroes from different graphic sets, which FES has no issue with.
That can be especially useful for monsters, which are less restricted by their time period—remember, even the original Final Fantasy had a technological dungeon.
Map components
We’re starting to dive a bit deeper now. RPG Maker FES’ model divides maps into three kinds of entities.
There’s terrain tiles, which are the ground beneath everything. Every tile in every map has a terrain. Importantly, while you can block passable terrain with other things to prevent intrusion, impassible terrain can never be moved through by means of just walking. (There are vehicles available you can use to allow players to move over them.)
There’s decoration tiles, which can be laid, in multiple layers even, atop of the terrain. These can also block movement; they’re not just for show. Importantly, when you use the Erase tool, you always take the top tile off the decorations stacked on a space first. Once all the decorations are gone, the next erase will reset the terrain in a spot to default. You can set these tiles to passable or impassable, unlike terrain tiles, of which, if they are impassible, are always so.
Finally, and importantly, there are events. Events are literally everything else on your maps that is not the hero’s party! They’re all called events, even though some things, like your standard bump-walking, info-giving NPC, might not seem like they fit the term. Whatever it is, if it has some effect, even if invisible, it’s an event. Events are all your NPCs, transitions between areas, treasure boxes, shops, inns and any set monster encounters. Many of these kinds of events actually have pre-made versions included (under “Easy create”), that will fill in the right instructions for you. You can learn a bit by taking one of those events, like Treasure Chest, making one and then examining it. But if you create your own events, you can do a lot more.
You can change the contents of a treasure box according to situation. You can offer different shops based on who’s in the party. You can create complex NPCs that say up to 10 different things, depending on where the player is in the game. You can randomize important parts of the game, to improve replayability. And you can discard FES’ standard random encounter system, offering visible monsters wandering around the map that may attack you if you get close. (For an example of how to do that, keep reading.)
Building interesting events
Doing cool things in RPG Maker FES is largely the process of learning how to use events to maximum effectiveness. Events, for all their usefulness, have some pretty glaring drawbacks. There can only be, at most, one event on a space at design-time. And at run-time, events cannot ever be created nor destroyed. Although an event can trigger combat, once the player defeats the monster, the event is still where it was. There is no way to delete it, so without special consideration, the combat could immediately be triggered again. This is where coding, inevitably, comes into play.
Every event has a number of basic properties that provides some default behavior, like walking around randomly or whether the player can pass through it. If the default behavior is enough, you don’t have to do anything else to it. But to do things more complex than that, you’ll have to put in what FES calls “contents.”
Basically, these contents are instructions. Each event can have up to ten “pages” of them. These pages are not just an organizing system, but are how you vary the workings of an event, how you give the event the circumstances under which different sets of instructions will execute.
For every event, you must define under what circumstances it activates. The options are:
“When character touches” means when the player’s party tries to enter the space containing the event. That is to say, that’s what causes the event to evaluate and perform instructions. (Exactly what instructions are performed can vary, but we’ll get to that.) Note that, if the event is set so that “Pass judgement” is off, the player will not collide with the event and will step into its space. In this case, the event will occur when the player has fully moved into its space.
“When touched by event” is similar, but it is the event that must perform the colliding movement.
“Investigate” requires that the party be facing the event in an adjacent space and that the player must press the “A” button. This has a plethora of uses: you can use it to initiate conversations, open treasure boxes, search for items or clues, flip switches or open a shop window.
“Use item” is a little esoteric. Over in the Item database, you can create “Normal” items that the player can Use but that have no effect. This is as opposed to “Special” ones that you define with an effect, like healing a character or attacking opponents. So then, what is the purpose of “Normal” items? Well, you can set an event to occur if the player uses an item “on” the event. (Yeah, that’s a pretty rare occurrence. I do not know why this infrequently-used behavior gets the honor of being called normal.) Once set, it will allow you to specify which item the player must use to activate the event.
The final option, “Auto-execute,” means that the event triggers constantly while the player is on that map. It doesn’t matter how close the party is, or if the event is even on the same screen of the map. Every frame that the map is loaded (and another event isn’t already running), the event will activate! It is very powerful, but tricky to use. When an Auto-execute event performs any instruction, the map engine will ignore controller input on that frame. Meaning, unless constructed just right, even one Auto-execute event will softlock the game.
Note: different versions of RPG Maker share a few design aspects. Some PC versions add another option to run events, “Parallel,” which provides this automatic activation without soft-locking the game.
When an event activates, it then picks one of its content pages to run. All events have at least a Page 1, which is the fallback. Every other event page can have up to two conditions tied to it. When an event executes, the engine starts at the highest page number that exists (10 if there is one, then 9, then 8, etc.) and checks its conditions. When it finds a page both with contents and whose conditions are satisfied, it, and only that page, will execute. If the page’s conditions aren’t met, it’ll go to the next-lowest page number and try that one. If it reaches Page 1, it always executes. It only executes one page per event; once it finds and runs a page, execution ceases until the event is triggered again.
(In order to use Auto-execute, you must make sure that Page 1 is empty. Since it always executes, the event will always occur and block out anything the player tries to do.)
Here is a minor nuance. The engine is constantly checking those event conditions for all your events, every frame, even when they’re not executing. You see, each page of an event contains more than just a list of instructions, but also a set of properties for that event, like its graphic, whether it can be walked through, and so on. These properties affect how the event behaves as its conditions are met, even when it’s not running. With some thought, you can use this to adjust behavior dynamically, without executing any of its instructions.
In the example project (see below), we use this property to reset all the wandering monsters at once, whenever we like. The only thing in its system that records whether an event monster has been fought or not is the state of one of 500 built-in switches. When we fight a monster, that event’s numbered switch is set. That causes the second page of the wandering monster event to activate. And that causes the event’s graphic to be replaced with nothing, and causes it to no longer attack the player (Page 2 has no combat content), and it also sets the flag that allows the party to walk through it. When you leave the area, or use the healing spot near the entrance to the dungeon, an event sets all the switches from 0 to 100, the ones we reserve to track wandering monster state, to off. This immediately re-activates the monsters we already fought before, not only causing them to fight the player again, but making then visible and causing them to block movement.
What can't you do
So, what can FES’ scripting system not do? Well, quite a bit unfortunately:
Once the game is running, there is no way to add or delete events. The best you can do is set the event to make itself invisible (set its visibility to “transparent”) and execute no contents when a condition (usually a switch) has been met.
There is no way to expose an object’s coordinates to the scripting system, so you can’t set an event to detect when the player is nearby, only through collision.
There’s no way to do automated “cutscene” battles in the game’s engine.
There is no string functionality. The only variable types are Boolean (in the form of “switches”) and integer (“variables”). A side effect of this is that, while it’s possible through events to let a player change a character’s name, they cannot pick an arbitrary name. It has to be an option that you provide for them. You can, however, set some item and enemy statistics to point to an integer variable, allowing scripts to adjust them during the game.
Randomness, that’s visible to the event engine, is quite lacking. There is no system to easily assign a random number to a variable. There are ways round this, but they’re a lot of work.
Speaking of a lot of work… All scripts live with their event at its given location in the game world. You can copy an event to make a duplicate copy of its scripts, but you cannot “link” to it. So if you make 52 copies of an event so they’ll all do the same thing, but then find an error in the script, you’ll have to go through and make the changes to all the copies. So my suggestion is, first make one copy of the event and then test the hell out of it. Make absolutely sure it does what you want. I suggest making a backup save of your project at that point. Then, only when you’re pretty sure you won’t need to fix any bugs, start copying the event to all the places where you’ll need it. Honestly, you’ll probably still have to edit it later, if just to customize the individual instances (like, cause each event to have a different appearance and produce a different monster fight), but you can at least reduce the number of times you have to do it.
A wandering monster system for RPG Maker FES
Using all of the information above, and about 13 hours of grunt-work according to the timer, I have constructed a simple example project in RPG Maker FES. It’s mostly a single map dungeon filled with wandering monsters roaming around. The system expects most monster fights to be “random,” meaning, your party is attacked out of the blue by unseen assailants; letting the player see his opponents on the map screen lets them decide if they want to risk getting into a fight or not, adding more strategy to the game.
You choose which of three characters you want to take into the dungeon, then build their levels up by carefully choosing which enemies to fight. Starting with slimes, work your way up through goblins, floaty things, angry fungus, demon girls, giant spiders and mean ol’ orcs, finding treasure along the way.
You can heal your character up at any time by visiting the healing spot near the dungeon’s entrance, but doing this will revive all the monsters you’ve already killed! But that can be a good thing, since it gives you the chance to earn more experience points. Healing there also gives you the chance to save. When you think your level is high enough, leave the dungeon and try to fight the boss orc to win the game. You can turn on an in-game timer (that, due to engine limitations, only counts up outside of battle) to find out how long you’ve taken on your run.
The design of the game is “unlocked,” that is, you can open it in the full version of RPG Maker FES and look at how I put it together. Or, if you just want to play it, it can be downloaded using ID ci9u6rkm from within the free RPG Maker FES player available on the 3DS eShop.
If you decide to implement such a system in your own game, my suggestion is to devote a block of 100 switches to the random monsters, and reset the whole block when leaving an area. In my game there’s only one dungeon so it’s not a huge deal, but if you have multiple areas, those 500 switches will run out fast. So instead of giving every monster in the whole of the game its own switch, you can reuse them in each dungeon, so long as you don’t go over the number of switches you’ve reserved. This means that leaving an area will reset all the monsters in it, but you can’t have everything.
Sources
The built-in manual for RPG Maker FES, although it is woefully incomplete.
The RPG Maker FES GameFAQs board. There’s a lot of good information there.
A lot of experimentation on my behalf.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
