Introduction into Rm2k3

***************
I. Intro
***************
If you’re having to read this, you are probably one of those lazy people who haven’t bothered to read the RM2K3 Help File, which as I will add, has been written and is there for a reason – for beginners to read! Now look, making games and RPG’s is a long and heavy workload, so if you’re a person who gets bored or gives up early, don’t bother trying. RM2K3 is definitely one of, if not the easiest program to use to create an RPG. It uses point and click coding, but it is a very restrictive program, so you can’t quite do as much with it as say, Game Maker. My first two pieces of advice would have to be, read the ‘Help File’ and ‘Practice Makes Perfect’. You are going to make a very average game at best if you have not practiced using the program. My next two pieces of advice are ‘Read and Put Tutorials Into Use’ and ‘Try a Few Things Out, try a few systems such as an ABS or a CMS once you have quite a good grasp on the program, definitely try to make a short game using the basics of RM2K3, but don’t try to make a fully loaded, serious game until you have had at least a few months of getting things working and testing the programs limits’.

***************
II. Database
***************
Now look, the database is a very important part of making an RPG in RM2K3. It looks something like this, depending on what version you have:

I am not going to spend too long on the database, but I will just stress that it is important and you should complete it before finishing your game. Common Events are arguably the most important part of the game. They are constantly reoccurring or constantly used events, for example, in a fighting game, you would consider punching a common event and therefore you would code the punching in there. That’s it for the database, I thought we should just touch base on that.

***************
III. Events
***************
Events are another very important part of making your game. Events control what your hero does, what approaches your hero, what happens to your hero – they control everything that happens in your game. You need an event to present your hero with an option and you need another to carry out what happens after he chooses the option (or of course you could just use a second page on that event, which would save room on the map, but we’ll keep it basic enough for now). In a way, an event is a bit like a lie – you need one to start with, then you usually need another to back it up.
An event screen should look like this:

The first thing you should always do is name the event – this causes for less confusion when you have more and more of them and just gives it more structure. The preconditions are what has to happen before the event can actually happen, we will work with this a little later, don’t worry too much about that, once you get started and have read a couple of tutorials, it is easy enough to work it out. Trigger Condition: this is an important part of an event, if action key is selected, the hero will have to walk up to the event and press ‘z’ or ‘space’ before the event actually happens. On touched by hero, the hero has to move into the event, if the event is moving and touches the hero, it will have no effect. On Collision with hero is commonly used in basic ABS’s meaning if the event touches the hero, or the hero touches the event the action will take place. Auto-Start, as long as the preconditions are met will happen immediately, no matter where the hero is or what he does. Parallel processes are probably more commonly used than any other event trigger, it is a fair bit like auto-start with a few important differences which is probably more easily learnt through practice than me mentioning all of the differences.
Just quickly, event layer will determine whether or not the hero will be able to walk through it or not, below or above he will, but same layer is what should be used for objects or people which cannot be walked through.
For the rest of the options, just play around with them a bit, you’ll get used to them and it will be fine in no time.

***************
IV. Switches
***************
Switches are used when something has happened or been obtained that once pressed again, will cause a different effect. For example, you are making a game, and in that game you walk up to a chest and in it you find a sword, great, but when you press it again, it gives you another sword, and again. How do you stop this you ask? Well, make a switch, name it 0001: Sword Obtained and set it off. Now set up a branch option (Conditional Branch), set the option to ‘If switch 0001: Sword Obtained is set to off’ and under that you have Item Management – Add Sword. Under that, put switch operations and set switch 0001: Sword Obtained to on. Now look a little lower, you will see an Else Handler, if not, edit the conditional branch and click ‘Execute Custom Handler if Condition Not Met’. Now in it, maybe try a nice message or even erase event, anything as long as you don’t give the hero the sword again. Switches are used to give a different effect, depending on what has happened so far in the game. Just get some practice with them and you’ll get the hang of it in no time.

***************
V. Variables
***************
Variables store numbers. In fact they can even be used in the place of a switch, but we’ll let you worry about that when you’ve had a bit of practice. Variables are in fact much like switches, giving a different effect depending on what is chosen. They are used when something has happened and there are multiple options for the effect. They also rely on branches, for example, if you’ve made a game where someone gives you bananas (or anything really). And another person counts them for you, you will need variables. Remember to set your variable at 0 at the start. Then talk to the guy 4 times that gives you bananas. You should have four bananas, now walk over to the guy that counts them for you, in his event you should have something like this:
Branch V[001}: Bananas is equal to 0
Message: You have no bananas
Else Handler:
Branch V[001}: Bananas is equal to 1
Message: You have one banana.
Else Handler:
Branch V[001}: Bananas is equal to 2
Message: You have two bananas.
Else Handler:
Branch V[001}: Bananas is equal to 3
Message: You have a bunch of bananas.

You get the point..

***************
VI. Getting Started
***************
Thought I might as well touch base on getting started, probably should have done this right at the start, but oh well. Remember to set party start position by going to the events tab and right clicking. Double click anywhere on the map to start your events off. Also remember, in the database is where you can change your chipset and ultimately the look of your game.

***************
VII. Conditional Branches
***************
Well, they're pretty important so I thought I'd give them a section to themselves. They control what happens under different circumstances - usually using Variables and Switches, but also many other options.

Structure:

Have a look in the Maker itself at the options it presents to you, but 4/5 times you will be using a variable or a switch as the first option, and on, off or a number as the second.
If the condition is not met, the else handler will take effect, there is no need to put a branch in the else handler unless you are going to need more else handlers, but lets keep it simple enough for now.
End will happen after any previous coding if the condition is met or not. Try it out, in probably most codes in a conditional branch you will need to put something in the End part.

Just remember now, RM2K3 is not the greatest game maker, and it will lag sometimes, so do not overcode! It is the last thing you want to do - keep it as simple as possible, but always put what you want or need in it, just avoid unnecessary coding. I say this because conditional branches are often overcoded and this is not good for the game, especially if it is a longer game, it will cause lag.

***************
VIII. Conclusion
***************
Remember to read and try out tutorials and get the hang of systems and the coding in RM2K3 before throwing yourself in the deep end and making a game straight up because I can guarantee you, it will be no good. Practice makes perfect… and good luck I guess.

Hope I helped you;
Maditaliano