Menus and Complex Variable Functions

[drenrin2120]

Introduction

In this tutorial I plan to go over many functions of variables in rm2k3. This tutorial will NOT explain basic functions of variables such as modulus, referencing, adding, dividing, multiplying, etc., and will not explain exactly how to go about implementing these ideas into rm2k3. Some of the many things I hope to cover will range from implementing variables into a comprehensive menu system, auto-scroll and "temporary" variables. I have a lot to talk about and I'm not entirely sure how I'm gonna organize it all. So, bare with me as I try to share the techniques I've learned over the years. Hopefully, this will help and inspire others to create their own custom systems in rm2k3 and on other platforms while thinking outside the box.

CHAPTER 1
An Overview of Basic Concepts

If you want to create your own custom menu, you first have to understand the basics of menus. Menus come in all shapes and sizes and work in many different ways. There is no one set rule for making a menu. However, there are two concepts about menus that must be fully understood. The mechanical properties of the menu and the information it is trying to access. For example, I can tell you how to create a menu that allows the player to scroll around and look at items using a cursor, or how to create an auto-scroll effect, but what good is all that if nothing happens when they press enter? How do you connect a picture you imported into rm2k3 with an actual potion or other item? This is the basic function at the heart of all menus: an easy-to-use, easy-to-navigate interface for the user to connect with information stored in the game. In order to understand my ways of getting around these roadblocks, there are a few terms you should understand. Some are basic mathematics you may already be familiar with, others are terms I coined myself to give a little order to what I was trying to do.

LIST: is a group of SLOTS. These SLOTS are arranged on an informal coordinate plane (x,y). All menu builds presented in this tutorial can be broken down into coordinate planes.

COORDINATES and PLANES: There are two coordinate planes, x (horizontal) and y (vertical). A coordinate is a number referring to a position on a coordinate plane. For the purpose of this tut, a coordinate plane becomes the menus horizontal SLOTS and vertical SLOTS. This could also be represented as (x SLOTS, y SLOTS)

SLOT: This term is used very often to refer to an imaginary position on a plane of coordinates. The term SLOT is used because, generally, some sort of information is referenced at a SLOT's coordinates.

ID: An arbitrary number stored in a SLOT which refers to something else (an item, a character, a path to another menu, etc).

SCROLLING: is when a cursor moves about a menu (coordinate plane) or when the menu moves about the screen. Often times, when a menu SCROLLS, part of it is not viewable on screen.

TEMP VARIABLE: This is exactly what it sounds like. A temporary variable stores information for temporary use. Temporary variables are extremely important and can allow the programmer to cut back on code a considerable amount. Many tasks might simply be daunting to complete if you did not implement Temporary variables.

DATABASE: A database is a point of information access for in game variables. In rm2k3, a database would take the form of a Common Event. Mostly temporary variables use Databases. Databases can store any kind of information: item stats, monster stats, character stats, skill stats, attack equations (custom battle systems). For example, in a custom battle system, variables can not access data stored in rm2k3's default monster database, the user must create their own database of monster stats.

Okay, I think that's it. These are the crucial terms I've come up with to describe certain concepts that are otherwise hard to explain.

CHAPTER 2
Coordinate Planes and Menus

PART 1: The Framework
Laying out the framework of your menu.




We'll start with an item menu. The above picture displays the rm2k3 default Items Menu. Inside the red border are all the items this player has acquired. Each one of those items represents a so-called SLOT. We are not currently concerned with slots and their function. We are more concerned with establishing the coordinate plane, the framework to our menu.

Coordinate planes act like tracks. Cursors roll through the menu on these tracks where ever the player tells it to go. In the above picture, our x coordinate plane is represented by the green lines moving horizontally across the screen. Our y coordinate plane is represented the blue lines moving vertically across the screen. At every point these two lines intersect is a point where the cursor will stop. These points are where not only we get our coordinate numbers, but where we place our SLOTS.

Find the "Ether" in the item menu above. Note it's location. It's coordinates on this menu are (2,5). For the following you will need:

two variables for the Cursor's location: "Cursor X" and "Cursor Y"
if you are using rm2k3, you'll need a "Key Input" variable.

