Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
(RM2K/3) VARIABLES
Posts
Pages:
1
blkgoblin
View playlists
CloseThroughout my years of experimenting with RPG Maker, I've avoided using variables. After seeing what other people did with their games using them, I decided to give it a try. I want to know how to use variables and different ways people used them in their games so I can try them out.
Variables can be used in so many ways it's not even funny. Keeping track of data like stats, gold, etc, creating common events that call on these, eventing entire battle systems...you need variables to do any of these things.
Right now that's what I've been doing. I keep enemy data in Actor tabs, so at any time I can grab the enemy's stat. Which actor ID the enemy is is checked and then it grabs the enemy's stats. Damage calculation is handled the same way, which grabs the actor's atk or def and then pluses or minues from there. I'm using fairly simple formulas in mine, but only because I want to keep track of them.
You could also use them to create a Day and Night system, and approval system...I've even got a "bloodthirst" counter in my game.
Right now that's what I've been doing. I keep enemy data in Actor tabs, so at any time I can grab the enemy's stat. Which actor ID the enemy is is checked and then it grabs the enemy's stats. Damage calculation is handled the same way, which grabs the actor's atk or def and then pluses or minues from there. I'm using fairly simple formulas in mine, but only because I want to keep track of them.
You could also use them to create a Day and Night system, and approval system...I've even got a "bloodthirst" counter in my game.
Variable can do same things that switch can, except it's little more complex and there can be more outcomes.
In nutshell, if you know how switches work, then variables shouldn't be that hard.
In nutshell, if you know how switches work, then variables shouldn't be that hard.
gadesx
307
You can understand variables with this:
Switch= 0 and 1 (off and on)
Variables = any value
Switch= 0 and 1 (off and on)
Variables = any value
Killer Wolf
1235
Variables are useful in almost anything you can think of to do in Rm2k3.
Since you're just starting out with them, I'll make a suggestion I wish someone would have made to me:
Use referred variables as much as possible!
When you make a new system or function, plan to use variables as a sort of temporary storage (variables not locked down to a set value) to stand in for things like hero position, id, or anything else you want to check.
That way your system won't get cluttered when you add new party members, target's, calls, whatever. You can just reference them outside of the system, change the variables accordingly and let it work.
In one of my projects, I need to scan the entire map every turn to check the distance from the hero (for a lighting system). In a 20x15 map, that means I need to check 300 positions. By using only "derived" variables, I was able to automate the process. The distance check event grabs the position of the first tile, makes the check, then moves onto the next value to pull in. It saved me a huge headache.
Any time you copy-paste a function to make a new version for an extra party member, you run the risk of missing a change and glitching your system. If you leave the functions internal variables alone and just adjust your temporary values outside of the event, there is a much lower risk of screwing it up.
You can use variables in conjunction with the modulus command to store extra data in a single place. Lets say you were making a custom inventory system.
You could have one variable for item type, and another for item count, or you could just use one variable for each inventory slot.
You have seven places to use, so you could even track for object weight. Lets say you can have 999 types of items, you can hold 99 of any of them, and they can weight from 0 to 99 pounds.
[123][45][67]
The first block would be the type of item. The second block would be the number held, and the third block would be the weight. You can then use the modulus command with bases of 10,100,1000 etc to strip out the data you need for your calculation at any time.
Once you start getting used to variables, you might find yourself running up against the built in variable ceiling of 5000. Using the Variable Reference function, you can make use of pointers to add another 9994999 variables.
Since you're just starting out with them, I'll make a suggestion I wish someone would have made to me:
Use referred variables as much as possible!
When you make a new system or function, plan to use variables as a sort of temporary storage (variables not locked down to a set value) to stand in for things like hero position, id, or anything else you want to check.
That way your system won't get cluttered when you add new party members, target's, calls, whatever. You can just reference them outside of the system, change the variables accordingly and let it work.
In one of my projects, I need to scan the entire map every turn to check the distance from the hero (for a lighting system). In a 20x15 map, that means I need to check 300 positions. By using only "derived" variables, I was able to automate the process. The distance check event grabs the position of the first tile, makes the check, then moves onto the next value to pull in. It saved me a huge headache.
Any time you copy-paste a function to make a new version for an extra party member, you run the risk of missing a change and glitching your system. If you leave the functions internal variables alone and just adjust your temporary values outside of the event, there is a much lower risk of screwing it up.
You can use variables in conjunction with the modulus command to store extra data in a single place. Lets say you were making a custom inventory system.
You could have one variable for item type, and another for item count, or you could just use one variable for each inventory slot.
You have seven places to use, so you could even track for object weight. Lets say you can have 999 types of items, you can hold 99 of any of them, and they can weight from 0 to 99 pounds.
[123][45][67]
The first block would be the type of item. The second block would be the number held, and the third block would be the weight. You can then use the modulus command with bases of 10,100,1000 etc to strip out the data you need for your calculation at any time.
Once you start getting used to variables, you might find yourself running up against the built in variable ceiling of 5000. Using the Variable Reference function, you can make use of pointers to add another 9994999 variables.
Variables are the kind of thing you can learn in less than a day; they're really not as complicated as some people think.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
You can learn them in less than ten minutes if you've taken pre-algebra, and in less than an hour if you haven't. Figuring out all the things you can do with them takes longer; it takes an infinite amount of time because you can do endless things with them.
Some obvious things to do with them:
- Set a variable equal to your main character's level. Now add a new level 1 character to the party. Increase the new member's level by the amount stored in the variable. Now your new member starts one level higher than the main character.
- Set a variable to 0, then add the levels of all four party members to it, then divide it by four. The variable is now equal to your average party level. Now add a new level 1 character to the party. Increase the new member's level by the amount stored in the variable. Now your new member starts one level higher than the party's average level.
Some obvious things to do with them:
- Set a variable equal to your main character's level. Now add a new level 1 character to the party. Increase the new member's level by the amount stored in the variable. Now your new member starts one level higher than the main character.
- Set a variable to 0, then add the levels of all four party members to it, then divide it by four. The variable is now equal to your average party level. Now add a new level 1 character to the party. Increase the new member's level by the amount stored in the variable. Now your new member starts one level higher than the party's average level.
Seena
125
author=Killer Wolf
Once you start getting used to variables, you might find yourself running up against the built in variable ceiling of 5000. Using the Variable Reference function, you can make use of pointers to add another 9994999 variables.
Very bad idea! Referencing variables beyond the amount defined would reference memory that isn't allocated to the game. This runs the risk of overwriting the memory in another process, leading to an error message at the very least (and possibly crashing the computer it's on). Another process might also overwrite that memory, causing the value there to change to something unexpected.
I know this because I am a programmer.
If you want more than 5000 variables in a safe way try RPG Maker 2009 Ultimate or use Resource Hacker to modify RPG2003.exe. The 5000 limit can be modified this way.
Everything else you said holds true though!
Killer Wolf
1235
author=Seena
Very bad idea! Referencing variables beyond the amount defined would reference memory that isn't allocated to the game.
Everything else you said holds true though!
I haven't experienced a problem with it yet. I've been using the 0010000 to 1999999 theoretical range in one of my projects and haven't seen any crashes so far. I'll keep on the lookout though.
Kazesui
5797
author=Seena
Very bad idea! Referencing variables beyond the amount defined would reference memory that isn't allocated to the game.
I know this because I am a programmer.
And as a programmer, you'd know that this would depend on how the variable array is actually implemented. While it's true that it would be a very bad idea to try referencing beyond the scope of a normal array, it's not as big a problem with a dynamic one, which one has reason to believe that the rm2k3 one is alone by the fact that you can adjust the amount of variables in the editor(and I don't get the impression that rm2k3 is actually compiling code).
Cherry has also stated that the rpg maker dynamically allocated memory for variables by references like this (yes, in runtime), and if anyone would know (aside from the developers), he'd probably be among them.
Seena
125
If memory is in fact allocated when a variable references another variable that is otherwise beyond the scope of the variable array, then there should be nothing to worry about.
Hopefully this is tthe case!
Hopefully this is tthe case!
Pages:
1
