Build Up To Boston: Demo Changes

Hi all!

I hope you had an awesome labor day holiday. I spent my Sunday at the US Open watching some awesome tennis and getting an awesome tan. I now take regular and needless coffee breaks at the office so I can show it off.

This week I’m posting every day, building up to the Boston Festival of Indie Games! Last year the FIG had over 7,000 attendees. It’s a staggering thought that even 1/10th of those people might check out Vidar, and I can’t thank the program coordinators and curators enough for accepting my game into the showcase. So without further ado, today I want to talk about what’s changed since NYC Games Forum?

You might recall that the first time ever someone could play Vidar was at the end of July, at the NYC Games Forum playtest night. We had about 20-25 people play it, and got some awesome feedback. All of it and more has been incorporated in just the 6 weeks since.

New Art

The most immediate change has been all new art. Becca Bair‘s sumptuous tiles and sprites now dominate the game. When it comes to maps, this means that the cave feels more, well, cave-like. Rounded edges instead of square ones, organic walls, and a desaturated tint all help immerse the player even more.

Out with the old, in the with desaturated.

And of course, Becca’s also prepared new sprites. The cast of characters the player can interact with have all been replaced (as has the player sprite itself). These taller sprites have more detail and, as a result, more character. You can get to know them a little better just by looking at ’em.

Vidar is, at its core, about the people. Which means the people better be damn good to look at.

New Content

Since I was going to add these new sprites, I wanted to make sure the characters mattered. In the NYC Games Forum Demo, players could talk to Vidar’s citizens but, short of seeing some dialogue, it didn’t change the demo itself. The player was always going to try to rescue Sandor’s son. Now there are two big options – Sandor’s son is still in the game, but there is a chance the player will instead see Room 2 of the Ice Cave. Room 2 is a series of 3 puzzles, and there are a handful of quests that can spawn there. Specifically:

• If Bernadett is alive, she’ll ask the player to return a ghost’s spirit to its grave
• If Borbalo is alive and the player has Bernadett’s quest, Borbalo will ask the player to bless the grave with holy water
• If Dani is alive and Borbalo is dead, Dani will ask the player to find Borbalo’s alcohol
• If Szabina is alive, she’ll ask the player to find a clue to the Beast’s origins in the cave
• If Lilja is alive and Szabina is dead, Lilja will ask the player to dig around in the cave for buried treasure
• If Sandor is alive, he’ll ask the player to go rescue his son

As you can see, some of the quests included are mutually exclusive; this means that the two NPCs chosen to die at the beginning have immediate consequences for the demo.

Most of the quests are handed out at the inn, where Vidar’s citizens have congregated for this demo. But the workshop is also open.

The game decides where to send the player based on whether they got Sandor and/or Bernadett’s quest. If the player received only one, they’ll go to the map which has that quest. If they got both, it’s randomly chosen. As a result, I’ve rigged the demo’s random deaths a little bit – Sandor and Bernadett can’t both die in any playthrough of the demo.

Sandor’s Son

At NYC Games Forum, I got a lot of feedback about mechanics, balance, and puzzle-solving. So all of the following changes have been made to Erik’s room:

• Players will only solve either the left side or the right side of the room, as opposed to both from NYC Games Forum. The “left side” involves rotating arrows with the Stranger to guide Erik to the exit. The “right side” involves opening and closing doors with the Stranger to guide Erik to the exit. If the player is sent to this map, which side they do is also chosen at random.
• Additional options have been added to both sides. What this means is three levels of chance – a player has a chance to go to Erik’s room, a chance to play the left side, and a chance to see any one of 5 puzzle options in the left side.
• Pressing “A” to switch between Erik and the Stranger is instantaneous, instead of fading the screen out and back in again.
• When ice breaks around Erik, it no longer pauses the game. Combined with the above, players will (hopefully) no longer be frustrated that time is passing by because of things outside their control.
• The graphics for the gates in this puzzle are now clearly gates, and not spikes which suggested to players that they should not run into them.
• The tutorial has a more fulsome explanation of sliding, pressing “A” to switch characters, and using switches.
• Compass arrows have been added (described below)
• There is a cutscene if the player fails to save Erik, rather than just simply fading out the demo and concluding.

