technical question about nested vs non nested conditional branches

[grem333]

In my game, the NPCs have a bunch of random dialogue, and to control what they say, I use conditional branches. Thus, I pick a random variable between 1 and let's say 20. And then I use nested conditional branches to show the corresponding dialogue.

The problem with that is, because I have so much dialogue, the event commands are off the event screen to the right (you can't scroll that way in VX Ace ). So I was wondering if there was any downside to setting up an event with NON-nested conditional branches like in my crappy example below:

Random Variable between 1 and 20
If V=1,
"blahblahblah"
Jump to "bottom"
end
If V=2,
"blahblah"
Jump to "bottom"
end
If V=3,
"blah"
Jump to "bottom"
end
ETC ALL THE WAY UNTIL 20...
Label: "bottom"
END OF EVENT

I can't think of any downsides, but then again, I'm not an expert, so I wanted to check with you all!

Thank you for your help!

 

[TheoAllen]

I don't think there is a downside too. But instead of jump to bottom, maybe you can just put "exit event processing"

 

[Llareian]

Since you have those Jump To "Bottom" commands (and like TheoAllen said, they can be replaced with Exit Event Processing since you don't actually have any more commands at the end of your event), there shouldn't be any appreciable downside. Without either a jump to or an exit command, it would have to check all 20 conditionals even if the first one was true, whereas nesting conditionals inside "else" branches avoid that. But looks like you were thinking of that and you should be good!

 

[grem333]

Thanks guys! I will actually have some other "shared" stuff at the end, like increasing the Friendship variable, so I guess I'll use the "Jump to Label" commands instead of exiting the event.

 

[Shaz]

There are issues no matter which way you go.

If your random variable is set to 20, and you have 20 nested conditions, it's going to check 1-19 before it gets to the one that matches. If you have 20 non-nested conditions, it's still going to check 1-19 before it gets to the one that matches.

If your random variable is set to 1, and you have 20 nested conditions, it's going to check the first one and find a match, and skip the rest of the processing. If you have 20 non-nested conditions, with an Exit Event Processing or Jump to "bottom" after each one, it's going to check the first one and find a match, and skip the rest of the processing.

FYI, the Exit Event Processing command just does a "jump to bottom" behind the scenes. The Exit Event Processing command says "how many commands are there? Go to the index of the last one", while yours says "look through all the commands, check if it's a label, and check if the label is called bottom, then jump to that line". So Exit Event Processing is more efficient than Jump to Label. However, unless you have absolutely massive events, there's not going to be a noticeable delay with either method.

The only way you could improve on either of the above is to make it skip all the checks and go straight to the entry you're after (so if your variable is 20, to not do the 19 comparisons beforehand). For that, you could use a label prior to each dialogue, with an Exit Event Processing command after each dialogue. And a Jump to Label command that will let you use a variable.

I posted a plugin for this the other day:
https://forums.rpgmakerweb.com/index.php?threads/jump-to-label.89885/

If you are putting your random number into variable 5, your plugin command would just be

JumpToLabel $gameVariables.value(5)

and your labels would just be 1, 2, 3, 4, 5, etc.

This will still look through each command to see if it's a label, and check if the label matches, but it's a lot faster than using a heap of conditional branches.

 

[TheoAllen]

But @Shaz , this is for VXAce

 

[Shaz]

lol - oops! (@TheoAllen you got a kick out of that, didn't you? )

Here is the Ace version:

class Game_Interpreter
  def jump_to_label(value)
    @list.size.times do |i|
      if @list[i].code == 118 && @list[i].parameters[0] == value.to_s
        @index = i
        return
      end
    end
  end

end

Just save it into a new slot below Materials & above Main (and name it), then do the following as a script call:

jump_to_label($game_variables[5])

There - all better now

 

[GrandmaDeb]

I have to admit I despise nested conditionals going off of the page...
Am I understanding this correctly?

...so with this script, instead, I would set (for example) variable 3 to a value.
Then I would have each section be:
label according to variable value

JumpToLabel $gameVariables.value(3)

all events for this value
exit event processing

And it would not only be avoiding the awful off the page nesting but be faster?

I was taught that "goto's" were evil when I was taught to code, but I think I am totally over that as of this moment! =D

 

[Shaz]

In Ace, it would look like this:

Control Variables [5: Random] = Random Number (1..20)
Script: jump_to_label($game_variables[5])
Exit Event Processing (just in case you accidentally set it to a label you haven't defined)

Label 1
# do stuff for label variable == 1
Exit Event Processing

Label 2
# do stuff for label variable == 2
Exit Event Processing

... and so on

In MV, it would look like this:

Control Variables [5: Random] = Random Number (1..20)
Plugin: JumpToLabel $gameVariables.value(5)
Exit Event Processing

Label 1
# do stuff for label variable == 1
Exit Event Processing

Label 2
# do stuff for label variable == 2
Exit Event Processing

... and so on

I would only use the above if I had a lot of conditional branches and only wanted to run one of them (I have a common event set up to execute when I enter a new map, and another to execute when I leave a map, and I use the map id as the label).

Be very careful about putting labels or jump to labels inside conditions & choices - that's when you start creating spaghetti code, and probably part of the reason why goto's are evil.

 

[GrandmaDeb]

Fair enough on the spaghetti code warning. But heaven save me from this again:
(debugging while only able to see 20 characters in an event command)

 

[Robert-Character Creator]

If you don't mind using scripts, I have a solution. This script: http://himeworks.com/2013/03/event-page-conditions/ allows you to set custom requirements to an event's pages using a conditional branch.

In this case, you'd have twenty-one pages, the latter twenty only activating if [variable] = n. The first would be your command to set the variable (You could combine this with the first dialogue page, making the number of pages 20, but I digress.). The latter twenty pages would be set to parallel process, have the dialogue occur, and then set the variable back to 0. It's not the most elegant solution, but it should be functional.

Also... Hello famous people!

 

[Shaz]

But heaven save me from this again

Those conditions are all AND conditions - more than one of them may be true, and you may want to execute the code in several branches. Jump to Label may not help you out here.

The OP's situation was where there were 20 conditions, but only one would be true at any time.

There still may be a better solution for what you're trying to do - if you want to discuss it, it might be better to start a new thread and provide a screenshot of higher up in the event list (you know, trying to figure out what you're attempting to do when you can only see the first 20 characters of the command ), as I think you actually want something different to the OP.

 

[grem333]

Thanks guys for all the suggestions! I'll have to try out that script, too, and see what's easier.

 

[Bex]

Dont use nested conditions in your case... just put them under each other like you did in your example OP.