Warning! This blog post may contain programming lingo.

If you're going to step outside RM standard systems, nothing helps you more than properly planning and implementing your nonstandard systems and putting them behind an easily usable API.


Why custom systems?

I'm going to lean out of the window here and claim that the most-replaced RM standard system is still the battle system. Mostly because not even DynRPG stops the 2k3 standard system from sucking. *cough* In my days as a mod in the tech subsection of an RM forum, I've seen enough newbies asking how to make a custom battle system, to the point where there was a sticky post that explained the complexity behind it.

But I understand the need/feeling of wanting to use a system other than the standard one, aside from potential suckage. If you're making a classic RPG, battles are an important part of the gameplay, and you'll want your gameplay to be a unique experience. Alternatively, you just have this great idea, and no matter how you look at it, standard just doesn't convey it.


What's a paladin an interaction system?

Now I've rambled about custom battle systems, but the title of this blog clearly talks about an interaction system. What's the deal with that?

Okay, I'll have to go back a bit further and cross-reference that other project I'm involved in, Fata Morgana. Originally, FM was planned as a Zelda-like action adventure with quite some battling. For that, I built a rather dynamically usable battle system. Then we noticed that our protagonist was a noodle-armed teenager who'd be more likely to weasle around enemies than to fight them successfully. We also noticed that the battle system could be used for things other than beating up enemies. And thus, it was renamed to "interaction system."

tl;dr, an interaction system is basically a more generic form of an action battle system that goes beyond hammering enter and hoping you hit the enemy before they hit you.


Going generic

There are two kinds of interactions with the environment. I'll call them enter and non-enter, based on wether you use the enter key or not. Enter interactions are easy to implement, as they're natively supported by the engine. Non-enter interactions need to be handled by the interaction system, which I'll talk about further down in this post. For each interaction, the choice of enter vs non-enter has to be made. Both have their pros and cons which need to be weighed.

The big pro of enter interactions is that they're already implemented. You make an event and set it to on action key. Done. This works fine in games where you only have one interaction per event, which is chosen automatically (talk to a person and open a chest, not the other way round). If you have multiple interactions or want to give the player more freedom (talk to a chest and open a... oh wait), you'll have to resort to things like show choice, which is clunky to use for the player and not very maintainable for the developer.

This is where non-enter interactions come into play. Their big pro is that you have all the keys. For RM2k3 that's shift basically the whole numpad natively, and even more if you go deeper and play with patches. And each key can hold an interaction. I'm not saying there should be that many interactions, but there can be more than one. The downside is that you need a whole custom system to make use of them, and that you need to implement it well or else it's even harder to maintain than using show choice and enter interactions.

The solution is to mix and match. If you did your job right, you can use enter and non-enter interactions at the same time, which leaves the "talking to people and opening chests" part to the RM engine itself, while the fancy custom stuff is in your hands. The rule of thumb is that if you don't need a non-enter interaction, don't use one.


Interactions and Zack & Brian

Now I've thrown all the dry theory at you, it's time to throw dry examples.

The Adventures of Zack & Brian has five non-enter interactions, as seen in the HUD.



From left to right, they are:
Sword: This is your standard attack. It uses Brian's (self-replenishing) tech points and can be used against pretty much every enemy (and some other things, too).
See treasure: This isn't really an interaction, as it doesn't really interact with a specific event. Instead, it shows hidden treasures on screen.
Fire: This is your first MP skill. I don't think I need to say more about it. It's fire.
Ice: Ice is your second MP skill. Again, it's self-explanatory.
See ghosts: This is a semi-passive skill, which means that it can be turned on and off. It consumes MP while it's turned on. With it, you can see and interact with dead people. Again, it's not really an interaction.

So while all five of these are handled by the same input event (as you might infer from the HUD, they use the number keys), only three of them actually use the interaction system itself.


Making the magic work

I admit, behind the scenes, the interaction system is a bit of a mess in this game. The main reason for this is that I was planning to make it work in a week, so I had a bit of a devil-may-care attitude towards details. Also, and that's the important part, no matter how different the events look, they all follow the system's specifications.

A non-enter interaction with an event has a few steps and involves some background work.
1. The player presses a key (1, 3 or 4) that triggers the interaction. Depending on the kind of interaction, a hitbox is calculated.
2. For each event within this hitbox, its first page is called.
3a. If, after the call, the event page variable is still 1, that means that the event has finished reacting to the interaction.
3b. If the event page variable has a value higher than 1, the event is called with the new event page. This allows code to be split up according to switches and other things.

So basically, as long as an event can correctly handle the call of its first page, it works with the interaction system. Other than that, everything goes.


End of wall of text. I hope this has been insightful and not too rambly.