Slip into Ruby Resurrected!

Trihan · Mar 24, 2025

Since rpgmaker.net went down, so unfortunately have all my Slip into Ruby and Jump into Javascript articles. However, rejoice, sports fans! I'm bringing them all back right here. To prevent clutter, I will make each article its own reply to this thread. If you can think of a better way for me to do it, I am entirely ears. Without further ado, let's begin!

SLIP INTO RUBY PART 1 - OBJECT-ORIENTED WHA?

Part 1 of a series explaining Ruby and RGSS in a way you can understand.

Hello folks, and welcome to part 1 of...

My goal is to offer a resource to budding RMXP/VX/VX Ace users who know that there's a scripting language there but don't have the first idea what it is or how to use it. Or people who DO have a first idea but aren't quite getting it.

However, before we can really get into the meat of what RGSS is and can do, it makes more sense to take a look at it from a wider viewpoint. So we're going to start with a bit of a primer on what, exactly, object-oriented programming is.

I could talk about classes and methods and properties and instance variables and inheritance and parameters and arguments until I'm blue in the face, but I know there are some people out there who wouldn't have a clue what I was on about. So we're going to make a cat instead.

If you're starting with a blank slate, you can't ask Ruby for a cat, because it has no idea what one is. Before we can make one, we need to provide a template from which all cats will be manufactured; a blueprint for a cat, if you will. In Ruby, this template is called a “class”:

Ruby:

class Cat
end

This is one of the simplest classes you can write. It's the minimum amount of code required to be able to say “Hey Ruby, give me a cat please.” If at some point we find ourselves in need of a cat, it's simple: all we have to do is create a new instance of Cat with a unique name, like so:

Ruby:

tiddles = Cat.new

We now have a cat, but it isn't a very exciting one because it just sort of sits there and doesn't do much. However, there is one thing it did that you couldn't see; it called its constructor method (“method” being Ruby's term for a subroutine or function)

The constructor method is a specially-named one which is always called “initialize” and is always called as soon as an instance of the class is created; if you don't provide one explicitly, there's a built-in one for all classes which Ruby will call for you, but this isn't always ideal if we want to do anything specific when we make a new cat. We'll come back to this later, so don't worry too much about it right now.

The main concern we have at the moment is that the cat can't breathe, which means it isn't going to live very long unless we give it some way to do so. Let's do that quickly before our pet expires:

Ruby:

class Cat
  def breathe
    #insert code for inhaling oxygen and exhaling CO2
  end
end

There we go. Now any instance of a cat is able to breathe by calling this method when it's needed in the program. You call a method by entering the name of the instance, followed by a period, followed by the method name, like so:

Ruby:

tiddles.breathe

And our moggy lives to see another day. However, as you can see it's still not the most exciting of pets...maybe we'd have more luck with a dog?

Ruby:

class Dog
end

rover = Dog.new

rover.breathe

Uh oh. Rover's just informed us that he can't find a method called “breathe”, and he's rapidly turning blue. What went wrong?

Well a dog isn't a cat, so dogs can't really do anything that cats can. If we want Rover to breathe, we need to add the method to his class too:

Ruby:

class Dog
  def breathe
    #code for breathing
  end
end

There we go, much better. But Rover's just as boring as Tiddles. And the fact that we've replicated the exact same code bothers me. If only there were some way our cat and dog could share the breathing method between them...

Here's where class inheritance comes in. See, classes can be children of other classes, and the great thing is they will inherit all of the properties and methods of their parent. What do cats and dogs have in common? They're animals. What do all animals do? Breathe. So rather than replicating the breathe method for every animal in the world, it'll be much easier to let animals in general do the breathing and then pass it on to cats and dogs via inheritance. And we do that like so:

Ruby:

class Animal
  def breathe
    #code for breathing
  end
end

class Cat < Animal
end

class Dog < Animal
end

Excellent! Now we can do

Ruby:

tiddles.breathe
rover.breathe

And our pets have no respiratory problems whatsoever. We could even give ourselves a goldfish and as long as we specified that he's an animal too he can breathe like the rest. Of course, fish don't breathe quite the same way as cats and dogs, but that's a topic for later.

I feel quite sorry for poor Tiddles and Rover, so my next task is to give them a way to communicate with me. Let's see...

Ruby:

class Animal
  def breathe
    #code for breathing
  end
  
  def meow
    print “Meow!”
  end

  def bark
    print “Woof!”
  end
end

So now we can do:

Ruby:

