Welcome, dear readers, as I rant a little about what has made the RPG Maker series of games so powerful... the Event Coding system.

It is true that the newest batch of engines in the RPG Maker series utilizes a variation of the new RUBY Scripting language. Because of that, some of you may believe that an RPG game developed with these new systems require the inclusion of 'advanced scripts'. However, event coders have been and always will be an essential part of RPG Making.

Let us consider base-line eventing. The easiest events to conjure in an RPG game are things like NPC characters who talk to a person, a treasure chest that give a potion or two, or a door that opens which allows you to enter a house. If you could not perform any of these vital actions, you would not be able to create an RPG game, no matter how you look at it.

But I am not here to discuss simple event coding but what is referred to as an event system.


Since the early days of the RPGMaker series, there have been those skilled at making complicated systems for games. These skilled artisans are known as Eventers.

Eventers have crafted many systems in the years since the original RPGMaker 95 and RPGMaker 2000 was released. Event systems systems can range from simple timers and day/night system to complex caterpillar and party control systems Event systems may deal with a single map event or two, using the database's 'common event' system for specially called or automatic features, or an increasingly complex combination of the two. But in any way you you look at them, event systems create or re-create medium to large-scale features that one finds missing in the defalt package.



And before you ask, yes. There have been event systems created for the sole purpose of recreating sideview battle systems and ABS (active battle systems) such as the Zelda overhead battle system.


But what makes event coding separate from the creation of an event system? It can be summed up in one word: Expansion. Event coding utilizes the basic features you find in the map event system and uses it in a relatively basic manner. Event systems, on the other hand, augment an existing system or create a new system that was not in the game's package beforehand.

If someone places an event on the map that uses a simple 'show choices' event so the player can teleport to one of 4 different places, it is a simple case of event coding. Nothing in the system reacted any differently than any other teleport system, and nothing was really changed.

But, if you place an event that brings up a specially placed picture with the 'show picture' command, then use 'show choices' with a transparent backdrop, then you may be on your way to creating a low to mid-level event system. Something that displays a series of options, gives you choices in some way, has to be more than a simple yes/no or multiple-choice option in an event system. For a simple event system, the differenece is subtle (presentation) but the difference is still there. If the main function of the event system is built on multiple-choice options, there has to be more to the system than just the branching options.


Is an event system easy to work with? Chances are... no. Not the complex ones such as a full-blown menu system comprising of a dozen map events, sixteen switches, a dozen variables and the like. Most of the time, the end user (you ) of an event system will use the demo as a basis for their game... like downloading the Final Fantasy: Crystal Wings sideview battlesystem demo and creating their game from there.


However, some event systems were designed to be plug-and-play, relying on a mere handfull of events or common events which can be copied from one demo to be pasted into a new project.

In either case, you may have to edit an event system to be complient with other event systems in the event two or more event systems are using the samve swicht(es) or varibale(s). As such, it is important that every event system should have comments throughout their entireity, especially areas in the system wheret the end user may be able to turn on/off or change.

In any event, game systems (be they event or Ruby scripting) should have instructions tor ease of use.

Most event systems are fully enclosed systems inside a common event or a series of common events, which you could implement into any part of the game using the call common event function. In other words, a battle coded into a map isn't really a reusable or useful "event system" such as one you'd release online.

It's very vague the distinction between "a bunch of events", "a tutorial", and "an event system"; I think if you (the forum) wants to define an event system you need to set your own rules for their distinction. Something like "must have documentation and/or comments", "must be reusable", "must fit any purpose required of it", etc.

Stuff like these are also event systems:





An event system is a combination of map events + common events or sometimes just only of the two, this is a system that is made for people who can only assemble the lego pieces provided to them and cannot modify the default system of the engine. Usually, a heavy go event system can go upto 750 common events =_=

Yes, i love event systems, they made the impossible before the RMXP with RGSS.
About the 750 common events, well maybe if you look well, you'll see than some CBS needs arround 750 methods to make it, so imagina than you just make almost the same(of course with events it's harder if you think a while)
This is a good post, becasue it can show to new people than they don't need a script for all.

I'm wondering how to go about doing something like that? My event systems tend to suck in comparison. I've made menusystems using events but the movements of arrows and icons are laggy at best. Someone should make a tutorial on advanced event systems like this.

You know what's weird? I tried making event system in rmxp/vx, in comparison with 2k3, they tend to lag faster for reasons I'm not sure of. But sure, I recommend this one http://rmt.divinelegy.com/templates/inte...e/menu.zip , of course you need 2k3, but the same basic code apply in XP/VX :3


Edit by DerVVulfman: Space added to url to prevent the comma (',') from interfering with the link.

The link is broken.

oh remove the , at the end.

Ah, I remember these. Still in use today for those (like myself) who can't figure out RGSS.

When I was still using RM2k3, I was actually starting to get rather good at these. I was able to take apart most medium-high level systems and was even making my own weather/seasons/time system.



Not sure if some of you remember that one or not. For the same game I was also working on an ABS. I never did like turn-based systems. There was always a chance to miss when you know you saw the character hit. One other system was for reputation... I had a lot of systems in there. =\

Basically, though, I think of Event System as just something to make the program perform a task it was not originally meant to do and only using the events to do it. Number of events don't matter, the scale of the task doesn't matter, and even how well it works doesn't really matter. As long as you are using the events to force the program to perform new tricks, you've got yourself an event system of some kind.