Windows Tutorial Part 2/2[/color]
Warning: I like to simplify my tutorials for noobs. If you find this too easy to understand I apologize. I make tutorials that way.
This is not a tutorial on making a CMS. That is for my third tutorial. This is understanding scenes.
Length: Fairly long
Other Past Tutorials
-RPGMaker XP Tutorial 1 For Noobs
http://www.crankeye.com/forums/viewtopic.php?p=55556#55556- Windows Tutorial Part 1/2
http://www.dubealex.com/asylum/index.php?showtopic=5915Scene InteractionWindows are the basis of any menu. You do not necessarily need a window for a scene. Defining a window and a scene is fairly
simple, though, and can be sumed up into short "dummy" words.
A
Window is a piece of paper.
A
Scene is your desk.
Consider you are at school in a class. When you take notes you write on paper. And the paper is laid on a desk or table right?
Well if you think about it RGSS makes Scene Interaction the same as this example.
A Window is basically a box to show some data whether it be strings (text), values (integers, booleans or floats), or information
about another class!
A Scene is basically the "desk" or "table" you write on. This is where you can organize your windows into specific places (you can
do this anyway in the window itself, but I prefer this way).
Well in order for your to actually write a script with RPGMaker XP you need some sort of interaction between the windows (if any)
and the characters and/or actual gameplay. This interaction will always include some sort of
loop.
LoopI have been warming up to talk about this part. This is the main focal point of this tutorial. This is a quick
but crucial
part to this tutorial. If nothing else please understand this.
Everything about RPGMaker XP's use of scripts is a loop. Whether it be if rmxp is checking for a button interaction from the player, a
certain switch activated, a battle, graphic updating, a condition met, etc., it contains a loop nonetheless.
Loops can be broken down even further though.
Let's assume you create a script that makes each enemy contain a limit break. Whether the enemy actually uses this limit break in
battle is irrelevant. The point is, is that rmxp is constantly checking to see if this loop is still valid. If not it could go to another condition
or if all else fails feedback an error or quit the program entirely.
And if loops are the basis for RPGMaker XP, it must be the basis for Scenes.
ScenesScenes are what makes RPGMaker XP tick. Let's take a look first at probably one of the most important Scenes, then we'll head to
the most commonly used Scene.
If you recall from the first tutorial a window is basically a place that stores info.
If you used the window example in that tutorial you found out that the window would not
dispose when you wanted
it to. That's because you did not define a specific time for it to dispose. While the window showed up, a Scene was still occuring.
That Scene is Scene_Map. Because you did not specify a specific time to dispose the window the good guys at Enterbrain
specified a time for you. Hence rmxp is constantly looping.
If you put that window in a Scene correctly you can get rid of it whenever you like and return it in the same fashion!
Let's take a look at Scene_Title. We'll go through each part step by step.
Scene_Title
class Scene_Title
Here we have defined a new class called Scene_Title. Be careful not to confuse you with Window_Blah < Window_Base. As I said
earlier a window must have his parent with him. He is the "underclass". A scene is not.
def main
# If battle test
if $BTEST
battle_test
return
end
Here of course we defined a new method and also gave a
hidden global variable $BTEST a condition. If
$BTEST were true then the method battle_test would be commeneced and would also return the data. But this is important. This
time we defined a new class called main.
Here's some questions you might ask.
-Why did you make it def main?
-Why wouldn't you put def initialize?
def main is a very important method and here's why. Scroll down to the script at the very bottom called Main.
At around line 12 you'll see this.
$scene = Scene_Title.new
# Call main method as long as $scene is effective
while $scene != nil
$scene.main
end
This means that a global variable $scene is assigned to the class Scene_Title. And while this scene is not equal to nil (nothing)
then Main is constantly being updating by the rmxp and is always checking to see if $scene is equal to an actual scene
and if so it must have a method called def main. If you take a moment to just look at it, it makes perfect sense.
Another thing I want to point out. Main is
not a script. It is a beginning block of code so to speak. No where in the
script Main does it start with class Main. That is why most people say "Add this script above Main" because main is the default
place in which rmxp reads or begins the data. It calls $scene = Scene_Title.new which we're going back to now. Just wanted to point
that out.
Now your probably saying now:
-Well if you don't need def initialize, can't you still put it?
Of course! But there is no need to do that in this case. If you recall Main is only thinking about the main definition (def main)! So yes
you could put something in initialize but it would not matter. It would call initialize and thats it. After that it wants the main definition.
Ok!
Back to Scene_Title.
$data_actors = load_data("Data/Actors.rxdata")
$data_classes = load_data("Data/Classes.rxdata")
$data_skills = load_data("Data/Skills.rxdata")
$data_items = load_data("Data/Items.rxdata")
$data_weapons = load_data("Data/Weapons.rxdata")
$data_armors = load_data("Data/Armors.rxdata")
$data_enemies = load_data("Data/Enemies.rxdata")
$data_troops = load_data("Data/Troops.rxdata")
$data_states = load_data("Data/States.rxdata")
$data_animations = load_data("Data/Animations.rxdata")
$data_tilesets = load_data("Data/Tilesets.rxdata")
$data_common_events = load_data("Data/CommonEvents.rxdata")
$data_system = load_data("Data/System.rxdata")
# Make system object
$game_system = Game_System.new
These create global variables equal to the method load_data and it's attribute. In this case it's attribute is stored in the data folder.
When the def main method is called before the beginning of the game these values will be started. Also we have set the global
variable $game_system to the script Game_System. Game_System is not a scene. It does not have the main method or a
Window_Base or any other superclass, therfore it will simply be classified as a "value" script as I like to call it. It will then be called
by another script.
s1 = "New Game"
s2 = "Continue"
s3 = "Shutdown"
@command_window = Window_Command.new(192, [s1, s2, s3])
@command_window.back_opacity = 160
@command_window.x = 320 - @command_window.width / 2
@command_window.y = 288
This is important as well. RPGMaker XP has defined three local variables (s1, s2, s3) and assigned them to the string values "New
Game", "Continue", and "Shutdown".
Then it sets the class variable @command_window equal to the class Window_Command. Window_Command contains two
attributes in order for it to be called correctly. This is the syntax:
Window_Command.new(width, commands)
Look inside Window_Command to see what I mean if your confused.
Next it sets the class variable @command_windows
hidden method back_opacity equal to 160, it's x method
equal to 320 minus itself's width divided by 2, and it's y method equal to 288.
This is extremely useful because it's basically saying hey I'm editing myself!
This will call the Window_Command. It's default syntax will create a window with these attributes I just mentioned.
(I skipped some stuff to save time)
Graphics.transition
# Main loop
loop do
# Update game screen
Graphics.update
# Update input information
Input.update
# Frame update
update
# Abort loop if screen is changed
if $scene != self
break
end
end
# Prepare for transition
Graphics.freeze
# Dispose of command window
@command_window.dispose
# Dispose of title graphic
@sprite.bitmap.dispose
@sprite.dispose
end
This refers back to loops. If you are going to create a scene you must loop it. That is the syntax you use. The only thing you would
change is the class variables of the windows (if any) you defined earlier in that method (@command_window.dispose to
@window_blah.dispose).
YOU ALWAYS USE THAT SYNTAX! Of course you can add more but that is the basis of your graphics, button pushing, and scene
transitions.
#Frame update
update
is the method def update. If you do not create an update method, do not put updte in the Main Loop. It will give you an undefined
local variable or method error.
I won't go any further with Scene_Title. The whole point of this is for you to interact with the scenes and find out how it works. I just
gave you the gist.
Ok....
So what have we learned? Scene Interaction, loops, more on methods, more on variables, main method, "value" scripts (scripts that
are neither windows nor scenes), how to call methods, a little more on conditional statements (if this happens then this happens).
If you read this tutorial I'm sorry but you won't create your CMS until next tutorial (Custom Menu System Development).
I thank you very much for reading this tutorial and hope you find this helpful to your needs. If you have any questions or errors
please send them via my website. I don't check often with other people's replies on other forums. Thank you for reading.
~Constance
Discord
Light Style