tiddles.meow
rover.bark

And our output on the screen would be:

Code:

Meow!
Woof!

But wait. Inheritance isn't always a good thing...

Ruby:

tiddles.bark
rover.meow

Yeah, sometimes animals just need to have their own sounds. Let's fix this:

Ruby:

class Animal
  def breathe
    #code for breathing
  end
end

class Cat < Animal
  def meow
    print “Meow!”
  end
end

class Dog < Animal
  def bark
    print “Woof!”
  end
end

There we go, now dogs can only bark and cats can only meow. Our pets are able to communicate and breathe. They're starting to look much better already!

So tell me, how old is Tiddles? What? You don't know? Why not?

Well we haven't even told Ruby that our furry friends have ages. In fact it doesn't even know they're furry because we haven't told them about fur either. Things like this are called properties, and determine the kinds of data that can be held about the class.

So that we can answer the above question, let's give animals an age property. All animals have an age, so we might as well make it common to any animals we need. There are several ways to do this; I'll show you the least abusable way, then explain the alternative and tell you why it's a bad idea.

Ruby:

class Animal
  def initialize
    @age = 0
  end

  def breathe
    #code for breathing
  end

  def age
    @age
  end

  def age=(val)
    @age = val
  end
end

Oh man, that's a bit more complicated than we're used to so far, but don't worry, it's pretty simple. The “@” is basically telling Ruby that this variable is an “instance variable”--that is to say that every new instance of the class will have its own version. This means that Tiddles the cat will have an age independent from that of Felix the cat. If we didn't denote it as an instance variable then all cats would share an age, and that would just be chaos.

The new methods are there so that we can find out the age of a cat, or change its age if needed. So now when I ask you “How old is Tiddles?” you need only enter this in your program:

Ruby:

tiddles.age

And the returned value will be the age of Tiddles. You can also do

Ruby:

tiddles.age=5

And Tiddles will magically age to 5 years old.

This is, in my opinion, the best way to do this. What you could have done was this:

Ruby:

class Animal
  attr_accessor    :age
  def initialize
    @age = 0
  end

  def breathe
    #code for breathing
  end
end

“attr_accessor”, “attr_reader” and “attr_writer” are essentially a shorthand way of doing the get and set methods we created in the previous example, but there's one important difference. attr_accessor basically means the variable can be read or written to at any time by anything anywhere. This might result in you accidentally changing a cat's age in a part of your program that has nothing to do with cats, and if you don't realise you've done it that's going to be a to find and debug later.

The way we did it was by creating what are known as “getter” and "setter" methods, which allow you to read and write instance variables but only from within their own class, limiting the circumstances under which one might change a variable's value without meaning to.

So now we have a parent class, Animal, which determines the things an animal is able to do. We might end up adding other methods to this like jump, swim, mate and so on. Then for the cat class, we might add catch_mice, scratch_human, land_gracefully...you get the idea.

You may have caught on to something I mentioned earlier when I said that some animals might not breathe the same way as others. Fish certainly don't breathe the same way cats do, but currently if you made fish an animal the program wouldn't know that. We'd have to do what's called “overloading” and give fish their own, unique way to breathe. We simply do that by redefining the breathe method in the fish class:

Ruby:

class Fish < Animal
  def breathe
    #insert custom code that only applies to fish
  end
end

Now although fish inherit methods from Animal, we've told the program that they breathe differently from other types. Basically a method's functionality will be determined by the lowest level at which it's defined: methods in a specific class will take precedence over the parent, which will take precedence over the containing module (we'll cover modules later, don't worry).

And that's really all you need to know to be able to start recreating the world in Ruby! These concepts are the only things necessary to model the everyday things you see around you--and, indeed, kickass RPG systems. That's why you're here, right?

Recap:

Classes are the “templates” used to create an object.
Methods are the functions/subroutines that determine what the class can do.
Properties are pieces of data that describe the class.
Classes can be children of other classes, and will inherit any properties or methods the parent has in addition to its own.
Properties can be read/written either by creating getter/setter methods, or designating them as one of “attr_accessor”, “attr_reader” or “attr_writer”. Note that attr_accessor will allow reading and writing, attr_reader will be read-only and attr_writer will be write-only.
If a module, class or subclass have methods with the same name, the one that's lowest in the hierarchy will be used. Redefining a method that was already defined further up the chain is called “overloading”.

That's it for part 1 of Slip into Ruby! Feel free to tell me what you think; please let me know if I've said anything that's inaccurate or I missed something out in my explanations that would be useful.