In the rm2k3 default menu displayed above, we have a total of 22 possible slot positions. That's 22 coordinates from (1,1) to (2,11).  Every time the player enters this menu, a variable called "(x)" and variable called "(y)"would both be set to 1. Whenever down was pushed, 1 would be added to variable y unless y equals 11 in which case nothing would happen because this would mean the cursors coordinates are (1,11). It could not go any farther down on the vertical axis. Whenever right was pushed, 1 would be added to variable x unless x is equal to 2, because this would mean the cursor can not go any farther right on the horizontal axis. The opposite is true. When the player pushes up, 1 would be subtracted from y unless y equals 1. If the player pushed left, 1 would be subtracted from x unless x equals 1.

NOTE: This tut assumes you already know how to place a cursor picture on the map and use variables to move it around. One piece of advice, use MOVE PICTURE commands as often as you can. Too many SHOW PICTURE commands will cause tremendous lag. Whereas, the same amount of MOVE PICTURE commands will not lag.


Woo! Okay, so what does all this give you? A seemingly complex yet fairly simple (x,y) coordinate system allowing you to know exactly where your cursor is. This allows a connection to be made between what the cursor is hovering over.


PART 2: Slots and Ladders

In the above example we have 22 possible slots available for items to occupy. That means a total of 22 different slot variables must be made. The easiest way to label them is to get use to the coordinate system. As the cursor moves along, variables Cursor X and Cursor Y are changing, corresponding to different SLOTs coordinates. Using conditional branches, you know what SLOT the cursor is at when the player pushes Enter.

Example:
A variable called "SLOT(1,7)" would be referring to the Enabler in the menu above.

But the item "Enabler" could be in anyone of these slots, so how do we keep track of its location in the menu? This is where slot variables shine.

First, you need to do some dirty work. Compile a list of all possible things that could be in each slot. Depending on what your menu is, this could be a number of things: characters, items, skills, whatever it is. You have 22 slots represented by coordinate systems that the player can easily navigate through. You have made 22 different variables for each slot. The amount of items possible is irrelevant. On a separate piece of paper or a notepad document, assign all possible items a different number. Now you have a system of Identification. By assigning each variable SLOT a number one through infinity, you are able to tell two very important things. 1)if the SLOT variable is equal to 0, that SLOT is empty, and 2) if it is not equal to zero, you have a number which corresponds to a specific item, character, etc., which then allows the event (provided you have set up the correct conditional branches) to display the correct picture in the correct place and to perform the correct function when the player selects a specific item.


PART 3: Prevent Copies and Other Graphical Glitches

Let's say a potion is identified by the number 1. The player has a potion in SLOT(1,1) and finds another potion in a dungeon. There are two things that could happen, the potion could be placed in SLOT(2,1), or the potion could add to a quantity of potions, which would require a separate variable to keep track of. What you don't want to happen is it to replace what's in SLOT(1,1), or any other SLOT. This is where 0 comes into play. Conditional branches can be used to check for empty slots. If there are no empty slots, a message like "oh, no! There's no room in muh bag!" would be displayed. If one of the slots is open, the item would be placed in that slot. You can also set a conditional to check for any SLOT IDs to be equal to the ID number of the potion the player has picked up, or any other item the player has picked up. By doing this, if there are any SLOTS matching the ID number, the new item can simply be added to the quantity. By checking SLOT availability starting at the beginning, the list kind of organizes itself.

In the next installment I'll go over item quantity, automatically/manually organizing lists, use of databases and scrolling menus for unlimited item list capacities (for those of you who don't want a Dragon Quest style item menu).

Future possible topics:
Parties bigger than 4
Temporary Variables and you
Auto scroll!
Displaying Pictures without Lag (I MIGHT do this one, there are a ton of tuts out there on this.)

I'll also take requests!

I hope this wasn't too confusing. Let me know if any part of it was unsatisfactory.

[Prpl_Mage]

Wow, this was a great read Dren. I remember when I made an inventory system some years back trying to limit the space. This could've made that process a lot easier.
Good job.

[A Forgotten Legend]

Well, this is a good reference.  Good job!