Rgss tips : Method Hierarchy

[nio kasgami]

Hi folks! 

Here Nio back for a another discussion about rgss ! 

for people who begin in rgss you will maybe need to know this little information~

First I will love to say all my explanation are based on my OWN experimentation in rgss I can have false but I love to share my experimentation!

Now let's speak about

Method hierarchy

for people who don't know what is this term in rgss 

this simply the order of how method are called !

I spoke with a friend who wanted to know how to show a picture before the Printf of the battle message "enemy appear"

so I thought about the method hierarchy so let's explain

Naturally rgss will run in a sort of way like a stairway and will run the first method after the second method and e.c.t

now this know how to settle the priority of wich method you want to start

because no you can't put your code way ...you will hit a crash for sure

so let's show some exemple code

def mainSceneManager.clear Graphics.freezecreate_backgroundcreate_commandupdateendso ...maybe you can be a little lost no? 

but this pretty easy to understand! think of the rgss this like a domino!

who run each method in order unless you have a "IF" method but let's see that later.

so Naturally you will want to Clear you SceneManager from any kind of data and prepare you scene!

after you surely want to Freeze the graphics of your game for avoid any lags from the Scene_Map or event!

so they will come first!

but ..why background will come  before command and no after?

simply ..normally you want to create your background in first!  don't forget this like a domino but also like a manual...you want to read your manual correctly and not  pass of the page 1 to the page 20?

Naturally all will depends of how you want your scene to appear!

I invite you people to test my theory by using "msgbox_p("method")

for see how they read it!

so now...oh! we forgot update

why if this seem a important setting...we put it in last?

the answer is simple the update method is something who update your previous method...so if you put in before the other method...what the update will do if....no one of his method is not still create??

so this why you have to put the update in last.

so now

Multiple hierachy call

def mainSceneManager.clear Graphics.freezecreate_backgroundcreate_commandupdateenddef create_backgroundcreate_first_backgroundcreate_second_backgroundendHuho!

what happen here?

we call a the create_background method but...surprise! they have two more method who are appear!

so now my create command will not work?

No No you don't have to worry! this simply rgss will run these two method before running create command!

don't forget! Domino trail is not linear you can have some extra calling separate into multiple method! this even better to have separate calling this help for make your system readable!

Breaking method hierarchy

Now you surely want to not run a method if a certain condition is not meet right? so now for doing this let's show "if" statement!

the if statement are multiple they serve for force a call or stop a call to do if the condition is not meet but I assume you know how manipulate variable so we will pass to the if statement.

def mainSceneManager.clear Graphics.freeze@variable = truecreate_backgroundcreate_commandupdateenddef create_backgroundif @variable == truecreate_first_backgroundcreate_second_backgroundendendso now as you can see if the variable  will equal true..this will  run the two method else..this will run nothing!

now let's check you surelly want to run something else if the method will be not meet!

so for that we use this method!

def create_backgroundif @variable == truecreate_first_backgroundcreate_second_backgroundelserun_blank_backgroundendendthe else method is here for run a second method if the first is not met! 

this not magic?

ho and NEVER forget to add a extra end

for each if statement you do! 

so Here the ends of my explanation I hope you loved to read this Like I said I just share my experimentation  with the people! 

they also exist a lot of way of coding and this one is just one of the numerous way you can code in ruby! 

so Nio out's~

 

[Nathan Frost]

That whole ordeal for using create_background or create_all_windows for me is just a way of organization and a faster way to call a set of methods. I mean, you could write everything in the start def if you wanted to, but most of us follow this formula to keep the piece between the default scripts and because we're so used to seeing it that way. Oh and you don't always have to say if @variable == true you could just leave it as if @variable. The same goes for game switches, if $game_switches[1] etc, etc. It wants to return true always, only the false statement would really matter in this case which by that point you could say if !@variable or if !$game_switches[1]. Of course this is just how I do things but it's a matter of preference.

 

[nio kasgami]

That whole ordeal for using create_background or create_all_windows for me is just a way of organization and a faster way to call a set of methods. I mean, you could write everything in the start def if you wanted to, but most of us follow this formula to keep the piece between the default scripts and because we're so used to seeing it that way. Oh and you don't always have to say if @variable == true you could just leave it as if @variable. The same goes for game switches, if $game_switches[1] etc, etc. It wants to return true always, only the false statement would really matter in this case which by that point you could say if !@variable or if !$game_switches[1]. Of course this is just how I do things but it's a matter of preference.