Gates which are clearly gates!

After playing this new version of the Sandor’s Son quest, I’m in love with all of these changes. And that tells me that NYC Games Forum Playtest Night did its job; I really can’t thank the playtesters enough for their incredibly valuable and candid feedback. It’s already improved the game 10 fold.

Compass Arrows

A few people at NYC Games Forum indicated that they didn’t know what the goal was in any given puzzle. Specifically, where’s the exit? Where am I trying to go? So with this version of the demo, I’ve added compass arrows. These little indicators bounce up and down where you’re supposed to go next in the puzzle, and intelligently do so based on where you’ve been.

Four exits? No longer a problem, just head north towards that arrow.

The arrows disappears after you go over it once. Presumably, by then the player will know where the exit is. While compass arrows will be turned on in the demo, they’ll be a quest reward in Vidar. Every possible item which changes your gameplay experience – from sprint shoes to extra time to the clock itself – is a quest reward, and there’s no reason to treat the arrows any differently.

Additional Changes

A few other fun things have been added. The player can interact with certain items in town for flavor text. More branching paths are explained at the end of the demo. The menu has been cleaned up to remove items not available in the demo. More puzzles have been color coded. And of course, dozens of bugs have been cleaned up.

I’ll have 4 laptops running the demo at Boston FIG from 10 am till close. The event is this Saturday, September 13 at MIT. If you’re in the Northeast, it’s not to be missed!

Finally, don’t forget to sign up for email updates about Vidar on the website. If you sign up before Saturday, you’ll be entered to win a Vidar-embroidered beanie!

Transfer Lock

Double-post today! Reddit user tilfordkage wanted to block a player from advancing to a new area until the player reached a certain level. This is an easy solution!

Make Your Party Level Variable

In any event, create a event command of the type “Control Variable.” You’ll be greeted by this screen (it won’t be filled in).

Use this window to set variables as you need.

To get your window filled in like this, click on the … on the top line to name your variable (here, I did Player Level but it doesn’t matter). Select the Game Data radio button below, click …, and fill in the screen that pops up like this:

You can set the variable to a whole host of things about a player character, including their ATK, their current HP, or here, their level.

Now, every time we trigger our event, we’ll first set Variable 1 to Eric’s level.

 

Make The Rest Your Event

The rest is easy! Transfer events are almost always below characters/player touch so make sure your priority and trigger options in the bottom left are set accordingly. Then in the logic, after we set our variable, put in a conditional branch. If variable 1 >= 10, transfer. Otherwise, move the player away from the event and tell them to get a few more levels already!

Here we say to move the player down if he can’t transfer, but use your judgment to replace the player accordingly.

 

Multiparty

Worried that the player’s just power-leveled one actor and not the others? Average out the levels! Just do the math on the variable before the conditional branch.

Use control variable over and over to modify the event. Make sure to use the operators on the variable, don’t just reset it!

Good luck, tilfordkage!

Friday Script Or Not – Fomar’s Skill Master / Learn By Doing

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

Everyone loves to make their RPG stand out just a little bit, and one amazing way to do that is with a unique skill system. Today I want to talk about one option – a learn-by-doing system where you increase your skill ability based on the number of times you’ve used it! This is a Friday Script post, and we’ll delve into Fomar’s awesome and succinct Skill Mater script. But first, we’re going to do it all without scripts. In fact, you can make this system with events alone.

Skill System By Events

There are a few basic components we need to create in the database. The first is, for every skill that can be leveled, we need a variable corresponding to each actor that can use it. Based on your game design, this could be a lot of variables! You’ll need one final variable that the ID of the caster. Make a note of which one that is (here, 16)

Multiple actors could have access to the same skill – or not! Whatever you want!

The second is to build the skills, as many levels of them as we want. So, if we want “Spin Attack I”, “Spin Attack II”, and “Spin Attack III,” we make each skill with higher damage amounts, higher MP costs, etc.

Skills can do more than one thing. Just use the ; to separate lines of code.