In part 2 I'm intending to cover properties in more detail, including the different kinds of variable, and possibly go into parameters and arguments. If there's anything else you'd like an explanation on please let me know and I'll cover it either in part 2 or a later one.

------

Phew! The formatting needed some fixing from its original form, so I think I'm just gonna post these once a day rather than doing them all in one go. If you'd rather have them faster, though, I'm sure I can figure something out!

(Mods, if you could pin this, that'd be awesome, since it's intended as a replacement to the current pinned thread)

ShadowDragon · Mar 24, 2025

Ruby seems far more complicated than Javascript

JavaScript is already difficult for me to learn on my own, but its fun.

Ruby seems harder, but people knowing those language have lucky

but if this could be a question to you, what do you prefer?

JS or Ruby?

Trihan · Mar 24, 2025

ShadowDragon said:
Ruby seems far more complicated than Javascript
JavaScript is already difficult for me to learn on my own, but its fun.

Ruby seems harder, but people knowing those language have lucky

but if this could be a question to you, what do you prefer?

JS or Ruby?

JS hands-down. MV and MZ are so much easier to work with as I can use an external editor for my code and having a run-time console makes debugging infinitely easier.

Ruby can be fun though, as it has a much more native-English syntax than Javascript does, and supports some structures JS doesn't.

kyonides · Mar 24, 2025

Nope, some var=(val) method isn't a wrapper, it's a setter. It simply was manually created instead of using Module's attr_writter shortcut. Even if the setter included a conditional statement, it'd remain as a setter.

It'd be a wrapper in Ruby IF it had another name or a different number of arguments like set_vars(a, b) OR it's a custom spriteset class that lets you change all of its sprites' visibility state with a visible=(bool) method. Of course, there might be other ways to create wrappers that I haven't mentioned here like Game_Actors class being a wrapper class for a @data Array object that contains Game_Actor objects.

There's another correction I need to make here.

Trihan said:
If a module, class or subclass have methods with the same name, the one that's lowest in the hierarchy will be used. Redefining a method that was already defined further up the chain is called “overloading”.

Err, nope, that's OVERWRITING a method in Ruby.
The only way you can OVERLOAD a method in Ruby is by defining it in C/C++ and then create a wrapper CRUBY method, still accessible from Ruby, first to pick which of the low level functions will be executed based on the number of arguments or their Ruby classes.

ShadowDragon · Mar 24, 2025

Trihan said:
Ruby can be fun though, as it has a much more native-English syntax than Javascript does, and supports some structures JS doesn't.

can you give an example?

Trihan said:
I can use an external editor for my code and having a run-time console makes debugging infinitely easier.

this might be useful for me if I know how, as I think this also apply to Ruby?

Trihan · Mar 24, 2025

ShadowDragon said:
can you give an example?

this might be useful for me if I know how, as I think this also apply to Ruby?

Like just to use a simple example, the structure of if statements. In Javascript the condition always has to follow the keyword, but you can write it more "naturally" in Ruby, like

Ruby:

do_stuff if condition

Trihan · Mar 24, 2025

kyonides said:
Nope, some var=(val) method isn't a wrapper, it's a setter. It simply was manually created instead of using Module's attr_writter shortcut. Even if the setter included a conditional statement, it'd remain as a setter.

It'd be a wrapper in Ruby IF it had another name or a different number of arguments like set_vars(a, b) OR it's a custom spriteset class that lets you change all of its sprites' visibility state with a visible=(bool) method. Of course, there might be other ways to create wrappers that I haven't mentioned here like Game_Actors class being a wrapper class for a @data Array object that contains Game_Actor objects.

Seems a little pedantic given it doesn't affect the overall point and knowing the exact terminology isn't required to understand the lesson, but I've edited it anyway. Thanks.

Trihan · Mar 24, 2025

SLIP INTO RUBY PART 2 - MAKING A SCENE

Part 2 of a series explaining Ruby and RGSS in a way you can understand

Welcome back, RGSS scripters of tomorrow! Man, it's been a while since my last article, but I promised I wouldn't forget about the series and I'm finally ready to give you the next lesson. Today, we're going to cover how to actually make a new scene for your game, which is pretty much the heart of any new system you'll want to add.

The very first thing you'll want to do, in order to test things as you go and make sure everything is working as it should, is make a skeleton of your scene and implement a way to access it. Let's say we want to make a bestiary which shows info on the enemies in the game. Create a blank entry in Materials, just above Main, and type the following:

Ruby:

class Scene_Bestiary < Scene_MenuBase
    def start
        super
    end
end

This is pretty much the minimum you'll need for a scene. Note that it inherits from an existing class called Scene_MenuBase, which already contains some code for making the background etc. which will make life easier than having to code it yourself. However, even though this scene exists now, it's not accessible anywhere in the game. We can either access it through an event, or add it to the main menu. Adding it to the menu involves the "alias" keyword, which I'll cover soon, but for now let's just have an NPC that gives us info on monsters we've fought.

Create an event for your NPC, and in the event commands select "script". Write the following:

Ruby:

SceneManager.call(Scene_Bestiary)

Now playtest the game, talk to the NPC, and...well, nothing much'll happen yet. You will notice, though, that the screen goes all blurry. This tells you that you've entered your new "scene", which contains nothing right now but a blurry background.

Let's fix this by adding some windows. A window class is more-or-less self-sufficient and isn't restricted to any particular scene; once you've created the framework for a window you can create one anywhere you want. The first thing I'm going to add for our bestiary is a window that shows a list of the game's enemies, which can be scrolled through with the up and down arrow keys.

Ruby:

class Window_EnemyList < Window_Selectable
end

Again, this is the bare minimum you need for a window, but even if we create one in the scene it won't do anything yet. The first thing we want to do is add a constructor method, which tells RGSS what to do when first creating the window. Underneath the line beginning "class", write the following:

Ruby:

def initialize(x, y, width)
    super(x, y, width, Graphics.height - y)
    data = []
    self.index = 0
    activate
    refresh
end

The part in brackets defines parameters, or variables you will pass in when calling the method which will be used somehow later. In this case, when you create this window, you will have to provide an x/y coordinate and a width.

The first thing we do is call "super". This is a keyword that will call the method with the same name from the first available parent class; in this case, it will call the initialize method of Window_Selectable. If you look at this class in the script list you'll see it also requires four parameters: x, y, width, and height, so we have to provide these when using super. Note that I've provided a height of "Graphics.height - y", which simply means "the total height of the screen minus the provided Y coordinate" and will effectively stretch the window from whatever Y coordinate I set down to the bottom of the screen.

Next we set an array called data to [], which initialises it as empty. We do this on creation of the window to make sure we don't end up with duplicate entries when populating the variable.

Next self.index is set to 0, so that the window will open with the first entry highlighted.

"activate" will set the active property of the window to true. This doesn't so much do anything by itself but it means you can check to see what windows are active at any given time.

[RESURRECTED NOTE: The above is slightly incorrect. Activating a window causes it to start processing player input, which in the case of a selectable window means the arrow keys will scroll through its items.]

Finally, "refresh" will call the refresh method of the window. You'll note that it doesn't yet have one, and if you tried to use the window like this it would cause a NoMethodError to close the game.

Our next port of call is to create the refresh method so that error doesn't happen:

Ruby:

def refresh
    make_item_list
    create_contents
    draw_all_items
end

[RESURRECTED NOTE: The above is also incorrect. Window_Selectable already has a refresh method, so no error would occur. However, it only calls contents.clear and draw_all_items, so we still need to provide a class-specific version to make the item list. In hindsight, it might make more sense to call make_item_list and then just "super" to clear the contents and draw the items, and this may be more efficient than a call to create_contents every refresh, but it doesn't make a huge difference.]

Although create_contents and draw_all_items are not defined in this window class, they do exist in the parent class Window_Selectable, so they won't cause errors. make_item_list doesn't exist anywhere yet, though, so we need to define it.

Ruby:

def make_item_list
    @data = $data_enemies.compact
end

Note that instead of calling make_item_list we could just have put that line in refresh. It's really personal preference, but I would recommend that for any "block" of code that's more than a couple of lines, put it in its own method and then call that method where the block of code was. It keeps things neater. The only reason I used make_item_list here was to keep it consistent with the existing menu-type classes.

$data_enemies is a global variable containing an array of all the enemy data from the database. Compact is a new method available to all arrays which removes any empty elements from it. Basically, make_item_list will set the @Data array to a list of all your enemies, taking out any blank entries.

If you were to create the window now, you'd notice that you could see a flashing cursor, but you can't move it and there are no entries. This is because we have one slight problem.

Window_Selectable is smart, but it doesn't know everything. Unless you tell it otherwise, it assumes that you want to draw 0 items in the list. We have an array called @Data which will tell us how many monsters there are, but we still need to add a method called item_max to let the window know this.

Ruby:

def item_max
    @data ? @data.size : 1
end

If you were to create the window NOW, you'd be able to scroll through the list but the entries would still be blank. Jeez, what gives? Well, draw_all_items might exist, but all it does is call a method called draw_item, which in Window_Selectable is blank. In short, it doesn't know how to draw our list unless we tell it what to do. Let's define draw_item:

Ruby:

def draw_item(index)
    item = @data[index]
    if item
        rect = item_rect_for_text(index)
        draw_text(rect, item.name)
    end
end

Okay, let's walk through what we're doing here. draw_item requires a parameter, index. draw_all_items will loop through all the items in the list, so index will simply be the array element it's currently looking at.

We set a temporary variable called item to the [index]th element of the @Data array. We then have an if statement checking whether item actually exists, because if there isn't an [index]th element there, the game will crash if we try to do something with it (specifically it'll crash on the line with item.name, because there won't be a name property to access if there's no item)