haha yes but for me I don't see the point to put all the method in one call ..you imagine a battle system who doing that? this will be hellish 

and yes I for the variable I just show a matter of preference for other people who don't really masterize the rgss but most of time I use unless or !  seriously this depends of my mood to

and this totally a preference I think haha 

all the stuff I made was just a relevant information from myself who sudently become  a tutorial >>' 

but I enjoyed your answer and to write this thread 

 

[Tsukihime]

That whole ordeal for using create_background or create_all_windows for me is just a way of organization and a faster way to call a set of methods. I mean, you could write everything in the start def if you wanted to, but most of us follow this formula to keep the piece between the default scripts and because we're so used to seeing it that way.

You could write everything in one method, but what happens if I want to add or change certain behavior inside that method?


I'm sure XP scripters probably are more used to seeing everything in one method rather than having a hundred methods achieving the exact same end result.


VX scripters probably are used to seeing hardcoded values passed directly into method calls instead of calling a method just to get a hardcoded value.


These are all design decisions that programmers need to make, and it is perfectly reasonable for someone to ask "what's the point of all this? All that matters is whether it works or not right?"

 

[nio kasgami]

I approve what you said hime but also input all into same method complicate the reading and make edit very complicated so this why I think this better to simply separate all in multiple method for permit to be more readable!

 

[tyler.kendrick]

It can sometimes be better to flatten the method heirarchy - but only if you don't plan on changing/extending the behavior of the objects you are creating.

Code should document itself and methods shouldn't really ever do more than what their name describes.

Imagine if Game_Actor#gain_exp didn't break itself into multiple methods that described each step of the method.

If you wanted to display a custom message when the user leveled-up, there wouldn't be a level_up method to override.

what would you expect to extend in order to gain this new behavior?

gain_exp doesn't sound like an obvious method to display level_up messages in...

Even if you are just writing code that will never change, it is good practice break the steps into other methods.  This is because it makes testing and isolating errors much simpler.

If your "main" method throws an exception, what are you going to do to debug it?

An easier way to test the behaviors of the code, would be to break it up into smaller sections, that can be invoked in isolation.

In the original "Main" method, here is one way to test it:

1. Create an event that executes a call script once.
2. In the Call script, type in the first line of the original "main" function.
3. Check for changes you expected to happen after that line executed.
4. Run the game, and see if it throws an error or if your checks failed.
5. Create a new page on the event and repeat steps 1-5 for each method that is invoked on main.

If any checks fail, or an error is thrown, you will be able to easily determine EXACTLY where the error is located.

Another benefit from smaller, isolated units of code, is that you get the same benefits that you do with block comments.

This means that when you come back to the code after a few months to fix a bug someone reported, you will be able to understand the intentions of a method block - simply because it will ONLY do what the name of the method describes.

 

[Lemur]

A method name is a promise, one that should not be broken. I would be very careful of using Instance Variables to pass about data, it makes for a mess and hard code to follow very quickly.

In a more functional style of programming, we would take many small methods and compose them into larger ones by combining them in different orders. Think of it as legos in a way. Each method knows nothing of other methods, only itself. It's not allowed to manipulate outside state (instance variables) and is constrained completely to itself. Difficult at first, yes, but there's great power there.

Consider each methods name as a promise, and the parameters and returns to be a contract it makes with other methods calling them:

# Contract: (Integer, Integer) => Integer# Or in plain: It takes two integers and returns an integerdef adder(a,   a + bend
By modifying anything else, the method violates its contract. Breaking methods into their smallest components can yield very powerful and robust code.

While functional style is very distinctive from what you would be used to in an object oriented language, the two are not orthogonal.

In the case of objects, remember that the object itself is part of the contract you're making. Often times you simply return a new object with the new values instead of modifying the old. The goal is to isolate state as much as possible to prevent unintended side effects depending on the run order of your script.

If you're interested in contracts and learning more on functional concepts in general: http://learnyouahaskell.com/

TL;DR - If your code is dependent on the order it's run in, that's a very bad thing, you should fix that.