Note that in my damage formula box, I have a normal damage formula, followed by:

; $game_variables[16] = a.id

Variable 16 is my Caster ID variable. What I’m asking the damage formula box to do is first deal damage, then set the variable to who is casting. We’ll use this in the next step. It’s important that every skill that you want to level has this little line after it’s damage formula. You can copy and paste it – it’s the same variable, same everything for every skill.

Third, we make a common event for each skill that’s going to be leveled. One for Spin Attack level, one for Fireball, etc. In each one, we’ll need to take yet another variable that represents which actor cast the spell, and based on that, increment the correct variable. We’ll also need to ask if that variable is above a certain threshold – if it is, our actor should learn the new, powerful level of the skill! (and take away the weaker one if you’d like).

You’ll need one for every chain level of skill, and nesting options for each actor that could use that skill.

Let’s walk through the logic of this common event. We have a series of conditional branches which ask “who is the casting actor?” If it’s 1, then increase the skill variable assigned to that actor by 1. If that brings us to 50 or above, ask if Eric’s already learned the next step. If he has, do nothing. If he hasn’t, teach it to him.

And finally, in each of our skills, we need to set the casting actor variable, and call our leveling common event.

Remember to make sure you’ve already set the caster ID!

It’s pretty easy logic, but is extremely tedious. We need potentially dozens of variables, numerous common events. To simplify, we can use Fomar’s script. Download and install it, and open it up. All of our work happens in that script.

Skill System By Script

From above, we still need to keep all of the different skills. So our skill table in the database will be quite long. But we don’t need the variables and we don’t need the common events.

Look for this area in Fomar’s script:

When you get here, delete the example SKILL[3] line. Otherwise you’ll end up with something wonky.

There, we’ll add all of our leveling skill scripts. We do it like this:

SKILLS[original] = [new, uses, replace]

We’ll replace the terms original, new, and uses with numbers. And we’ll replace ‘replace’ with true or false. Specifically:

• “Original” is the id of the skill being used. So for our Fire I, it’s 9
• “New” is the id of the next level skill. Fire II’s id is 10
• “Uses” is how many uses it takes to get from the original skill to the new skill. Choose what you’d like.
• “Replace” is either true or false – if it’s true, the new skill replaces the old; if false, the new skill is added to the list without altering the old.

We list each skill that has the possibility to “evolve” so-to-speak, and separate them with new lines. Something like this:

Using # in our code means anything we type after on that line has absolutely no impact. It’s called a “comment,” and I use it here to keep track of what each line is doing. Make sure to keep your games organized!

Beginner Challenge

Sometimes, it’s nice to have branching paths in our skill tree. We also occasionally let players keep a set of earlier skills because, while they do less damage, they cost less, and the strategy inherent in that decision is more interesting than just always blasting away with the highest level fireball. Using Fomar’s script, how can we make our Fire I spell teach you Fire II after 25 uses, but also teach you Fire All after 50 uses (encouraging you to use Fire I even after you get the upgrade)?

Advanced Challenge

There are two classes an actor can be – Witch and Spellsword. Both can cast Fire, and Fire upgrades to Fire II and Fire III. But the Spellsword takes twice as many uses as the Witch does. Using events, how can we achieve this?

We’ll discuss answers in a few weeks!

So Many Pieces – Challenge Solution

A few weeks ago I issued a challenge: populate your game with three different-colored chests, and to open then, require a player to have 50 fragments of the right color of key. We solved a single key problem all within the chest event, but here I asked you to do it with a common event that runs each time a chest is opened.

Why? Well, what if you find that 50 key fragments are just way too many to ask a player to get, and want to change it to 10 for your entire game. If you have any more than a dozen chests, you’re going to curse the day you decided to have all of that information contained in each chest event.

And we’re going to solve the problem with Ruby. Don’t be afraid! This one is easy. So let’s get to it! I’ve created three items in my database, one for each key fragment, and they are items 4, 5, and 6 (you can check for your item IDs in the game Database, it’s the number to the left of the item name). Red, blue, and green, respectively. I also need a variable, a switch, and a common event.

