Gw Temp

Menu

Tutorial - 'General Custom Systems Tutorial' by Rast

An item about RPGMaker 2000 posted on

Blurb

In this tutorial, Rast teaches how to design, implement, and debug your own custom systems. No more begging for tutorials!

Body

I look at the GW forums a lot, and I'm see people on a daily basis ask for tutorials on things that could be easily done themselves, usually in just a few minutes. So, I've decided to make a general tut on how to design, create, and debug your great idea for a custom system, whether simple or complex.

The first thing you need to do when creating your own system is to decide, exactly, what you need. Create a text file, and jot down your basic ideas. This text file is important, it will hold all your notes on your system as you make it. I've included a recent one of mine that's at the bottom of this message (please don't steal my minigame - this is here for your reference only).

Next, still in your text file, look at what you need, and decide what switches and variables you'll need to make it happen. Create a list of both switches and variables. I suggest you precede each with a colon (:), you'll put the actual switch or variable number in front of the colon later. This will make it easier to find the switch or variable when you're actually making it later and refering to your notes.

For your switches, they're either on or off. When you're typing up what the switch is, make sure to notate what the switch does when it is on. If it does something different when its off, be sure to write that down too.

Variables are a little different. There's basically two types of variables that you'll use in a custom system of any sort - control codes and values.

A value variable is a variable that holds a number that represents a quantity, an amount, a number, anything where any value represents varying levels of the same thing. Examples of value variables might be the party's gold, a timer value, the number of steps taken, etc. When you write these down in your text file, write down what value the value variable is representing. If there are any 'special' values that mean something special (such as -1 meaning that the variable is uninitialized, something I use a lot), be sure to notate those too.

A control code variable is a variable where every value means something different, and the variable can only be one of a set of predefined values. Examples of control code variables would be things like, say, message box style, minigame difficulty, or a choice in custom menu. When you write down these kinds of variables, notate what each value means.

Next, still in your text file, write down a detailed description of exactly how your custom system will work. Use pseudoscript or short lines of text that detail simple operations (e.g. "Adds 1 to the cycle counter" and not "It runs through the whole list and sets up the room based on the settings"). While you do not need to have a 1 to 1 correspondance between lines in your detailed description and lines of script in RPGMaker, it does need to be simple enough that you can do it in RPGMaker without having to stop and do design work again to make it work.

Take as long as you need on this step. Run through it logically and make sure it works in your head. You want this detailed description to describe your entire system. If you add or change any switches or variables (which you will), be sure to notate the changes in your switch and variable list that way you don't confuse yourself later.

Now that all that's done, you're ready to make your system in RPGMaker. By now this should be a snap - you already have a clear idea of what's involved and how it will work. Create your switches and variables you outlines earlier first (be sure to fill in the blanks you left for their numbers), then go through and create all the events you just designed. You shouldn't have to stop and think very much during the step, but if you find you need to go back and do some rework, be sure to notate what you're changing in your design document.

Now test play your game and test your system. Unless your a god or just really lucky, it probably won't work right, if it all. Now it's time to do some debugging!

You can define bug categories in millions of different ways, but I like to group them into these categories: lock-ups, bad values, and bad logic. I'll define them first, and then go over some of the more frequent methods I use to track them down.

A lock-up is just what it sounds like. The game freezes and won't continue. These are almost always caused by your game getting stuck in a loop of some sort, normally either a cycle or an autostart event. When you start debugging, investigate these areas first.

A bad value bug in when a value variable ends up holding an incorrect value, and every calculation down the line that uses that value gets muddled up. When all is said and done, you see a strange output that makes little (if you're lucky) or no sense at all. These bugs are usually caused by muck-ups in your "Change Variable" events. Trace through your script and identify the point at which the value gets messed up and investiage there.

And last, but not least, a bad logic bug happens when your script logic goes screwy and does something unexpected. This bug manifests itself as the script doing something it logically should not do, which might be as simple as someone giving a "No" answer when you chose "Yes" to something completely off the wall. This type of bug will often appear to be one of the two preceeding types.

Now for the fun part - you get to fix it! To do this, I suggest you use my debugging method, which I call two-finger troubleshooting.

In your script or design document, identify last location where you know the script was working properly (we'll call this the Last Known Good Point, or LKGP for short). Put your finger there. Now, identify the first location where you know the script was working improperly (and we'll call this the First Known Bad Point, or FKBP for short). Put another finger there. You have now isolated the error to the script inbetween your fingers.

Investigate the script in question in RPGMaker. Oftentimes the error will pop right out at you, and you'll slap your forehead and say "Wow, that was dumb" and fix it. But, if you can't find the error, or if the block of script in question is quite large, you need to further isolate it.

To do this, find a good spot to check your variable and switch values that's as near to the halfway point of the block of script in question as possible. This part is up to you, you'll get the hang of it fast enough.

Next, stick in a "Show Message" command. For its text, give it something like "Debug 1" or some other text that lets you know that this is your breakpoint.

Now, test play your game. When you see your debug message appear, press F9 to bring up the debugger. You'll see all your switches and variables. Examine the relevant ones to see if they are correct. If they're wrong, you have a new FKBP. If they're right, you have a new LKGP. Press ALT-F4 to quit out of your game, and repeat this whole process. Eventually you will narrow your problem down to the faulty script and you can then fix it.

Voila - your custom system is done! That wasn't so hard, now was it? But, there's still a couple more things I want to go over that may make your life a little easier. There's a couple more things I want to go over though that will make your life easier.

The first is the debugger, that thing that appears when you press F9 when in testplay. This screen is your friend. In addition to helping you isolate faults in your script, you can also use it to change your switches and variables on the fly. This allows you inject known inputs into your script. You can then examine the outputs to verify the script is working properly.

Next, if you are creating a large and/or complex minigame, you may want to create special debug modes that are activated by switches that the player can't normally access. You can turn these switches on through the debugger (an example of this in the Reveal Map switch, below, in the example design document). These special modes should allow you to examine the minigame in a format that's easy to digest. These can go a LONG way toward making debugging easier if your custom system is very large and/or complex.

I hope everyone who comes here trying to find out how to create their own custom widget finds this useful. I'm just trying to help you help yourself.