[Eventing]Switch & Variable Efficiency, Moving from Amateur to Pro with Switches & Variables. Options

[Vanit]

Ahh, thanks for clearing that up for me Kread.

Sorry for the confusion, BigEd, although the stuff I said holds true for rm2k3, clearly its a very different story in the more recent makers.

[Kazesui]

Your general idea is correct, apart from the last switch being decided by the sign, since 2^23 is the highest you can go without blowing the absolute number limit.

This is wrong and I have seen a bit more misinformation here, so I thought I would chime in. In Ruby complexity like this is hidden from you, and even in a statically typed language on most platforms an int will be 32 bits, i.e., 2^31 possible combinations, losing one power of two to store the sign bit. If the type is unsigned than you can use the full 32-bit range. I don't know where you got 2^23 from, but that is incorrect.

Probably been explained through the previous posts but I thought I'd just chime in and say that you're just as wrong. The rpg maker series consist of more than just xp and vx, so your 32bit ints doesn't apply to rm2k(3), at least not through normal usage. in rm2k(3) you are limited to the 7 digits a variable can have, where 2^23 = 8,388,608 is the highest value below 9,999,999 a power to 2 can have, leading to a total of 24 bits if you include the sign bit.

This is not any more wrong or misinformation than saying you have 32bit ints at your disposal when applied to the rpg maker series as a whole.

[dragonheartman]

Probably been explained through the previous posts but I thought I'd just chime in and say that you're just as wrong. The rpg maker series consist of more than just xp and vx, so your 32bit ints doesn't apply to rm2k(3), at least not through normal usage. in rm2k(3) you are limited to the 7 digits a variable can have, where 2^23 = 8,388,608 is the highest value below 9,999,999 a power to 2 can have, leading to a total of 24 bits if you include the sign bit.

This is not any more wrong or misinformation than saying you have 32bit ints at your disposal when applied to the rpg maker series as a whole.

This. As much as people want to pretend they don't exist, there are people that still use 2k/3.

This is a great step up into more efficient gamemaking with rm* and I just wanted to chime in and share my examples of composite variables, as Vanit coined. This is for RPG Maker 2003.

Delay
For SU's FFX-style turn queue (shown here), every character has a delay associated with an attack (at it's simplest state, delay is an inverse of agility). For each character I get the next five delay values and then sort that big list to get an accurate turn order. How do I associate a delay value back to the character? I included an identifier variable in the first two digits of the varable, so the variables look something like this: XXXXXYY, where XXXXX is a delay value, and YY is that delay value's associated ID. Since the ID is stored in the least significant digits, it actually doesn't affect sorting and makes displaying the turn queue a breeze (just mod 100 and you return the ID).

Multi/Unique Target Abilities
I also used composite variables for multi-target selecting abilities for the CBS. The problem I had was determining an efficient way to show where attacks of varying range would target on a 3x3 grid and allowing users to control that target as freely as possible without graphics overflowing off the edge of the grid. The two problems I thought about were: 1 how do I determine when an ability range is out of bounds? and 2. how do I keep the general target shape intact? it turns out if I represented this 3x3 grid as a series of variables with a 2-tile "buffer" around the grid, all that information is safely stored and displaying the grid/determining enemy locations is relatively fast.

Essentially I zero out this matrix and any valid grid space for the attack I set as a 1 and any space required to be in the grid I set as two. Examples might help

CODE

0.) 0000000
1.) 0000000
2.) 0022200
3.) 0022200
4.) 0022200
5.) 0000000
6.) 0000000

Encoded here is an ability that targets the whole 3x3 grid, but cannot be moved at all.

CODE

0.) 0000000
1.) 0000000
2.) 0001000
3.) 0012100
4.) 0001000
5.) 0000000
6.) 0000000

Encoded here is an ability that targets a tile and it's immediately adjacent tiles as well. This can be moved anywhere within the 3x3 grid because the adjacent tiles are encoded as 1's. If this ability is moved to target an enemy in the corner, it effectively only targets three tiles (as it should) and if the target is in the center it will display all five target spaces. Any possible permutation of targets on the grid for an attack is easy enough to encode and it's all interpreted the same way.

When you decide to move the target around the grid, you just do some basic operations. To move left, multiply every variable in the list by 10. To move right, you divide by 10. To move up/down you just assign a row to it's next/previous neighbor depending on the direction. It's fairly efficient and I'm happy with it.

[lilcooldude69]

LOL late posting for me on a reply of the 2 cents i put in, you can only go into debug mode from the game maker engine, if your playing the game from the project folder it wont let u.