• I call my variable “Key to Check” – this is different than before, when we wanted to know how many of an item the player had in their inventory. Instead, we’re storing in this variable the item ID for the chest. 4 for red, 5 for blue, you get the idea.
• My switch is named “Chest Can Open” – if it’s on, the chest will open. If it’s off, the chest will remind us we need more key fragments.
• My common event is called “Open Chest Check” – it’s the event that will process all chests and decide whether to open them.

I’ll set up my chest with a conditional branch, just as we did before. It’s just that the things we do in advance are a little different. We’ll need to set our “Key to Check” variable based on the color of our chest, and then we’ll need to call our common event. Finally, the conditional branch is based on our switch. Like so!

To think only a few weeks ago we were pickle hunting in this forest.

Note that because it’s a red chest, the Key To Use is set to 4 – the item ID of my Red Key Fragment. Now we build our common event. Choose “script” from the trigger editor to open a scripting window, and add the following.

Just a few lines of code will process all of our chests in the game.

Ok, let’s go through that line by line:

• id = $game_variables[5] : here, we’re just setting whatever the value is in our “Key To Use” to an easy name, “id.” The script editor inside a common event doesn’t play nicely when you don’t name your variables.
• key = $data_items[id] : now that we have our id, it’s easy to actually match the id up to an item. We’ll call our item “key” (even though it’s really a fragment, we don’t win points for being literal).
• itemamt = $game_party.item_number(key) : a built-in RPG-Maker function, this allows you to find out how many of a given item the party has. In this case, we’re “giving” it key, which we defined in the line before.
• if itemamt >= 50 : this is just like a conditional branch in the trigger editor. We’re asking, if the player has 50 or more of whatever item we’ve chosen.
• $game_switches[1] = true : set our “Chest Can Open” switch to ON
• $game_party.lose_item(key, 50) : another awesome built-in, we tell RPG Maker which item to lose (here, it’s “key”) and how many to lose (here, “50”)
• else : just like the else in conditional branches in the trigger editor
• $game_switches[1] = false : set our “Chest Can Open” switch to OFF
• end : make sure to end your if/else statement

And that’s it! Doing it this way has two VERY nice features:

• If you want to change the amount of key fragments from 50 to 10, you only have to change it in two places. You can probably tell where they are in the script!
• If you want to add a yellow chest, no problem! No need to reprogram anything, just make a yellow key fragment and you’re off to the races – this common event doesn’t care what chest you’re opening.

Happy scripting!

 

 

Class Warfare

Reddit user kraegar wanted the player to choose 2 class for her party at the start of the game, but wanted to prevent her from duplicating the first class. The set-up was simple: in room 1, the player encountered 10 NPCs each representing a class, and the player would chose one for her first party member. In room 2, she encountered 9 NPCs – the classes, with the already-chosen one conspicuously absent. Kraegar set Variable 1 “Player 1 Class” to a number, 1-10, based on what you picked, and Variable 2 “Player 2 Class” the same. But how to make the NPC in room 2 disappear, as oppose to tell you “Sorry, you’ve already chosen my class?”

The answer is event pages!

First, let’s set up our first room, with all ten classes. When you talk to the NPC, we’ll give the player a choice to accept that class, and then if they do, assign the variable accordingly. Set up your event page like this:

We set variable 1 to “6” to represent healer. Just make sure you remember the numbers for each class!

 

We might even make every NPC tell you to advance to the next room once you’ve chosen a class. Let’s get comfortable with using different event pages. Once you’ve set up your NPCs, click “New Event Page” at the top, and for that page set it up something like this (I chose a different class this time – you’ll want each event to only deal with a single class).

The circle indicates what the page’s number is. Number is critical to determining order.

A few notes here. Sure, we could’ve put all of this in one event page, but in order to change the dialogue depending on your class we’d need nesting conditional branches. As you get more complex with your events, these conditional branches can run right out of the window, and can make it incredibly difficult to follow your event logic. Where possible, use event pages!

