Gw Temp

Menu

Tutorial - 'CMS Tutorial, Part 1' by Rast

An item about RPGMaker 2000 posted on

Blurb

Part 1 of a very long tutorial by Rast, detailing how to design and make your custom menu systems.

Body

1) Overall design, getting to/from your menu, and cycle-based submenu design (you are here)
2) Basic cursor loops and static menus
3) Distributed control and chara displays
4) Manual dereferencing, picture displays, and composite displays
5) Showing lists and scrollable cursor loops

Greetings, and welcome to my big CMS tutorial. The tale was just to big to be told in one tut, so this is broken into a 5-part series. When you're done with all this, you should have all the knowledge you need to create your own full CMS. It is, however, important to note that this will not give you step-by-step instructions on how to make a specific CMS, you will still need to a lot of the work yourself. If you want a cookie-cutter CMS, download and install a CMS add-on.

This is part 1. Here, after going over a few prerequisites, we will get into overall menu design, how to set up submenus, and how to get to and from your menu in a manner that won't screw up the rest of your game.

Prerequisites
First off, being good with pointers is absolutely essential for this, so if you need to brush up, go right ahead. Knowing how to sort variable lists helps too but isn't required (my copy is fixed, so no bitching please).

You need to know how to use variables. All menu information is stored in variables and we'll be using lots of them.

You'll need an image editor to make your menu graphics. IDraw works but I'd suggest Paint Shop or Photoshop if you want the best-looking menus. But still - IDraw will work. You need to know how to make tile-sized chara as well.

And finally, you need to have a basic understanding of how RM2K/2K3 operates, in general. I'd suggest waiting to try and do the CMS until you've made at least one complete game.

Got it? Good. Onward!

Overall Design
After you set something up in your CMS, going back and changing it later will be difficult, and virtually impossible if the change is to drastic. Therefore, it is very important that you design all major aspects of your menu in advance. These would include such things as all your screens, your character stats (including any hidden stats - more on that in a moment), how your CBS will interact with your character data stored in your CMS, how your equipment and skills will work, etc.

Sketch
Get out a sheet of paper, and do a rough sketch of your menu system. Put on it such things as the screens, what information they will contain / display, their menus, etc. Don't go into too much detail, you're just trying to get a feel for how things will work. Do not rush this step - an error here will be magnified many times over while you are building your menu system and will be very hard to go back and correct. Take all the time you need and jot down as much information as you feel is necessary.

Character Setup
After you do that, open up a text file and start writing down ALL your character stats. Be sure to number them as well - you'll be setting up a data structure using these stats. Do not forget to include switch-based stats (such as status changes) - you'll have to multiplex them onto a variable. Do not use them as plain switches or your CMS will become much more difficult to set up. (See my switch multiplexing tutorial if you need help).

For your stats, I would recommend having three variables for most base stats (such as strength, dexterity, con, hp and the like), as follows:

1) Base Stat - The unmodified stat. This is the value that everything is based on and any changes to this stat will be permanant. You would modifiy this stat at level ups, and when they use stat boosting items.
2) Normal Stat - This is the value that the player sees outside the CBS. This value takes into account semi-permanent stat modifications, such as equipment bonsues.
3) Current Stat - This value is only used the CBS, and is the value of the stat with all temporary battle-only modifications (such as speedup / slowdown spells, attack boosting/draining spells, etc, etc)

For advanced/derived stats (such as attack power, defense power, accuracy, etc), I recommend two values, as follows:

1) Normal Value - As above.
2) Current Value - As above.

For stats that equipment will never modify (this will vary from game to game), I suggest this:
1) Base Value - As above.
2) Current Value - As above.

And for stats that only have a single value and never, ever temporarily change (such as level, xp, and marching order in the party), you can just use the base value.

Don't forget equipment slots and some variables for your character's skill list. If any of your special systems have char-level stats don't forget about them either. Everything that pertains to your characters has to go on this list.

Look at your list and review it a few times. Do not get freaked out if it's really big - the CMS that this tut series is based on uses almost 200 variables per character - dealing with big lists isn't a problem if you design your menu intelligently (which we will :P). After you set up your data structure in RM2K, this list is set in stone, so if you screw it up, you'll just have to live with it. After you're happy with it, open up RM2K/2K3 and set up your data structure (review the pointer tut if you need help with this). I suggest you have one slot for each character in your game (they will stay in this slot, only their March Order variable will change), and then another for each enemy your CBS will eventually support - this allows your CBS to use your CMS data and will make it much easier to work with later since you won't have to copy all those variables.

After you set up your data structure, make any common events that you know will need for it. I suggest these:

1) Interface event to get data in and out of your structure.
2) Event that determines party's marching order, if you following my March Order variable suggestion above.
3) An event that recalculates a party member's normal values (you'll probably have to dummy this for now, just stick in now so you can place calls to it where appropriate, even if won't do anything till later)
4) Switch mulitplexing/demultiplexing event

