Events and Structured Programming - How do you call it?

I was looking over a tutorial and was looking at this event:

from this tut


http://forums.rpgmakerweb.com/index.php?/topic/1790-the-puzzle-tutorial-make-your-own-puzzles-part-1/


(It has a button you must roll a boulder on to open a door. The door opens when you step on it as well,but of course, it closes when you step off!)


I will admit that I am generally one to look with displeasure at commands to break loops, exit event processing, jump to labels, and other "non-structured programming" methods.


But I am looking at this set of nested conditionals and thinking there has got to be a better way --- and all I can come up with is -


Test to see if the player is on the button. If they are - set the switch and jump to the end of the event processing.


If they are not on the button, test for the boulder being on the button and set the switch accordingly.


How important is it to you to keep your event pages tidy and trim?


Do you keep them free of jump to labels? Do you mind long event pages?


Sometimes I use second event pages just to keep the page from becoming unwieldy!


Discuss, please.

If I am understanding it correctly, It's a event that onc triggered it moves the bolder depending where the char is. 

If that's so, nah there really Isn't, because you need to record the char's position, without knowing what position it will be beforehand., and you need a condition branch for each possibility

However what you don't need to record is the Bolder's position(I don't know why they did that). Furthermore, in the condition branches, why is it "only" turning on a switch, when it should be moving the bolder as well. It sounds like the Bolder's event(not shown in SS), has a unneeded extra page to it.

The results of the event aren't in question.


It is the structure of the Conditional branches - a stylistic question which applies to may circumstances - which I am opening for discussion.

Well in "this" case, couldn't you do away without any condition branches except 1 of them(for the open/close sesame poc), and no recording the char location needed? It sounds like all the developer wants to do, is make sure the Bolder doesn't collide into the char, so couldn't they just use set move rout/move away from the char?

@Zoltor: The boulder has nothing to do with this, it's only an example for a question about programming methods.


@GrandmaDeb:


We all have to work around the eventing limitations, and one of the more heavy limitations is that the conditional branch can't check for more than one condition.


However, there are ways to make even such structure much more easier


It looks like the target is to make a switch ON only when both coordinates are identical. In this case, a bit of "out of the box thinking" makes the structure a lot easier:


Control the switch OFF (default) before any conditional branch, then make conditional branches without any else-branch just for the case where it should be ON. That will remove most of the branching structure with the same result.


If it is for tutorial purposes I would let it stand this way (still requires two nested conditional branches, only without the else's), but if it would be for my own games only, I would make the conditional check as a scripted check on the switches using an AND-Operator to combine both conditions into a single branch command.

I like keeping things succinct. I do this by using script versions of event commands as often as possible, which also gives me much more flexibility in what I do.

For your example, I would do what you suggested then simply nest the two conditions into one as a scripted conditional.

(if) $game_variables[1] == $game_variables[3] && $game_variables[2] == $game_variables[4]
or
$game_variables[5] == $game_variables[3] && $game_variables[6] == $game_variables[4]
 

Here's a screenshot of what my event commands generally look like:



I also make it a point to comment on every little thing I do to make sure I know what's going on whenever I need to go back and check or make changes.

I use loops and loop breaks often to keep redundant processes to a minimum, such as assigning each event a name, or an enemy with its initial HP and defense if it's an enemy monster, etc.

TL;DR I keep things succinct but I won't hesitate to make it complex if it makes developing easier in the long run.

EDIT: Which reminds me, I really really wish the next version of RPG Maker has a toggle mode where you can type all of the code in on this screen so I can copy and paste everything outside of the event and work out of the program.

I like to keep my events tidy. I don't necessarily avoid long events, but if I have them, I put in plenty of comments to break them up.


I don't avoid Jump to Label, but I only use it for specific purposes - something like when I use conditional branches to determine what choices to make available, I'll build a string to represent the possibilities, then I'll use a Jump to Label to go to the correct Show Choices command. Then since the same choice may be offered in several combinations, I'll use a Jump to Label within the Show Choices for each individual choice. That means I'm using labels and jumps in order to avoid repeating blocks of commands. I could probably use Call Common Event instead, but I tend to try and keep my common events to a reasonably low number.


I'll use script calls to make something easier (nested conditions, for example) but I like them to be clear too, so I will usually try to avoid very long or complex script calls.


It's all about being able to understand what the heck it was doing when you have to come back to it in 3 months to change it or fix a bug.

Yea good luck with that one, please let me know when you come back to reality lol(Keeping common events down to a reasonably low number, is an impossibility, furthermore you only hurt yourself with such silly concepts like that).

I never use jump to label in my events, because It's just asking for difficulties with locating aspects/reading the event in general later on(having to jump all around events to piece together a string of event commands, is the exact opposite of keeping things tidy.

Also, very rarely should you end up in a situation, where adding a comment would be a good idea(comments tend to make things even more cluttered, because not only do you need to look through a ton of event commands already, but now you'll have comments getting in the way of you reading the event command string. Unless It's something very weird, and extra hard to understand what's going on, I think you would be better off avoiding comments.

lol! Is this a "pull to pieces everything Shaz says" post? You haven't seen my game, you haven't seen my events, and you are not in a position to comment on whether my approach works or doesn't.


Just because it doesn't work well for you, does not mean it doesn't work well for me. It could simply mean you use the same tools I do, but don't use them the same way. I disagree with pretty much everything you just said, and I'll stick with my methods ;)

I'm sorry, but trying to keep common event count low, is a silly, yet futile endeavor.

I'm just trying to help for one, and second, I had to point out that jumping to other labels or whatnot, is the exact opposite of trying to keep things tidy. 

For that tutorial, you could substitute it with a script condition. I can't remember it out of the top of my head, but basically you compare event[1] X&Y to event[2] X&Y. If true, turn on the switch, if false, turn it off. This would only require one conditional branch.


I use exit event processing and labels a lot. Mostly due to the way my events are set up. For example, I have an event that controls an NPC's move route. In my project, NPCs run about at specific times, on specific days. So this event checks the day, then jumps to that day, and with a conditional branch that checks for the hour, I move the NPCs, and then use exit event processing to prevent any other parts of the event to run. It's a very long event page, but it's very well organized (plenty of comments), and the best part is - if I haven't worked on it in a very long time, and I come back to it, I know exactly what I did and why I did it. That's important to me.


@Shaz: common events are the meat of my games. I only use map events if it's really specifically tied to that map (like transfer events, or NPCs), but I use hundreds of common events to get the actual game running (for example, the map event for an NPC would call the common event to show his dialogue).

I feel like if you ever decide to ask for assistance and show your events, we could really help you out. Either that or trollolol.

Definitely true, I like to bypass using variables whenever I can and just use their current placements. $game_map.events[1].x == $game_map.events[2].x && ....[etc]

I thought about doing this for YANTH, using a "dialogue variable" to notate where in the common event to start the dialogue, with the dialogue nested in a conditional for a specific value in the variable, but it was already far into development and... ...

...

why shouldn't I do this even now? It keeps everything into one common event, oh god that would make it so easy... >_>

For complex events, it might be neater to use multiple event pages instead of very nested conditionals.  

It's one way to make each event condition less complex, since a single event page can require multiple conditions to trigger.   I like to use things like "Switch X and Self Switch A" for more interesting events like "NPC who gives you an item once you've finished a quest"

I like trying to keep my events neat, with multiple pages rather than sets of nested conditionals.  

I also like to use Common Events to test a complex condition, or run an equation, if I use it in several locations, and store its result in a Variable or Switch.  This keeps the core event logic simpler.

Basically, I try to keep the logic in small compartments, even if it means a single Event may call one or two smaller Common Events along the way.

To seita: I'm a very experienced eventer, and I have made crazy complex event in the past, as well as lately. Odds are very low I would actually ask for help eventing, and even then, it would have to be the type of event so difficult+odd, it would take weeks of brain storming with the other highly skilled eventers on the forumss, to come up with a way to get it to work, if It's even possible to do without scripting.

Even when I get stuck, I just try other ways to get it to work as intended(I'm a super fast thinker, and getting stuck doesn't phase me one bit, infact I actually enjoy the challenge, if one thing doesn't work, no big deal, move on to another method). It's actually kind of sad that I figure things out so fast. The last time I got stuck, I was stuck for barely even half aday sigh, what BS. 

As silly as it may sound, I actually long for the days I was making my first game on the original RPG Maker, and created a password system from scratch that completely did away with the memory/size restriction. Not only did it take a long time to come up with the proc for such, even knowing exactly what to do, it took months to create, nevermind the fact It's the most confusing string(not to mention huge) of event commands ever(I'm glad I didn't lose my position while going over it, much at all).

I just came up with a simple fix to a problem I did ask for help on the forums for, yet noone could figure out a way to do it, and I wasn't event thinking about it at all(infact haven't thought about it at all for months, I've been working on more important things).  I was working on a unrelated system, and it just hit out of the blue.

I am not one to brag, but you did insult me, especially with the way shaz was talking, it sounds like most of the more complex events, she just scripts instead(She's a great scripter, so It's understandable if that is the case, but being more or less against the use of Common events, is counter productive if she does event complex events).

The more complex the event is, the more likely that X event would "greatly" benefit from a common event. Furthermore complex skills, and items downight need common events(some people try to use the formula box to pull such off, but it rarely turns out well, people keep the formula box, for just that, formulas, don't try to create actual events with it).

I can address some other things as well, but this is more then enough for now.

To Whitespear Yes, that's a very good, and extremely viable option if you want a event to be better organized/easier to read(3 condition branches Isn't all that much, but any more then that, you would do well to use extra event pages instead of trying to do it all on a single event page)

Also your other idear are very viable good options as well.

A simple

makes a world of a difference.

Ok, yea you could do that

Tell me where I said I'm against the use of common events? I didn't say that at all, and I'm not. I said I try to keep the numbers down.


Yes, common events are useful - I just don't like scrolling through hundreds of them to find the one I'm after. And yes, I do have a number of scripts that I use that ALLOW me to reduce the number of common events - if I didn't script, I would use common events. I'm not against using them at all.


And comments? Not just to separate things and make them cleaner, but to explain why you're doing a certain thing or doing things in a certain way. As I said, try going back to a complex event 3 months or 6 months down the track. I bet you can't remember why you did everything or how it all hangs together, and if you'd taken the time to put in a couple of comments, it'll give you the memory jog you need. Particularly helpful too, if you're working with other people on the project and THEY need to know why you were thinking.


Anyway, we're dwelling a bit too much on one or two things. The OP asked for things you do that make it easier to do events, or make events more understandable. It's okay if someone likes to use a certain method and someone else doesn't. We don't all have to do it the same way :)

I suspected you were scripting to bypass the need to use common events, well you're a awesome scripter, you can do that if you want. As long as you aren't trying to event the hard, and very long way, in hopes of bypassing the need to use common events, no harm done.

Using comments to mention what everything does, is what I have a problem with(because you have a lot of text telling you what things supposedly do, which just gets in the way of reading the actual event. It's not hard to read events, if you're coming back to a complex event, if you can't find the exact location with the event commands you think are causing it, just start reading the event from the nearest spot you know is being executed before the event command string you're looking for.

I can see why you do it though, you're a scripter, in scripting, It's not always clear what things do(especially depending how you scripted it, if you script it in a format like the developers of RPG Maker did the default scripts for instance, whithout comments, it would be a nightmare trying to locate/figure out what scripting segment, relates to what feature).

The difference between scripting, and eventing though, is it already pretty clearly tells you what everything does(unless you don't name your switches, and variables).

True, fair enough.

On topic: Splitting the more runon types of events between multiple pages is a very good option. Not forcing a single event to do the same thing over, and again in various pages of the event or making it do too many completely different things(for the 2nd issue, multiple pages work best, but for the 1st issue the use of a common event would do wonders) is definitely a good way to avoid problems later on.

Yeah, you're probably right there ... it IS commenting in programs that has put me into the habit.

I don't script, and I comment the heck out of my events. It's very well organized. Zoltor, your reason for not using comments because it adds more 'reading' is ridiculous. The comments are for yourself, so that you can make a linear event and come back to it and still know what it was all about. This is extremely useful for complicated events. I doubt you would be able to read some of my events - without comments - to know what they're for and what they do, as a complete outsider.


If anyone looked through my project, they should be able to understand my flow of events because I comment. You should never discourage commenting.