
UI's Slow Fuhrer. Waitwhat
      
Group: Members
Posts: 1,736
Member No.: 46
Joined: 17-February 06

|
This is an idea I discussed briefly in the IRC chat once, but hardly mentioned except for a brief OMG I HAD A GENIUS IDEA ABOUT PLATFORMING STUFF in the xfire chat.
Well, it's really several ideas. I will now go over them THOROUGHLY.
These ideas will only work in RM2k3. The second idea is also extremely applicable outside of platformers (it would allow for almost 100% C/Pable enemies in an ABS, you'd just need to change one reference to one variable ID on one page)
----------
FIRST IDEA: Giving events terrain types.
This idea combines the store event ID based off of coordinates command, the set range of variables command, and the ability to set a variable to the value of the variable with id X (value stored in index X) to make it so that you could easily have anything from temporary platforms to convenient balls of death.
First, make a decision. Do you want to dedicate variables from the beginning (0 through anything from 100 to 1000, depending on how safe you want to be), or do you want them to start later in your variables? I suggest later personally. It'll add an extra step to calculating the event terrains, but that's not a huge deal. Decide a starting point. You will start from one AFTER this point, but you can use this point to mark where the terrains start being stored. Every time you check the event ID at a coordinate as I instruct later on, add this value immediately afterwards.
Now, set up an event on your template for your platformer. Have it be a parallel or autostart, with no conditions. It should set the variables ranging from your starting point to your ending point to zero, and then erase.
Of course, that's not all. On every individual map you will assign the event IDs + your starting point to be their associated terrain type. For example, if you want event ID 0001 to have terrain type 2 associated with it, and your starting point is 1000, set variable 1001 to 2. Any variables left as zero will be ignored.
Now, if you have a common event that always runs while platforming that constantly updates the terrain type of the 8 surrounding tiles and the tile you're on, which you should (it's extremely convenient, take my word for it, and it makes this waaaaay easier), before it stores the terrain type of the tile in coordinates X and Y for each tile, have it store the event ID. If it's NOT zero, have it do the regular terrain type storing. Otherwise have it add the starting point and then store the event stored in that index in the terrain type for that tile.
There you have it. Now what's the use for all of this?
Well, temporary platforms. For one example, the spear ability that acted as a temporary platform in SoG could be done easily with this. It also allows you to make temporary platforms (as soon as they're supposed to be gone, make sure to set the value in their index back to zero) or temporary walls very easily. There are plenty of other uses too.
There is one major drawback though. When there are two events on the same tile (not counting the hero as an event), RPG Maker simply stores the event ID at those coordinates as zero. So you have to make absolutely sure that any events that actually server a purpose (ie don't have their value as zero) can't have events overlapping them.
----------
SECOND IDEA: Simulated action key trigger events in a platformer system or other system with a custom form of movement (when regular movement is disabled)
This idea is actually surprisingly simple to pull off, and makes many objects MUCH more C/Pable (no going through and incrementing every variable refference to match that event), AND saves a massive amount of computation. Okay, maybe not massive, but sizable.
First, decide on a key to trigger these action key events. It doesn't have to be enter. I'd suggest shift, in fact.
Now, set up a common event that checks your coordinates and then checks your facing to make it so that it has the coordinates of the tile in front of you in an X and Y variable. Now use the store event ID command on this tile. Next, have it use call event to run page one of this event.
Keep in mind that this requires all events to have page one dedicated to action key response. These pages can easily be blank, though.
This also means that an event running a parallel process could still have an action key trigger, if you want.
Now, this is extremely useful, in case you can't tell. For one thing, it makes it so that simulating the action key doesn't require every event to have two variables dedicated to it, one serving the purpose of X and one serving the purpose of Y, and you don't have to compare them to the tile in front of the hero on every event at once. Only one event will ever have any activity with this method.
This is also, as I mentioned, applicable in an ABS.
Instead of using it to fake action key triggering though, you would use it to run the damages from an attack. Assuming the attack only hits one enemy, you could even have it use a temporary variable to set the damage done by the attack, and then have it call another page to subtract that value from its HP value. Then you only need to change that reference for HP, and that's it.
Even if the attack hits multiple targets, you could still have it affect the enemies one at a time.
This does, however, suffer from the same flaw of event overlap killing it.
----------
I'm going to submit these to UI as tutorials, but I wanted to get some feedback first.
Constructive criticism is invited.
I want them to look good when I submit them.
--------------------
|