Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

Windows with RGSS (Creation and Implanting in Scenes)

I decided to write a little tutorial because most of the people that can't script always complain about how to create windows with scripts. This should finally render all questions related to those simple things obsolete and also give RGSS-newcomers an easy start.


Part 1 :: Basic Knowledge

Windows get defined by a class, it's called class Window. If you look into Window_Base, you can see this line at the beginning of the script:

Code:
class Window_Base < Window

The phrase class Window_Base defines the name for the current script, Window is the superclass. Since all definitions from a superclass are available in the current class (in RGSS, the current class is called self), you can't find them all inside class Window_Base.


A window is created by different factors. They're defined by super(). Inside the brackets, four constants have to be defined: x, y, width, height; as you can see all seperated by a comma.

http://img130.imageshack.us/img130/3518/018yy.jpg[/img]

As you can see in the above image, all four elemnts together describe the position and shape of the window. Here comes a more specific explanation:

x : Defines the distance between the left border ( x = 0 ) and the window. Setting x = 0 makes the window sticky to the left side.

y : Defines the distance between the upper border ( y = 0 ) and the window. Setting y = 0 makes the window sticky to the upper side.

width : Defines the horizontal size of the window.

height: Defines the vertical size of the window.

The code for that window is super(224, 192, 192, 64). Don't get confused by the two instances of 192, this is just a coincidence because of a bad example, my fault ^_^.


Part 2 :: Creating a Window

As already said, Windows are based on class Window_Base. You can either create a window class with that class as a superclass (examples can be found in nearly every window class, e.g. Window_Gold), or create a window directly in a scene also using Window_Base, but in another way. I'll explain both ways.


1st: New Window Class

Like I already said, Window_Gold is an example for the first way of making windows. Using this method gets you more classes in the end, but your actual scenes will be cleaner. It's the better way as soon as you have a window with content, which applies to almost every window.


2nd: Window based on Window_Base

Mostly used in custom systems like menus, this method is only advantageous if you use it as a dummy window, meaning a window that has no content, but draws the outline. A good place to demonstrate this is class Scene_Menu. Take a good look at the following two pictures:

http://img238.imageshack.us/img238/128/025po.jpg[/img]
http://img148.imageshack.us/img148/7034/036rk.jpg[/img]

The first screen shows the default class, while the second screen shows the class with a less than 10 additional lines. To achieve the same with independent window classes, you'd need approximately 200 lines of code.
The second screen was done using dummy windows. I won't post the code for that here, because that's a good thing to try by yourself. If you read this topic carefully, you shouldn't get any problems.

The clue on how to use windows based on Window_Base class is the following line:

Code:
@window = Window_Base.new(x, y, width, height)

This can be inserted to the scene directly. For implanting it correctly into a scene, please read Part 5 of this tutorial.


Part 3 :: Window Content

Of course, a window is of no use if one doesn't how tow to put anything into it. I'll only cover text here for now, because this is the most generic type of content seen in windows.

To show text, you need to use a text draw definition. This definition is named draw_text. On a side note, if you search for it in script editor, you won't find it. This definition is softcoded to RMXP, what means you can't see it, but by rewriting the same definition somewhere, you can overwrite it.

Like I mentioned before, self is the name for the current class.
contents is some kind of sub-folder in which the definitions are stored. I'll explain that right after the code for the draw text command ...
draw_text needs a few constants, too. The first four are the same as the window ones, so look them up if you can't remember. There are two additional constants called text (the actual text string to display) and align (the alignment inside the text field, 0 is left, 1 is centered, 2 is right).
At last, you need to know that these code pieces are connected with dots ( "." ) in Ruby and RGSS.

All together, it get's you the following code:

Code:
self.contents.draw_text(x, y, width, height, text, align=0)

Now the sub-folder thingy will be explained along with the structure of this line. The line is some kind of a pointer for the program to find it's way through the code.
The first thing in line defines where the [not defined yet] should be executed. In that case, it's self, so the draw_text command will be executed in the current class.
contents tells the proram that the class shouldn't be changed, but instead, content should be added.
draw_text finally tells the program that text should be drawn. In the definition, constants will be used to make the code more flexible. You can see the align=0 in my code. That means, the value is by default 0, so not giving any value for align and instead just giving the first five constants would be fine for the interpreter. This works only for the last command(s) in a line.