item_rect_for_text is a lovely little method available to Window_Selectable and its child classes, which basically works out the area required to display text in one "slot" of a selectable window. We need to do this because draw_text requires a rectangular area to draw the text inside, and we can't provide static values because we're looping through a list and don't know at any given moment what that text is going to be or which position we're drawing it in. Aren't dynamic methods great?

And finally, we draw_text using our previously-calculated rect, and item.name. In this case, item is going to be the current enemy, so the .name property will return the enemy's name. You don't need to worry about the text's Y coordinate (to make the list read downwards); that's all handled by the item_rect_for_text method.

Okay! You've worked long and hard with no tangible reward yet, so let's show you the fruits of your labour. Go back to Scene_Bestiary and underneath "super" write:

Ruby:

@list_window = Window_EnemyList.new(0, 0, 200)

Now playtest your game, talk to your NPC, and you'll see something like this:

If you can see the same thing, congratulations! You've totally just created a new scene, a new window, and put them together. Wasn't as hard as you thought after all, was it?

Now that's all well and good, but you'll notice that although you can access your new scene, once you're in you can't get out again. We're going to need a way to return to the map when ESC is pressed, and we do that by adding the following line in the start method of Scene_Bestiary:

Ruby:

@list_window.set_handler(:cancel,  method(:return_scene))

set_handler is another very useful method of Window_Selectable that allows you to specify an input symbol and a method to call when the associated key is pressed. The great thing is that for things like OK, Cancel and the like, all the gruntwork is done for you already. In this case, we're going to call :return_scene (itself a built-in symbol that calls the scene prior to the one you're currently in, which is obviously the map) when the :cancel key is pressed (which unless you change the key setup will be ESC). I'll cover set_handler, symbols, and the available default options a bit more in part 3.

Our final script (for now) will look like this:

Ruby:

class Scene_Bestiary < Scene_MenuBase
    def start
        super
        @list_window = Window_EnemyList.new(0, 0, 200)
        @list_window.set_handler(:cancel,  method(:return_scene))
    end
end

class Window_EnemyList < Window_Selectable
    def initialize(x, y, width)
        super(x, y, width, Graphics.height - y)
        data = []
        self.index = 0
        activate
        refresh
    end

    def item_max
        @data ? @data.size : 1
    end

    def make_item_list
        @data = $data_enemies.compact
    end

    def draw_item(index)
        item = @data[index]
        if item
            rect = item_rect_for_text(index)
            draw_text(rect, item.name)
        end
    end

    def refresh
        make_item_list
        create_contents
        draw_all_items
    end
end

There's quite a lot of new stuff in here and I don't want to overwhelm you, so I think we'll end today's lesson there. Next time I'll show you how to display a picture of the enemy, and a window listing their stats.

Recap:

Scenes will usually inherit from Scene_MenuBase.
The "super" keyword will call the method with the same name from the first available parent class.
Windows don't do anything unless you create them as an instance variable in the scene.
Selectable windows need, at the minimum, a refresh method to tell it what to display, an item_max method to tell it how many things are in the list, and a draw_item method to tell it what it actually needs to draw in each space.

As usual, comments, corrections and criticisms are welcome. Please feel free to suggest topics for further parts, too.

Inada · Aug 5, 2025

No more?

Trihan · Jan 30, 2026

Rpgmaker.net is back, so all the Slip into Ruby articles are too!

Nacnac42 · Feb 14, 2026

Love this tutorial!! I am trying to do something similar but would still consider myself beginner and keep running into walls trying to figure out some of this stuff.