Party Setup
Now that you have your character-level stuff set up and out of the way, it's time to set up your party-level variables, such as gold carried, the marching order, and the inventory list.

If you need help setting up your inventory list, I suggest you use a list of variables that store inventory information in the following format:

####QQ

Where #### is a 4-digit id number, and QQ is a 2-digit quantity. To get the quantity, do a MOD 100 on the number, to get the ID number, divide the number by 100. To put it back together, multiply the ID number by 100 and add the quanity. You can do all this pretty easily and automatically with a common event.

Item / Skill design
And finally, the last thing we need to set up before continuing is figuring out how the items and skills will work.

I suggest that you use a common format for items and skills - the only way they differ would be in how they are used. Do this like you did the characters, figuring out all the things you need your items and skills to be able to do, everything from their MP cost to if character X can put it on his head to if it raises attack power.

You should put each stat on your list, along with a bunch of multiplexed switch flags that determine its use. If you need some suggestions on how stat modifications will operate, here's how I do it in Dragon Destiny II - you can feel free to do the same:

1) For HP, Max HP, MP, and Max MP, NEGATIVE values boost, POSITIVE values penalize
2) For everything else, NEGATIVE values penalize and POSITIVE values boost
3) For status flags: if an item sets a flag on user's own party, it CURES it, if it sets a flag on enemy party, it INFLICTS it
4) For status flags on weapons - they CAUSE that effect with the indicated success rate
5) For status flags on jewelry - they PREVENT that effect
6) Status flags on armor DO NOTHING (this is a speed optimization)
7) Equipment CAN NOT modify resists - resist changes outside battle are PERMANANT!

Now, go back into RM2K/2K3, and set up the variables you just wrote down. You only need to set up 1 - this is not a data structure. We'll be using a common event to place data about specific items and skills into these variables in a moment.

Although you don't have to, before continuing, I would suggest you make a big list of all (or at least all your planned) items and skills, what they do (exactly, in terms of the variables you just set up), and what their ID numbers are. You can, and should, space the ID numbers out to allow more items and skills to be added later as necessary without having to get your list out of order, as you'll probably want to sort it based on ID number.

Next, set up a common event that retrieves information about an item or skill based on an ID number passed in to the common event. It takes the ID number, runs it through a bunch of forks (we'll go over how to get RM2K/2K3 to do this quickly in chapter 4), and returns its information in the variables we set up above.

And, if you followed by suggestion about character setup, you can go back and finish up your normal-recalculating event now.

And now, all our menu set up is out of the way. This is the last you'll hear me talk about specific stats and lists and such - everything from here on out will be about menus in general, but you'll be able to use it to set up your interface to the data we just set up.

Getting to and from your menu
I'm hearing some complaints...

"I'll just use pictures and overlay them over the map!"
"Bah - just use Memorize Place and Goto Memorize Place"

If only it were that easy. The menus we are going to go over are far too complex to depend soley on pictures, instead, we use a mix of pictures, events, and panoramas. And for MP and GMP events - yes, that will work, but not without some problems, which we will go over.

Create your NPC template
Although we do use Memorize Place and Goto Memorized Place, the problem with this is that, normally, all your NPCs will go back to their starting positions. But we can fix this!

To do this, open up RM2K/2K3 and create a data structure 150 items long. This is what will hold the NPC location and facing information, and can support up to 50 NPCs per map. You can also use it to store state information for any minigames and puzzles you might have, so they don't reset.

Now, on a dummy map, create your template NPC. The way this will work is that every NPC in your game has at least 3 pages. The first two are 'hidden' by a switch (we'll call it "Always On") that is set on when your game first starts and are used by the suspend system. The third page is keyed active by the Always On switch and is what the player actually sees.

The first is called when the map is setting up, and will restore the NPCs position if the player is coming back from the menu.
1) Checks the "Reset in Progress" switch. If it's OFF, it does nothing.
2) If it's ON, it sets a scratch variable equal to its ID number (0-49. Each NPC on a map must have a unique ID number). This is the only edit you'll need to do on this page for each NPC. I suggest the template set this value to -1.
3) It calculates its pointer into the NPC information data structure and retrieves its position and facing data.
4) It uses Set Event Place to position itself at the appropriate location.
5) It runs its facing through 4 forks and faces itself appropriatly.

The second page is called when the map is being suspended. All it does is store the location and facing information of the event.
1) Sets a scratch variable equal to its ID number, as above. Again, you'll need to edit this on each NPC. It must be the same as the ID number on page 1.
2) Gets its pointer into the NPC information data structure, and saves its location and facing information.

Use special teleports
Now, we have to split up our teleports. For those of you who read my Four-Phase Day/Night tutorial, its the same thing, and in fact can interoperate with it just fine. This version just has some extra CMS stuff.

Teleport Event
For your teleport events, they should do the following:

1) Call TransitionMapOut common event
2) Teleport to destination