Second, it’s important that this event page be numerically higher than the previous one. That is, the page when you’ve already made a choice cannot be number 1, while the page prompting you for your choice is number 2. Why?

RPG Maker always displays the highest numbered event page where all of the conditions are true.

So long as Player 1 Class is 1 or above, this second page will be on display. If we flipped them, our prompt page would be on display no matter what – it has no conditions! Any page with a lower number would never be displayed.

Ok, we’ve chosen our class, and we’re well on our way. It’s surprisingly simple to set up the next room. The only difference is that we need a few event pages! The first will be the nearly the same as before – copy and past from your old room, just change the text and variable setting to reflect that this is your second choice.

If you only want to copy a page, and not the entire event, there’s a button for that.

Now, we want our Bard to show up in this room only if Variable 1 is not equal to 9. As you might’ve guessed, make a new event page. This time, set the condition to “if Variable 1 is 9 or above” and leave the entire thing – graphic and all – blank. Like so:

Make sure blank event pages like this one are set to “Below Characters” – otherwise, you’ll create an invisible wall.

But wait, what if Variable 1 is 10 – the pugilist? We solve it with, you guessed it, another event page. Copy and paste the first one, into slot three, and set the condition to Variable 1 is 10 or above.

Our Bard is rather full of himself, isn’t he.

And that’s it! Now when you enter this room, if Variable 1 is equal to 9, you won’t see the Bard. We can do the same for all of our classes, to have a seamless class picking setup.

A Little Ruby

Don’t be scared of learning how to script in RPG Maker a little at a time! While this approach works for some, you may have reasons for not wanting to store a class ID in a variable. Oftentimes in complicated games, you can end up with thousands of switches and variables, and so just grabbing the class ID of a character is preferable to accessing a variable. We can do this! To get the class of any given actor, you use:

$game_actors[actor_id].class_id

This will get you the class id of the actor identified. You can find both of the numbers in your game’s database. While event pages don’t have script conditions built in, this can still be a powerful tool to use.

Once it’s a script, we can start to dynamically change a lot of things. We can even change a party member’s class on the fly.

Marked for Death

A team of unlikely heroes has come together to fight evil. Conveniently, each hero fill a different role in the party’s needs. Nick the Ninja is great at taking down individual enemies, marking them with a curse and then dealing terrible damage.

Double-post today! The Hunter’s Mark ability has existed in some permutation for generations of games, in various different forms. It involves sacrificing a turn, or time, or MP, or something else to reduce an enemy’s defenses. Sometimes this works only for the marker, sometimes for all of the marker’s friends.

Reddit user PieHardLoL wanted his assassin to mark an enemy and deal more damage to that enemy. He wanted this to work for all of the assassin’s skills, but not for anyone else in the party. So let’s do it!

