This is a simple guide to help people along. I never got around importing pictures because there was some sort of bug in the system at the time I wrote this. It's fixed now but y'know.

RPGM2k3 has 3 "sides" to put it simple. The Database, the Maps and the Gameplay.

The database holds all the information needed to make the game run, but most the things there are directly related to the battle system or other default systems like the menu or shops.
There isn't much you can do in the database except what it is intended for (with the exception being Common Events, more on that later).

The maps on the other hand is where you as a maker have the most chance to do something, and not just conversations between characters or cutscenes, no this is where you can spice up your game to be something more. But to do that you need to learn what different commands are at your disposal.

The last side is of course the gameplay, this is what your players will see. The efforts of your work on the maps together with the settings you've made in the database.

As already mentioned, this guide is focused on the Event Commands, which you can find when creating a new Event on the Event Layer of your maps, simply right click to do it.
Most of these commands are also present in Common Events and the Troop's battle events in the database.

If you have any other questions regarding event commands or the maker in general then just throw in a question in the guide.

These two concepts are basically needed to understand the maker. And luckily these are both rather core concepts for any programming.

Switches are eilther OFF or ON. Simple as that, picture it as a light switch when you come home from school; if you don't switch any ON, it will stay dark and nothing new happens.

Variables are common in math as well and basically means that something has a value. All variables starts with the value 0 since no value have been assigned to it. Unlike swtiches the variable can be between 0-9999 In value so it's NOT just an ON / OFF thing. So if we assign a value to a variable it will remain and we can use that later.
So picture this being you going to your closet before school, you don't have a shirt on right now (0) BUT you have all those different t shirts to put on, but you can only wear one of them at a time. So if you have 5 t shirt options in your closet that means we have 6 different possible values to this variable. 0 for nothing and then 5 t shirt options.

Both Switches and Varibles can be affected by the Control Switch command and the Control Variable command. One command for each.
Just keep an eye on the Control Variable window as some of those choices stays marked as you create a new one.

Now Switches are useful since a lot of the maker's core features are dependant on it. We have the Condition for Event Pages, Triggers for Common events, Conditions for Battle events, Triggers for Battle Skills, can be activated after using a Battle Skill and some others.

Variables on the other hand are less obvious to people since they are in the background. But they are useful if you for example have a llinear story. Then you can just increase the variable by 1 for each thing happening storywise rather than switching ON a new switch for each. Or if you need to count how many potions you have or what level the hero is on etc.
They are there in several of the other Event Commands so it's good to get a hang of them.

Click the ... button to choose a switch/variable. You can name your switches and variables here if you want, to help you keep track on what they are supposed to do. But if you are only planning on using something at this very moment then assign one to be a temporary varaible or switch since they are all global.
Also keep in mind that the maker remembers switches and variables by their ID, a numeric value starting at 0 and going up. This is useful for some more advanced things but we'll avoid that for now.

Not gonna lie, this is the bread and butter of a lot of things in programming. Well not exactly this command but well, logic gates. It's on page 3 of the event command list.

Here comes some pseudo philosophic crap so skip this paragraph to the next if you just want it explaned. Computers are dumb, the chances of AI taking over are slim. A program can only do what we tell it to beforehand, therefore we use logic gates like these to set conditions. By setting conditions the software ignores activating things until the condition is met. If we want a treasure chest, simple things as that - the maker doesn't understand that opening the chest means that we can't open it again. It makes sense to us because of the logic in the physical world, but there are no limitations like that in code. So we need to activate a switch when it is opened, and if that switch is ON? Well then we can't open it again. Therefore we can control what happens. But once again, it is only as useful as we make it. But its most useful function is to avoid mistakes and errors. Okay rant done.

Conditional Branches is the event command, but Event pages also have a smaller "Condition" section. You can also find this term in the Common Event tab, Troops tabs and for enemies when you assign skills to them and some more.