TransitionMapOut common event
This is a common event that does some common things that will need to be done each time you are teleporting to a new map. It does the following:

1) Sets "Stop Hero" switch
2) Clears "CMS Enable" switch. This is to prevent them from pulling up the menu while they're changing maps.
3) If you have any other custom systems, it shuts them down here

Map Reset Event
This is an autostart event that needs to be on every map. It has no appearance conditions, and thus will run every time the map starts up. This event just sets everything back up so the player can keep going, and then deletes itself.

1) If the "CMS Up" switch is on, it sets the "Reset in Progress" switch. If "CMS Up" is off, it sets "Reset in Progress" off. This makes it so that if they're coming back from the CMS, page 1 of the NPCs will run, but if they're coming from another map, the NPCs will fully reset back to their starting positions.
2) It calls page 1 of all NPCs on the map
3) It calls "Transition Map In" common event
4) It clears "CMS Up" and "Reset in Progress"

Transition Map In common event
This event does common set up that will need to be done on every map. It does the following:

1) It sets the hero 1 graphic to the current party leader (only do this if your CMS allows the player to change the marching order)
2) It fades the map in (or calls RestoreLightLevel if you're using my 4-phase day/night method)
3) Clears "Stop Hero" switch.
4) If "CMS Auto Enable Override" switch is off, it turns back on "CMS Enable". Set CMS Auto Enable Override when you're running a multimap cutscene and need to hold the menu off.

Stop Hero common event
The purpose of this event is to stop RM2K/2K3 from processing any player input while the "Stop Hero" switch is on. It is an AUTOSTART event keyed on by the Stop Hero switch, and it's only command is "Wait 0.0". As soon as the switch is turned off the player will be able to move again, and this won't interfere with other autostarts.

Run CMS Common Event
Next, we have a common event. We'll call it "Run CMS". This event should be a parallel event that is turned on by a switch, which we will call "CMS Enable". Just like it sounds, turning off this switch will disable your CMS. You'll need to turn this off whenever your events are doing something that takes time (such as moving chara around during a cutscene or displaying a custom message box) to prevent the CMS from interfering with your game.

This event monitors the CANCEL key, and when the player hits it, it takes them to the CMS, runs it, and when they're done returns them to where they were. This event does the following:

1) Enter Password - Cancel Key. Wait until key hit.
2) Sets "Suspend Map" switch. Waits until it is cleared via a cycle with a 0.0 second wait. (More on that in a moment)
3) Fades the map out
4) Memory Place
5) Set a variable equal to hero facing
6) Change hero graphic to a blank chara
7) Runs the CMS (teleport to CMS screen, fade in, run, etc)
8) Fade the screen out again
9) Go to memorized place
10) Restore hero facing (run the hero facing variable through 4 forks and set their facing back like it was)
11) Set "CMS Up" switch.

Suspend Map Event
This is an event that must be present on every map. Failure to include it will cause your game to lockup when they try to pull up the menu on that map. This purpose of this event is to call all your NPC page 2s when the player pulls the CMS up. It is a parrallel process event keyed on by the Suspend Map switch. It does the following:

1) Calls all NPC page 2s.
2) Clears Suspend Map Switch (which stops the event and allows Run CMS to continue since it waits for this switch to clear)

Now - after you put all this on your maps, when they pull up the CMS, do it, and come back, everything will neatly go back to the way it was. If you have visible monsters in your game, you can easily adapt the template NPC to create a template monster which will also not reset.

Cycle-based menu design
And now, to conclude this installment, some theory!

We're going to be creating a menu with many submenus and various modes. Without a good overall design it will quickly become unmanageable. To do this, we use cycles.

Basically, each menu is a cycle, and each submenu is a cycle inside of that cycle. For example:

CYCLE
- Set up the menu (including teleporting to the appropriate map)
- Cycle
-- Run menu
-- Get final input
-- Take action based on input
-- If they're going to another menu, break cycle
- End Cycle
- Fork Going to submenu 1
-- Cycle
-- Set up menu
-- Cycle
--- Same as above...
-- End Cycle
- End Fork
- Fork Going to submenu 2
-- Cycle
-- Set up menu
-- Cycle
--- Same as above...
-- End Cycle
- End Fork
- Fork Going to submenu 3
-- Cycle
-- Set up menu
-- Cycle
--- Same as above...
-- End Cycle
- End Fork
- ... and so on and so forth

As you can see, this makes menu navigation a snap. All you need to do to return to the previous menu is break out of the cycle that is running the current menu. All you need to do to return from the menu entirely is break out of the top-most cycle - you can think of the menu itself as a submenu of the map.

In reality, of course, each menu will be on a different map, will have a different common event associated with it, and will have totally different map events, but the priniciple remains the same - it will contain a cycle and when the common event is done and returns control to the common event that called it, it will automatically return to the previous menu. We'll go over menu set-up in more detail in the next installment.

That's all for this week - stay tuned for part II - Basic cursor loops and static menus!