EVENT STRUCTURES OF COMMERCIAL RPGS

Posts

Pages: 1
Hello everyone,

Recently, I've been coding an RPG from scratch. But the more I progress, the more I find that I'm just recoding features that are found in RPG Maker. Loading "events" with executable data in a list format.

Does anyone know the design initiative behind RPG Maker's event commands? Were they an industry standard?

How do commercial RPGs, such as, say, Final Fantasy IV, or Chrono Trigger, or SaGa handle their own "event commands"?

(If there are any people who have made ROM hacks of such RPGs, I'd expect them to weight in here.)
SunflowerGames
The most beautiful user on RMN!
13323

I think RPG Maker is made with C++, which is the code most games are initially made from. Developers usually make their own engine from C++ to make things faster. RPG Maker is just a tool that cuts out much of the code writing that would be required to make a game.
Kory, I think Zachary's referring to how AAA's designed their eventing system; the actual logic they used, and not the how they turned that said logic into code.

As for the topic, I don't think it is an Industry Standard of sorts. Rather, I think it simply is the easiest to implement and maintain, and the most efficient way to handle events. I can't really confirm this though, since I haven't actually looked into commercial games' codes, but I'm betting that this is the reason why it was used.
Hi Zachary,

I'm doing a small project related to this right now, but I'm piecemailing certain points until I can stitch it together, so for now I'm only doing a small executable that imitates pokemon battling.

This looks like it can be fun to talk through, so I'm going to start with some questions and then lay the ground work of some simple things found when programming these leviathans (RPGs are notoriously big).

What other kind of games have you programmed? If you've not done much game programming at all, I'd recommend you start from the simple up if only to build intuition. for example, Pong is clearly easier than Donkey Kong (arcade), but you can take the collision detection, score accumulation, and game loop thinking from pong to build slowly to DK (still a big jump, but not TOO huge).

> How do commercial RPGs, such as, say, Final Fantasy IV, or Chrono Trigger, or SaGa handle their own "event commands"?

When we look at a game like Chrono, we have A LOT going on. It is BIG, so we have to look at how we can break a game like Chrono into pieces. Let's think big scale first, what are our basic modes? We have stuff like the following:

Main Menus
World Map
Town/Dungeon Map
In Game Menus
Battles

This is a nice very big break down, since what we do in the Game menus is completely different from a Battle (though we may be calling some of the same functions/methods). Let's leverage this to make our lives a little easier; let's push and pull these modes from a "mode stack" (note, some of my high level CS terminology may be funny; I do hardware/systems stuff for my living...). Let's say we have Chrono et al enter a castle and get into a battle, what happens at a big scale here:

pardon my ascii stack representations...
Also, I'm tossing the main menu from the stack since I could care less about its state...

Initially

|WORLD MAP|

Enter the castle

|DUNGEON MAP|
-------------
|WORLD MAP|

Random encounter

|BATTLE |
-------------
|DUNGEON MAP|
-------------
|WORLD MAP |

Victory!!!!

|DUNGEON MAP|
-------------
|WORLD MAP |

Open menu to recover items

|GAME MENU|
-------------
|DUNGEON MAP|
-------------
|WORLD MAP |

Close it

|DUNGEON MAP|
-------------
|WORLD MAP |

another battle

|BATTLE |
-------------
|DUNGEON MAP|
-------------
|WORLD MAP |

No! A loss! ==> terminate or blow this stack and return to main menu

Doing this let's us get in and out of modes very easily! Since we have the state set, push a new mode on top of it, play in that mode, and then return, we will just find us in the previous mode where we left off! It helps keeps things organized quite nicely.

Once this is set, we can look into various elements that will occur in each mode. Battles are pretty simple, so let's peak here first.

What do we have in a battle? Our party, some enemies, items, and some other things. What do we do? We select our actions (RPGs are HEAVY on menus, so get used to them...), let some kind of AI (maybe RNG) decide foe moves, evaluate the actions based on our parameters, evaluate if the battle is over, evaluate for game over, rewards, evaluate exit conditions, repeat if needed. This gives us a nice small loop to work on with this stack item (trying REALLY HARD not to call this a frame arrrgh). What do we need at each poriton now?

Well the action selection will need a base menu (attack, item, run, magic, etc), the rest is automatic evaluation! Sweet, the less the user does the better since we all know user input is evil and trying to kill our baby who needs to coddled and loved and compiled with -O3 or whatever.

Let's take a look at the town map now! What have we got here. RPG Maker is nice in that you can put everything under the very vague "Event". This is for teleport points, npcs, and whatever. C++ can really shine here if you treat it nicely! The big thing is plaaning twice and coding once. Draw big diagrams for what your "events" can manifest as. Then, make this stuff real in the code. Getting into of the gritty of this here would be a little too much, but this should be a good foundation for now.

The biggest thing here is less, how to x, but really more your own design process. We can't simply attack a monolith like an RPG writing blindly line by line; we'll kill ourselves. So even more generally, follow a consistent and disciplined process. This is the one I typically follow:

Define the Objective
-What is the end product that we want and is it feasible now?
-What are our must haves, what specs do we need to meet?

Fracturing
-Look at the end goal and break it into slightly smaller sub-modules
-Continue to fracture those sub-modules further until we have small managable units that we can feasible program. Each item on this list should be functionally pure if possible (we will need IO, etc), and each item should only be doing one thing and modifying one thing or group of things that can be handed back on output. This will make debugging easier, trust me, especially if you ever dare to make this multi-threaded.
-Make sure each programmable small sub-module can be wired seamlessly into the portioon it is under easily and neatly. Avoid making a baklava with your code where th honey from one layer can be easily found and toyed with on other layers.

FREEZE
-Make sure everything is neatly and nicely defined. Save this to a read-only file. You are no longer allowed to modify once you begin programming. If you need to change somthing at this level, go back to pre-freeze, fix the specs, freeze and start over. the Freeze is a HUGE DEAL!

Testing
-Once each small programmable unit is written, test it in isolation so you can easily control input and watch output.
-Once they are all tested, wire them together into the slightly bigger sub-unit. Test that in isolation, but DO NOT mess with the submodules to it on their own; he goal is to test them together. If there are failures, fix them individually and work up the chain
-Continue up this chain until everything is wired together

Unit Testing
- At this point hopefully you have a nice demo that you can show off. make it public and ask people to report bugs.

Elaboration
- Keep adding new maps, enemies, and other things until you find that the game is complete.

Good luck on this. Even a small RPG (I'm talking like 10 minutes long) is going to be a big investment in time from a programming end line by line. I posted a Tetris mock up on another thread. Including learning SDL that was about 15 hours of time, so be ready to just plug at it, pull away for a day, and come back again, but going small to big is the way to go since you can use the stuff you gain at the small level at the big. You can just copypasta your batle mechanics (why I'm doing poekmon battle mock up in isolation right now), character structs, and whatever. Eventually all this starts to feel like playing with legos.

Aside from that, I'd be cool working with you on something over github if you want to or have the time to. I come with a weird caveat though; I mainly program in pure C, rarely C++. I probably could learn Java or Python pretty quick, but my home is really in C. Sorry for being weird.
Pages: 1