Of course, you do not have to set self as the target class. You could insert a window based on Window_Base and set it's contents by using @window.contents.draw_text(...) in any Scene_ class.


Part 4 :: Window Settings

You also do not have to set contents as the definition for the window, there are several other things you can set instead.


If you want to change a window's position from a scene or inside the window, but after the initialize-definition, you have to use the following code:

Code:
self.x = x # inside the window class
@window.x = x # in a scene where @window is defined

This does of course not only work with the x-value. Allowed operators are, for example:

Code:
x
y
z # depth-position of the window, setting it higher will make it 'above' windows with lower value
width
height
opacity # (the transparency of the whole window, but not the content; from 0 (fully invisible) to 255 (fully visible))
back_opacity # (the transparency of the window's background, but not the content or the border, same range)
font # (may be expanded by name or size (seperate with a dot) to change the fontname or the fontsize)
index # (used to define the cursor's position in a subclass of class Window_Selectable)

These codes are fully optional, which means setting them is okay, but not setting them is okay, either. This doesn't apply to the four window definition constants, of course.


Part 5 :: Window Implanting

Now for the fun part: The actual integration of the windows to a scene. We'll do an easy example, which is adding two windows to Scene_Title. Here is an example of how it should look like if it's finished:

http://img151.imageshack.us/img151/2476/040ce.jpg[/img]

1st: A show text window, like my window from the first image. It should be centered horizontally, sticks to the upper border of Scene_title.command_window and contain a centered text saying "Title Menu", and it should be 64 pixels high.
2nd: A dummy window that replaces the backgrounds and borders of the other two windows.

The first step is always the window creation, but that has been explained before. Once the window is created, the next step is adding it to the scene, to be more precise: Define it in the main definition, before Graphics.transition. To do this, you need a class-internal name for the window, like @info_window. Now you need to keep the name of your window class ready, something like class Window_Info works for me. The code for adding it:

Code:
@info_window = Window_Info.new

This assigns the Window to the internal name @info_window. The phrase .new at the end of the line is used to tell the program that the window is defined here. I don't know a single case where you'd use that code without the .new behind.

This displays the window. If you start your game now, you'll be able to see it in Scene_Title. If you continue with e.g. starting a new game, you'll notice the window stay on screen. To prevent this, you need to dispose it. This is also done in main definition, but after Graphics.freeze. Just add this below the other dispose codes:

Code:
@info_window.dispose

If you test it now, it'll dispose if you start a new game.

There are windows that change their content while in the scene. You need to update those windows, like you need to update the @command_window inside Scene_Title. Look inside the update definition and you'll see the code for it. If @info_window would be a window that changes it's content, you'd need to put the following line inside the update definition:

Code:
@info_window.update

Well, in this case, it doesn't make any sense but to drain RAM, so leave it out ;)


There's one window left, the dummy window. We're going to define it inside Scene_Title, rather than as an individual window. I already told you how to do windows based on Window_Base and also all attributes you need. Now it's up to you to get what's shown in the fourth picture. If you can't figure it out on the first try, re-read the part where I told you that and try again.

Good luck and enjoy.
 
Thanks for your comment (or is it supposed to be 'thanks for noticing my thread' ? ^_^ )

Coloring the codes would be more hard than useful, because it's easy code everyone should get at first sight, while making every comma and dot blue is rather time-soaking ^_^
 
Will you make some more? On other subjects? Like Game_Character Scene_map, that kind of things? Telling what the variables are and what they do..., just a question.
 
I'm doing tutorials if I feel that I can do them (I'm also an RGSS beginner, you know? ^_^ ) and if I see that another noob asked how it's done though it has been explained a thousand times... Therefore, I'll surely do other tutorials *lol*
I'm fairly familiar with the Game_Character scene because of my 8-way-8-frame movement system for my game, and of course I know Scene_Map, I just wonder why I should explain them, because it's more helpful to people to explain the what-to-do rather than the where-to-do, in my opinion...
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top