We’ll first need to create a state. I named mine “Marked.” Handle the removal timing as you see fit, and give a clever message for when an enemy is marked (“(target name) is Marked for Death!” Don’t include any features at all – this state is just a placeholder for us to check for. Make a note of the state ID – the number next to the state in your database.

Everything in your database – from actors to common events – has a numeric ID. These IDs are the keys to the kingdom in RPG Maker.

We’ll also need to know our ninja’s (we’ll call him Nick) Actor ID. You can get that from the Actor page.

Nick needs to know the skill Mark for Death, so he can apply the state, so go ahead and make that as well. Make sure Nick knows it!

Build things like animation, text, and costs to cast here.

The bulk of our work happens in the skills menu, specifically in the “Formula” bar. That bar determines the damage dealt by an attack, and uses two letters – a and b – to signify the attacker and target, respectively. So the default attack formula, “a.atk * 4 – b.def * 2”, means that the attack will deal attacker’s attack stat * 2, minus target’s defense stat * 2.

We can do so much more with this bar. We can include if/then statements, ternary operators, and much more. We’re going to be using a ternary operator for this, which looks a little something like:

x > y ? 1 : 2

This may just be a bunch of symbols, let’s break it down. Before the question mark we’re asking, well, a question. You can read x > y ? as “is x greater than y?” After the question mark are the results for yes and no. So, is x greater than y? If yes, the result is “1”; if no, the result is “2”. Simple!

So now we know, we can ask a question in the damage formula box, and we can produce two different results depending. Splendid! So let’s take a look at an attack I just made for Nick, “Ninja Attack.” No one else will be able to use it except Nick.  It attacks twice, but as with all of Nick’s attacks, we want it to do more damage if the target is marked. So the damage side of our equation might look something like

a.atk*8 – b.def*3 : a.atk*4 – b.def*2

That is, if our question is answered “yes”, do a lot more damage; if it’s answered “no”, do standard damage.

But what’s our question? Whether the enemy has the Mark state! My Mark state id is “25”, so I would write:

b.state?(25) ? (a.atk*8 – b.def*3) : (a.atk*4 – b.def*2)

b.state? asks if the target has a state (as you guessed, a.state? asks if the attacker has one). I put our attack values in parens for easier reading. So now we’ve got our Ninja Attack!

The formula box is small, but holds way more text than it lets on.

But wait! We want Nick’s regular Attack to do more damage to marked targets as well. But he shares the regular attack skill with everyone else. So we need to ask a better question – does target have the marked state, and is the attacker Nick? Remember when I said to note Nick’s actor ID? We need it here:

a.id == 4

That asks if the attacker’s actor id is 4. So now, our basic attack skill looks like this:

Use && between the two parts of our question to make sure that they’re evaluated together!

Voila, Nick’s Marked for Death now works for his attack and his special skill, Ninja Attack. Don’t forget, the ternary needs to be in every damage formula that Nick has access to for this to work.

Beginner Challenge

Marcy Mage has a slightly different mark she applies. Any damage the enemy takes by any of Marcy’s friends (or Marcy herself) will be measured against that enemy’s magic defense – even physical damage. How do we do that in the formula bar?

Advanced Challenge

Marcy Mage just leveled up her mark. Now, any damage the enemy takes is does fire damage, such that it considers the target’s fire resistance or weakness (great against those stupid ice imps). How do we do that in the formula bar?

Check back in a few weeks for the solutions!

Resisting Death

Reddit user Dynamex had the most standard of RPG quests in his game – kill 10 rats. He had troops with 2 rats, and would slay them with gusto, but whenever he fought them, the quest would only register one kill. He was script-phobic, and was looking for a fail-proof way to count that second rat. And one that did not involve changing his game design.

There’s a solution, but it’s tedious. Fortunately, it can be used for so much more than rats.

Dynamex’s problem was something inherent in RPG Maker VX Ace. The very second the last enemy in a troop dies, RPG Maker will start running its end-of-battle code. Anything that’s supposed to trigger when an enemy dies will be forgotten with respect to that enemy. So how do we solve this problem?

• If your enemies are events on the screen that trigger when you run into them, this can be handled in the battle processing event branch. But what if they aren’t?
• If you’re willing to use a script, Hime has a script for you. But what if you aren’t?
• If you change this to a “turn in 10 rat tails” quests, and have the rat drop a rat tail 100% of the time, your problem is solved. But who wants to clutter their inventory like that?

Well then, we’ll just need our monsters to cheat death long enough to run our events.

Avoid Death State

The first “state” in the database – regardless of what you call it – is the Death state. It will be applied to an enemy the second it reaches 0 HP. We need to prevent this from happening for a little bit, and the trick is another state that we’ll make ourselves. Make a state called “Avoid Death”, clear most of the fluff from it, but under Features add “State Resist: Death.”

No need to have a message appear – we don’t want the player to know what goes on behind the curtain.

Troops

Now let’s set up our troops. For our purposes, troops of 1 rat, 2 rats, and 3 rats should do it. If rats traveled in packs larger than 3, my guess is that whoever gave us the quest would be asking us to kill way more than 10.

Troops, like events, have pages. Here you can have events trigger during the battle. Let’s set up one which applies our new Avoid Death state to every enemy as soon as the battle starts.

Happily, there’s a copy event page and paste event page. Make sure this goes in any troop where it matters.

For condition, we’ve added Turn No. 0 to make sure it happens right at the start. “Span” really refers to frequency – can the event happen once per battle, once per turn, or repeatedly? We only want this happening once per battle, so we’ve set it to battle.

Now, if any rat’s health drops below 0 HP, nothing happens. Battle will continue, and we’ve got a serious undead rat problem on our hands. So let’s take care of that. Make a new event page, which triggers as soon as the enemy’s HP is down to 0. We’ll do three things:

1. Increment our rat killer counter
2. Remove Avoid Death
3. Add Death

Like so!

Can’t we just find a troop of 10 rats so I can get this over with?

Unlike the first event page, which applies to the entire troop, we’ll need a separate event for each rat in the troop. Change the event page accordingly – so when enemy 2’s HP is 0% or below, enemy 2’s states should change, etc.

Beginner Challenge

I noted this has more utility than you’d think. Create a battle against a Chocobird (I’m not about to get sued for trademark/copyright infringement). Set it up so that when a Chocobird dies, there’s a 10% chance that an over-powered Devourer shows up  to fight you.

Advanced Challenge

There are plenty of scripts out there to handle things like “magic points” or “action points.” But without scripts, use this system to assign a new type of point/experience at the end of battle, where the amount of points you receive is assigned in each troop.

Check back in two weeks for some solutions!

Pieces of Key

An easy one today!

Reddit user No_Fudge (that is the saddest username I’ve ever seen. How could someone be without fudge?!) wanted to make a collectible item that’s used to open chests in his game. So rather than simply walking up to a chest, and rather than having that One Key for that One Chest, he wanted the chests in his game to be locked unless a player used 50 key fragments to open them. Hope they have a high drop rate!

The quick solution is a conditional branch! In your chest event, wrap everything in a conditional branch that asks if you have 50 key fragments in your inventory. If you do, take away 50 key fragments and open the chest as usual. If you don’t, display a message that you need 50 fragments, but only have X. Something like this:

Wrap this conditional branch around the default chest event that RPG Maker generates, and you’re set!

Too easy? Well then try a little challenge on for size: create three different key fragments – red, blue and yellow – and have a chest only respond to a specific type of key fragment. Don’t solve this problem by changing the item reference in the line example provided; instead, have a single common event or script that runs a check for every chest. We’ll test out some solutions soon!

 

Bridges – Tutorial and Supplement

William The Unpro Pro has a video on how to make bridges, and it’s a great scriptless way to have a character go both under and over bridges, depending on levels! Check it out! As a supplement, Reddit user warboy3 had some difficulty implementing the events William described in his video. The trick he was missing – and one not specified in William’s video – is shift clicking. When RPG Maker VX Ace generates a roof tile – like the one warboy3 was using – it autotiles the roof accordingly. What this means is, if your roof tile has a ground tile to its north, then the roof’s northern edge will be a border. Putting aside bridges and events and all of that jazz, this is what happens when you make a roof:

See those dark green borders circled in red? Those are autogenerated by RPG Maker at the edge of the roof so that you don’t walk onto the roof from its side.

As awesome as the bridges are, they won’t change that fact. Which is why our hapless player was able to walk across the bridge, but only if the bridge extended past the auto-generated border. That looks dumb, as he rightfully complained, so instead, lets get rid of the border entirely! Shift rightclick on any roof tile that is surrounded by roof tiles, say…that one:

The circled tile is surrounded by roof on all sides, so RPG Maker hasn’t generated a border.

Then shift leftclick on the entrance/exit to your bridge. It’ll look like this, notice a slight change?:

Take a look at the left roof, where we might have a bridge connect.

Shift-clicking copies exactly the source tile, auto-generated borders and all. Our bridge is going to connect to the roof on the right, but see the tile where we’ll step out? We’ll probably want to keep the top border, and just eliminate the left border. Thoughts as to how to do that?

Once you’ve got the map set up, follow William the Unpro Pro’s tutorial, and you’ve got yourself a bridge, son!

We’re going all over – and under – this bridge. It’s gonna be awesome.

Incidentally, Neon Black has an awesome script to handle bridges, and it uses region tags, if you’re into that sort of thing.