Ruby Scripting

[kyonides]

More About Defining Methods

As far as you have seen here, you can defining pretty much any method except for the new method. You would have to use the initialize method if you ever need to setup what values it will define every time it creates a copy of that class, meaning it becomes a new  Ruby object.

For more information on the new and initialize methods, please read the main post of this thread.

There is something I have not told you that might confuse you if you come from other languages like C or C++.

Ruby does not care about the order of the method definitions.

Until now you might have thought that you had always had to start with the class definition and the initialize method, if you ever needed it. Then you would have to define any other methods below the initialize or (scene class) main method. And that was fine.

The thing is that  does not expect you to always follow that pattern. Actually it is the same for it if you first define dozens of attr_reader or attr_accessor method calls to quickly define new methods, and then come up with the definition of the initialize or main method. To be honest with you, you could also cut them all and paste them right below all of your manually defined methods.

I have got a reason why I am bringing this up right now. There is a slight advantage at defining certain methods and place them above the method that will call them later on.

Internally it seems to be more convenient for  to go up to the line where the method you have called from another method is located and then return to the caller after the former method's execution has ended.

Placing the callee after the caller method seems to make it a bit slower than the process I have described above. Here is an example of what I have been talking about:

Code:

class Window_Message
  def substitute_actor_name(text)
    text.sub(/\\n\[(\d+)\]/i, $data_actors[$1.to_i].name)
  end

  def fake_message_text_processing
    text = $game_temp.message_text
    text = substitute_actor_name(text)
    self.contents.draw_text(4, 32, width - 32, 32, text)
  end
end

In that hypothetical case we are defining substitute_actor_name before we even deal with fake_message_text_processing in the Window_Message class. So when the script ever calls and process that latter, it will jump upwards and execute the former and then fall back to fake_message_text_processing method without any issues. Then it will continue executing its contents, namely the draw_text method, to display a single line of text on screen.

Recursive Methods

This type of method relies upon itself to keep processing data over and over again as if you had defined a loop or for loop or while loop or until loop.

Code:

class Window_Test < Window_Base
  def recursive_method(value, value_max)
    val_width = self.contents.text_size(value).width + 4
    self.contents.draw_text(4, 32, val_width, 32, value.to_s)
    value += 1
    recursive_method(value, value_max) if value < value_max + 1
  end
end

In the case above we have defined a new Window_Test class that inherits basic methods from the Window_Base class. That will allow us to call the draw_text method at will.

Later on we have also included a call to the very same method we are defining there. It was necessary to include a condition (the if modifier) to prevent it from recursively call itself for the rest of our lives. Otherwise we could have seen how the game gets frozen and some popup window showing up telling us that a stack overflow has occurred and the engine needs to close by force.

So if we call recursive_method(5, 10) just once, it will print the value on screen 6 times in the same line.

Do you need to include recursive methods in your scripts?

Well, not really.  It is up to you and your scripting needs.
I guess not many scripts will ever demand you to implement such a thing in your game project.
 Even so you can be glad to know that you have learned about another programming skill here.

Happy Helper Method's Day!