Home > Tutorials > Ruby Game Scripting System > RGSS For Dummies Tutorial 6: Game Programming 101
RGSS For Dummies Tutorial 6: Game Programming 101
Introduction
This tutorial will introduce you to some basic ideas game programming (or scripting) in general, and about RGSS in particular. You'll need these basics to be able to understand how RGSS and RMXP work. Once you know that, you can easily edit or add to the default scripts in order to make the next Final Fantasy game.
RMXP uses RGSS as code for the entire game, unlike some other makers, RMXP gives you the source code of the game (well, some things are still built-in). This approach is really powerful because you can change almost anything, you can even delete all the default scripts and write your own game from scratch (I did this once, it was a nice Pong game!).
Contents
1. Game Loop
1.1. Input
1.2. Logic
1.3. Graphics
2. Scene
3. Data Variables
4. Game Variables
5. Sprites and Bitmaps
6. Windows
7. The Interpreter
8. Conclusion
9. Summary
1. Game Loop
To make anything interactive, you need a loop. Otherwise the program will end once all the instructions are executed. To keep the game running until the player exits, you need a loop that keeps updating everything until the player leaves the game. What do I mean by everything? First, input must be updated to detect what buttons are being pressed. After that, the game 'logic' needs updating, logic could be anything from calculating enemy's next action to choosing a random direction for an NPC to move to. Finally, the graphics need to be updated all the time to reflect changes in the scene, like moving the player or drawing tiles. A simple game loop might look like this:
Code:
while (game is running)
update input
update logic
update graphics
end
If you recall the simple definition of computers: computers take input, process it, and then produce output. In games, input is buttons, processing is game logic, and output is graphics.
1.1. Input
In games, input often refers to the keyboard, joystick, mouse, or any device that allows you to input messages to the computer. Input needs to be checked all the time to see what keys/buttons are pressed.
1.2. Logic
Before drawing anything, you need to figure out how to draw things. If you checked input and noticed that a direction key is pressed, you need to calculate hero's new position and what part of the map will be drawn. When you enter a new map, the map's data must be loaded and the map's music must be played. When you're fighting an enemy, you need to calculate the damage that the enemy does, the effects of magic on heroes, and check if the enemy died (enemy HP = 0) to end the battle. All these are examples of the 'logical' part, you need to calculate stuff and do things that might not be visible to the player.
1.3. Graphics
Every loop, the screen needs to be redrawn to reflect any changes. Changes include: characters moving, weather effect, menu cursor moving, battle animation, etc. Each graphical update is called a frame. The term Frames per Second (FPS) refers to the number of times graphics are updated (how many frames are drawn per second). The higher the FPS, the smoother and faster the game might look. Graphics are simply drawn by placing images on the screen, this process is often called blitting (comes from bit block transfer).
2. Scene
Updating input, logic and graphics could be done via functions. The problem is how to handle changes in the game state? On a map, pressing up will move the main character north. In a menu, however, pressing up moves the cursor up. In a game over screen with a "press any key to continue" text, pressing up will take you to the title screen. As you can see, input is handled differently in different scenes. Logic and graphics are handled differently too, drawing a map is different than drawing a battle scene. A scene is simply a game state with special input, logic, and graphics. RMXP handles scenes this way: There is a separate class for each scene, each class has methods and variables to update itself (update input, logic, output). The current scene is a global variable, changing the variable's value changes the scene. Each RMXP scene has a method called main; this method is called from the game's main loop (defined in the Main script, the last section in the script editor). The main script looks like this:
Code:
$scene = Scene_Title.new
while $scene != nil
$scene.main
end
First, the $scene variable ($ means that it's global, it can be accessed in any script) is set to an object of type Scene_Title, because the first scene in a game is the title screen. After that, we have a loop that exits if the value of the $scene variable is nil. Nil is a special value in Ruby, it simply means "nothing" or "undefined". A simple way to exit the game is setting the scene variable to nil, this will break this loop and without looping, the game ends. Inside the loop, the main method of the scene is called. The main method itself will update its scene. For example, when you select "start game" in the title screen, Scene_Title will simply change the value of $scene to Scene_Map.new, which will changes the scene to the starting map.
3. Data Variables
So, what makes each game different if the RGSS code is the same? It's the things you do in the editor, the maps you design, the items, spells, heroes, etc. that you create in the database, and the graphics you import. But how does RMXP know about this stuff? Simple, when you change the database, these changes are saved in files (with the extension .rxdata). In the title screen scene, the data is loaded into special global variables. After that, any script can access the database data using those variables. For example, the item data is stored in a global array called $data_items, each item is stored as an RPG::Item type that can be accessed through its number in the database. You can easily get the name of the first item in the database using $data_items[1].name.
4. Game Variables
The data variables store data with fixed values, that is, data that was defined in the editor (database for example). As the game progresses, there are some game data that changes depending on gameplay. For example, you can get the starting party members using the $game_system variable, but what if new members were added or existing members were removed? You need a variable that holds updated data that reflect the current game. RMXP uses global variables that start with $game_, they contain current information about the game such as the party members, the items held, the values of switches, etc. To get the name of the first hero in party (as apposed to the first hero in database), you use $game_party.actors[0], and to change the value of the first switch you can use $game_switches[0].
5. Sprites and Bitmaps
To draw stuff to the screen, you use sprites. Sprite is a built in class that represents an image that could be placed on the screen. Bitmap is also a built in class that represents image data. What's the difference? A sprite is like a frame that can be placed anywhere in the room, a bitmap is like a painting or a photograph that must be placed inside a frame. A sprite holds an image, but not the other way around. Bitmaps in RMXP have certain attributes like width, height, etc. They can be used to store the hero's charset, for example. But without a sprite, you can't draw the hero to the screen. The sprite defines the location (x, y, and z) where the bitmap will be placed.
6. Windows
RMXP has a built-in class called Window, it's similar to a sprite that can be associated with a window skin (which is basically a bitmap). Windows also have a contents bitmap, contents might include text or pictures that are on this window. RMXP defines two types of windows, basic windows that just display stuff (like the gold window in the menu screen), and selectable windows that have cursors (like the item window).
7. The Interpreter
RGSS handles the normal (point and click) RMXP events by using an interpreter. The event commands (such as showing a message or adding a party member) are saved in the map file, after that the commands are loaded by the Interpreter class and parsed (read). Each command has a unique number, and the Interpreter class has a method associated with each number. The method is called when the command is parsed.
8. Conclusion
You didn't understand anything? That's okay, I just wanted to give you a general idea about what to expect when dealing with RGSS. The following tutorials will explain data and game variables, sprites and bitmaps, and other built-in classes in more details.
9. Summary
- Games instructions are repeated in the loop. The instructions fall into three categories, input, logic, and graphics.
- Each scene processes its own input, logic, and graphics. A variable is used to refer to the current scene.
- Data variables store database information.
- Game variables store information about the current game.
- Sprites and bitmaps are used to draw pictures to the screen.
- Sprites hold bitmaps, and define their position on the screen.
- Bitmaps represent a picture and its information (like width, height).
- There are two types of windows, basic windows and selectable windows.
- The interpreter reads point and click event data and executes them.
- If you jump too high your head will explode.
|
|
Details
|
|
Tutorial:
|
RGSS For Dummies Tutorial 6: Game Programming 101 |
|
Date Listed:
|
2008-06-05 |
|
Author:
|
RPG
|
|
Total Hits:
|
7093 |
|
|
Submit Your Article
Guild Wars 2 Forum
RPG Maker VX.com