We use conditional branches for control and to avoid errors (mostly players being able to repeat things they aren't supposed to)
In the conditional branch we have a lot of choices that the engine can check right away. Just keep in mind that a conditional branch can only check one thing. If there are 2 things to check then we need to add a second conditional branch after the first one.

EXAMPLE:
It's hard to explain the use of this without an example. So let's go with an example: You have a NPC in a store. If you bring him Iron Ore, he can give an Iron Greatsword to you.

One condition
Now if you do this without any condition then the player can just go there, talk to the NPC and get a greatsword. Because there is nothing that checks if you actually have Iron Ore or not.
Now the Conditional Branch command has a choice on the second page which is "Item is in inventory". So on that list, choose Iron Ore and we are good to go.
The game checks if there is a Iron Ore in the inventory, if it is: It carries on.

One specific condition
Now this is all good and dandy, but what if you need 3 Iron Ore rather than 1?
Well, now we need to work with variables. Before the conditional branch, use a Control Variable command to set a temp variable to Iron Ore in inventory. If you have 1, then the value of the var will be 1, if you have 15, then the value will be 15.
So this time the conditional branch will not check for item but instead check for a value of a variable. So we ask the conditional branch to see if the variable is equal to 3 or greater.
if it is, that means the player has 3 or more Iron Ore in their inventory and can get a Iron Greatsword. It carries on.

One specific condition and another condition
But wait, what if we also want the player to pay 1800g for it as well? Well now we need another conditional branch.
So first we use Control Variables, set a var to the value of the number of Iron Ores in the inventroy.
Then the first conditional branch checks if we have 3 or more.
Then the second conditional branch checks if we have 1800 gold or more. Luckily there is a choice called "Money" at the bottom of the first page for this.
Now if both those conditions are true, the event carries on and you get your sword.

We've talked a bit about variables and switches in this guide. They are afterall essential for pretty much everything you do in your project.

Now in both Control Switches and Control Variables there is a choice to affect a whole Batch of switches/variables at the same time. Now this will probably be confusing for a new programmer, why would you possibly want to affect several switches or variables at the same time? The answer: A lot of times. The problem? A batch means all switches/variables in a row. So you most likely didn't have that in mind when making your switches or variables.

Examples:

• Now let's say you set a bunch of variables to be equal to your heroes' levels, but those same variables are also used later which could create errors. Then you can simply do a Control Variable command in which the entire batch are set to 0 again.
  
  
• Or let's say that the player has a failsafe in a puzzle dungeon, then the failsafe event could simply turn all those puzzle related switches OFF at the same time without you having to add several different Control Switches commands.

Ever wondered what that tab in the database is for? What you can use it for?

Well first of all, the common events are basically a storage for events that you want to trigger several times in your game. If you create an event here then you can call it from any map.
What you need to keep in mind however, is that since this is an event outside the maps, you can't really do anything that affects the map itself. With a few exceptions of course.

A common event can have some settings. The first is Trigger. There are three settings: None, Autorun and Parallel Process.

• If it's set to None, then it will only activate once a Call Event command is in play
  
• If it's set to Autorun then it will activate when you first start the game and then never again. Throw in a trigger for it and it will play to conclusion each time the trigger is met.
  
• If it's set to Parallell Process then it will run at all times, avoid this unless it starts with a conditional branch or if you set a switch.

The second thing you can change is, setting a switch. This is for Autorun and Parallel Process only. Basically, they will only run if that switch is ON.



Examples:

• The most useful thing is for something that will happen often but you might change it.
  
• If you want the engine to calculate something for you
  
• If you want the game to react to what items you have equiped and similar things
  
• If you want to make a custom menu
  
• If you want to make a custom battle system
  
• If you have some sort of mini game
  
• If you want to make something a bit more complicated and use pictures

So chances are that if you like the maker and the systems it has, you probably won't use this much.

The Call Event command is useful when you want to activate a common event.
As mentioned previously. If your Common Event is set to "Call" then it won't activate on its own unless, well, called. And this is the command to do it.

In the command settings you can choose Common Events or Map Events.
Avoid choosing "Map Events" if you add this command to a Common Event or things will most likely screw up.

• If you choose common event, simply pick one from the list.
  
• If you choose map events then you get an additional choice. Either constant or variable.

If constant, simply pick one from the list and choose the page to activate.
If variable, then the game will load the event which ID corresponds to the value of a variable and load the page corresponding to a second variable. Kinda tricky right?
The point of the second? Not really sure but I can imagine that if you have some sort of choice and then have a page depending on the choice then you can do this to avoid using a ♥♥♥♥♥♥♥♥ of switches in your game.

Examples:

• You have a save point, instead of adding all those commands and sound effects in each event you have all of that in a common event and the "save point event" on the map simply calls it. That way you can change the message in the common event and all save points will be "updated" without you having to find each indiivudal save point and edit it.
  
• 
  
• When you need to make a calculation. For example to set a variable equal to your current gold and then subtract that variable by the price of an item you are looking at right now.
  
• 
  
• A lot of times this is just to make things smoother and reduce the amount of lines of codes. This is not as much of a big deal in a maker like this compared to real life programming.

The Key Input Processing command is useful when you are trying to do something fancy whether it's just a mini game or an entire battle system.

What this does is basically to record what button you are pressing. But it is saved as a value. How are you supposed to know that? Well I'll just give you a codex here:
1: Direction key down, J
2: Direction key left, H
3: Direction key right, L
4: Direction key up, K

5: (Select)Enter, Spacebar, Z
6: (Cancel) Esc, X, C, V, B, N
7: Shift key
10: 0
11: 1
12: 2
13: 3
14: 4
15: 5
16: 6
17: 7
18: 8
19: 9

20: Numpad +
21: Numpad -
22: Numpad *
23: Numpad /
24: Numpad .

So if you, after the key input starts, presses UP, then the varaible you assigned will set its value to 4.
------------------------
So you need to pick a variable for this value to be stored. You can also pick a second variable where the time is stored. This is kinda useless though, or well, I haven't used it at all. So if you take 20 seconds from the Key Input to begin before you press a key then it will have the value of 20.

You can also choose to disable some of the keys by checking the boxes. So if you want the players to click either Select or Cancel then you have those two checked. If you have directions marked as well then the key input will end when you press any of those buttons.
The default setting is to wait for input, this basically creates a paus from which the game will not progress unless the player presses a button of the allowed.

Now this command is useful when you want to do fancy things, you can add it to a parallel process event to make it check what the player is pressing constantly or use it to trigger a special menu when the player presses Cancel instead of the defaullt menu.

Although it sounds like the Key Input Process command this one is more straightforward.
The player is given a window where they can use the direction keys to input a number. How many digits the number has can be set int the Input Number command to begin with. You also assign a variable where the value is stored. That's it.

So let's say you found a secret code for a chest and it's 256. The chest itself has the Input number command and it is set to ask for 3 digits. It is stored in a varaible so you add a conditional branch to see if that variable is equal to 256 in this case. If it is, chest opens and loot. If not? Well, the condition didn't check out so it can't progress.

Examples:

• Codes with numeric values
  
• Custom bank system
  
• other custom systems.

This command's obvious use is to name your heroes, perhaps at the start of the game or when they join your party.

But it can also be used for coded puzzles like the Number input previously mentioned. So that's what I will focus on here.

First of all you want to create a hero that is only an entry in the database that we'll use for the code, so it shouldn't be a playable character or it will be weird.
So let's call that Hero "CODE".
In the Name input command you choose CODE from the list and add it to a door for example. You need to give the correct password to open the door.
Now, the player has free control to add anything within 12 characters.
Next we add a Conditional Branch, in it there is a choice for hero(actor CODE) one of them is "Hero's name is..." and then you are free to enter the correct answer here.
So if the player wrote exactly as what the conditional branch is looking for then it's a success.

This can also be done to give the player a bonus for naming characters super secret names if you have some sort of character customization at the begining.

You can of course use this together with the Message command to display some strings that player chooses. Like if you want to do like in Earthbound 2 and let the player tell you their real names and favorite food.

In your events you might want things to repeat themselves, or maybe you have choices that leads to the same results, or maybe there are wrong answers that makes something start over?
Regardless of which, learning about Labels and Loops could be useful for you.

Now Labels are not brands but rather a checkpoint in your code. If you add a label at the start of a conversation and one of the choices is "go back" then you can add a Jump command to move the process back there so you don't need to add all of that one more time.

It's worth pointing out that a Loop is what it sounds like, once you reach the end you start at the beginning again. So in many ways it's just a Label done easy.

So you can use both labels and loops when you are designing something that needs to be repeated at this moment. Sure, you could simply add an "End Event Processing" command to cancel the event and force the player to activate it again, but that also give them the freedom to walk away. And there are times when you don't want the entire event to restart.

it's also useful if the player are given choices that affects something now, but the end will still be the same regardless (such as the story progressing) then you can add a label further down and make each choice end with a Jump command to that label.

Now for the loops, this is when something needs to be repeated and can't start over. This could be useful for setting up something, doing some calculations, making comparisons and many other things like that. Just keep in mind that it will keep on repeating until you add a Break Loop command.

But the most useful use of the loops and labels don't come until you try to do something downright complicated.

The maker has a preprogrammed timer system. You can have up to 2 different timers running at the same time.

Now, to use the time you can use the Control Timer command from page 1. First you need one where you set the time that will be counted down. Then you need to add a new one that starts the timer.
There are two choices as well, if the time should be shown to the player and if it should keep counting down in battles.
The last use for the Control Timer command is to stop the timer.

Using timers can be good to add a challenge, such as the classic Resident evil Triology that always ended with a self-destruct sequence and you had to get out. If time ran out before you left, you died and had to fight the final boss again.
It can also be connected to a mini game or something else.

Of course, to actually make something happen when the timer reaches 0 you need a Conditional Branch (Surprise), you have a choice on the first page about timers.

Also note that the countdown stops when you open the menu. So if you make a custom menu or something then you need to do the following. Which is also useful if you for example want the timer to stop when you interact with a puzzle item.

If you stop the timer then the timer is gone.
But in the Control Timer command you can set the time to be equal to the value of a variable instead of giving a constant numeric value right away.
Luckily we can use this. So we could add a Control Variable command that stores the remaninging time of a timer in it. Then stop the timer, and when the player has interacted and got the control back you set the timer to the value of the variable and start it again.

I made a seperate guide for more advice on how to make certain things in the maker.

https://cs2bus.com/sharedfiles/filedetails/?id=2513584168