I have a campfire event spawn on location in front of character with use of a key item and then call Scene_Camp. The initial menu is firing. I am just starting on this but feel like my code is heading the wrong direction as i try to expand on it. This code is far from complete, but a few questions b4 I fall down the rabbit hole..

Should Window_CampCook < Window_ItemList be Window_Selectable?
I am assigning a note to raw items <cook> that will populate the menu and selecting them will result in cooking them (I will need to add a method for recipes after this is functional) but that is not my focus at the moment.
Am I using the correct approach with the include?(item) function in that same method?

Any input is greatly appreciated regardless of if I am asking the wrong questions!

class Window_CommandCamp < Window_Command
def make_command_list
add_command("Cook", :cook)
add_command("Rest", :rest)
add_command("Exit", :exit)
end
def command_cook
SceneManager.call(
end
end
class Window_CampCook < Window_ItemList
def include?(item)
case @category
when :item
item.is_a?(RPG::Item) && item.note =~ /<cook>/i
else
false
end
end
end

class Scene_Camp < Scene_MenuBase
def start
super
create_background
create_windows
end
def create_windows
@mycmd = Window_CommandCamp.new(150,150)
@mycmd.set_handler( :cook, method(:cook))
end
def cook
p 'cook'
@mycmd.active = true
SceneManager.call(Scene_Cook)
end
end
class Scene_Cook < Scene_MenuBase
@cook_items = Window_CampCook.new()
end

Edit: I went down the rabbit hole! lol
This is functional but still requires some adjustments for appearance and methods to expand it. Please critique. As I said, I am a beginner and don't want to teach myself bad habits. thanks

class Window_CommandCamp < Window_Command
def make_command_list
add_command("Cook", :cook)
add_command("Rest", :rest)
add_command("Exit", :exit)
end
end

class Scene_Camp < Scene_MenuBase
def start
super
create_background
create_windows
end
def create_windows
@mycmd = Window_CommandCamp.new(150,150)
@mycmd.set_handler( :cook, method(:cook))
@mycmd.set_handler(:cancel, method(:return_scene))
end
def cook
p 'cook'
@mycmd.active = true
SceneManager.call(Scene_Cook)
end
def Rest
p 'rest'
@mycmd.active = true
end
end
#---------------------
class Scene_Cook < Scene_MenuBase
def start
super
@list_window = Window_CampCook.new(150, 150, 400)
@list_window.set_handler(:cancel, method(:return_scene))
end
end

class Window_CampCook < Window_ItemList
def initialize(x, y, width)
super(x, y, width, Graphics.height - y)
@category = :item
@data = []
self.index = 0
activate
refresh
end
def include?(item)
case @category
when :item
item.is_a?(RPG::Item) && item.note =~ /<cook>/i
else
false
end
end
end

Slip into Ruby Resurrected!

Trihan

Speedy Scripter

SLIP INTO RUBY PART 1 - OBJECT-ORIENTED WHA?

Part 1 of a series explaining Ruby and RGSS in a way you can understand.

ShadowDragon

Realist

Trihan

Speedy Scripter

kyonides

Reforged is laughable

ShadowDragon

Realist

Trihan

Speedy Scripter

Trihan

Speedy Scripter

Trihan

Speedy Scripter

SLIP INTO RUBY PART 2 - MAKING A SCENE

Part 2 of a series explaining Ruby and RGSS in a way you can understand

Inada

Warper

Trihan

Speedy Scripter

Nacnac42

Villager

Latest Threads

Latest Posts

Latest Profile Posts

Newest members

Forum statistics

Slip into Ruby Resurrected!

Speedy Scripter

SLIP INTO RUBY PART 1 - OBJECT-ORIENTED WHA?​

Part 1 of a series explaining Ruby and RGSS in a way you can understand.​

Realist

Speedy Scripter

Reforged is laughable

Realist

Speedy Scripter

Speedy Scripter

Speedy Scripter

SLIP INTO RUBY PART 2 - MAKING A SCENE​

Part 2 of a series explaining Ruby and RGSS in a way you can understand​

Warper

Speedy Scripter

Villager

Newest members

Forum statistics

SLIP INTO RUBY PART 1 - OBJECT-ORIENTED WHA?

Part 1 of a series explaining Ruby and RGSS in a way you can understand.

SLIP INTO RUBY PART 2 - MAKING A SCENE

Part 2 of a series explaining Ruby and RGSS in a way you can understand