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!

Boss Battles – The Elemental Shifter

A great resource for those interested in old-school RPG Maker design is a blog called “Final Boss Blues.” Whenever I think about that name, I immediately start thinking about, well, bosses. Endemic to RPG Maker VX Ace are a host of terrible boss fights. Boss fights typically just become longer versions of the random encounter variety, with different music and more powerful enemy attacks. But what makes a good boss fight isn’t more of the same – it’s really a test of skill. Oftentimes, that skill is one that the player can ignore in random encounters, but now becomes essential.

Today I want to talk about one particular fun boss mechanic – an element shifting boss. They’ve been around since elements were in RPGs, and they’re quite easy to do in RPG Maker! Let’s get to it – I’m going to make a boss that flits back and forth between a “fire” aspect and a “thunder” aspect. You can adopt this to as many elements as you want.

A Tale of Two States

A element shifting boss is governed by states, just like Poison or Ice Force. These states allow us to control a lot about the boss. I’ve created two states, “Aspect of Fire” and “Aspect of Lightning.” For each, I’ve given it a little text (so the player knows what element the boss is in when it changes), and I’ve used the Features box to reduce the damage done by that element to 0%, and increase the damage done by the opposing element.

You can guess that the other one just changes the text and elements involved. The notes are just that, notes – they don’t do anything.

Now, we need to give our boss the ability to self-apply these states. Create two skills, each one adding a state and removing the other, like so.

Make sure your skills are certain hits. It would be extremely embarrassing for a lightning god to fumble on applying his elemental state.

You can also create any other skills you want your boss to have the ability to use, assuming the defaults don’t fit your boss.

Setting Us Up The Boss

When establishing what skills an enemy can use, you’ve probably twiddled with the “Rating” a lot. It’s what determines how often the enemy uses the attack, so that it’s not casting Ultima every single turn. But there are also a lot of conditions you can set, including…state! State asks whether the attacking enemy has a particular state. This means that we can say “boss can cast Thunder, but only if it has Aspect of Lightning applied.” So let’s do that.

Fill in as many as you want; variety is the spice of life.

We need to add two more skills – the ones we created before which allow us to flip. Remember to set the condition so that the skill which applies fire state requires thunder state; and vice-versa.

Start Him Off

Finally, if the boss were run like this, we’d end up with a boss that just keeps attacking and does nothing else. Why? Because all of his attacks are state dependent, and he doesn’t have a state. So at the start of battle, pick a state and add it.

When you set the Span to “Battle” it means this is just going to happen once this battle. Which is exactly what we want.

And there you have it! Our elemental boss will shift between Fire and Lightning with ease, and do appropriate attacks.

Improving the Boss

If we allow ourselves to use a tiny bit of script, we can really improve this boss in the following ways:

• Change his graphic so that the player knows which element he’s in just by looking at him
• Have him absorb elemental damage rather than negate it

We’ll explore that and some other options next week!

Iteration 2

Dev blog? But it’s Friday! What’s going on? I’ll level with you – Friday script posts take me about 5 times longer to make than the other posts. And that doesn’t even include the time spent looking for amazing RPDR gifs. I have to the learn the script, come up with challenging new uses for it, poke at the edges, implement it. I’ve cut corners by featuring scripts I’m using in Vidar, but running out of those.

Never fear, the Friday script feature will be back, but it will be less frequent than…well every week.

So today, even though it’s Friday, I wanted to write about recent iterations to the Ice Cave! After playthrough, it was clear that getting the waypoint was absolutely critical. Without it, it could take 5 of the player’s 10 minutes just to reach the next puzzle. And the waypoint was tied to an incredibly challenging quest from Bernadett, which involved going back and forth across the Ice Cave several times.

But if Bernadett died in the first few days, the player was penalized so heavily that the rest of the game became impossible. While the point of varied quests was to change the way you play the game, I never want you to feel like “oh, so-and-so died, I have to restart.” And our favorite judgmental nun was absolutely in that position. Based on this, I’ve decided to add multiple ways to “teleport” throughout the caves. A minimum of three, so that the player has some way of rapidly advancing to the puzzle they need to tackle next.

1) Waypoints are staying in. Each area has a waypoint that can be unlocked by completing a certain quest, and that waypoint gives the player direct-from-town access to a room in the middle of each biome (chosen randomly, of course).

2) The Ice Cave waypoint is now the reward for completing Borbalo’s quest. His quest is slightly easier than Bernadett’s – asking you only to visit each of the graves, rather than returning ghosts to them. Borbalo’s former quest reward – the journal – is now given to you at the start of every game.

3) Campfires. A new addition to the Ice Cave are randomly placed Campfires. Doing a quick, easy, and early quest for Dani allows you access to Campfires.

The location and number of campfires is random, but there are at least three in the Ice Cave.

Dani’s quest is designed such that about 95% of games will complete it. In exchange, Campfires give the player a trade-off. A player can use a Campfire to immediately end the day and start the next day still in the cave. This means that the player can keep solving puzzles without being forced to awake back in Vidar. But the Beast waits for no man – someone will still die. And if you needed that person to complete a quest, you’re SOL.

4) Ghost running. Bernadett’s quest reward has been upgraded to allow for quick transfers between the graves in the Ice Cave. This is by far the most flexible of the three ways to move about the Ice Cave, and is a strong reward for a difficult quest.

The other biomes are getting a similar facelift. The upshot of this is, more quests. Way more quests. When Vidar started, there were 24 quests planned, full stop. Now we’re at 34, and I expect we’ll be up to 50 by the time the beta is ready. I’m thrilled that the solution to this problem was more game diversity, because that’s what Vidar is all about.

Dev Blog – Switches 1

I thought it worthwhile to do a series on how Switches are handled in Vidar. In this series, when I use the capitalized-S Switches, I’m not talking about those numbered global booleans that you can access in the trigger editors. I’m talking about things you interact with that you expect to do something, like these:

To make matters more confusing, these are called “Switches” in the RTP Character Sheets.

I’ll use the lowercase-s switch to refer to the boolean that you set. Any basic dungeon will end up having a Switch like the one above that opens a door. And it’s easy to have an event page for your Switch look like this:

This is typically accompanied by a page 2, which has as its condition, “Open Door 1”

And then your door would have 2 pages; one where the door is closed, one where it’s open and the conditional is that “Open Door 1” switch. And then you’ll use another switch in another Switch for “Open Door 2,” and another for “Open Door 3…”

This is a bad habit. Stop doing it.

What you’re doing is creating global booleans that only get used once. Not only are you cluttering your list of switches, there’s a strong chance you could accidentally call it with something else, a chance that something gets moved or deleted. Once you have more than 10 doors, you’ve got a headache. These switches are really good for massive plot-moving periods in your game, because they’re an easily referenced marker – use switches for things like “Cave Boss Defeated” or “Fire Summon Available.” Don’t use them for Switches and Doors.

Vidar in particular can’t use switches like this. Why?

1. There are hundreds of possible doors in Vidar, making tracking them tedious
2. Which doors are actually spawned at the beginning of the game are chosen randomly, making tracking them really tedious

Plus, it’s bad practice. There’s a much better way. For the second page of your door, instead of using a global switch, use a self-switch. Something like this:

Now your door isn’t dependent on some switch in your list that you might accidentally click; it’s dependent on its own self-switch.

As it turns out, your Switch can tell the door to turn on its own self-switch. Just use this:

$game_self_switches[[mapid, eventid, "A"]] = true

So instead of using one of those global switches, our Switch page would just look like this:

Since we’re not using a global switch, we need to trigger 2 self-switches; the door and the Switch itself.

Why is this so desirable? Because it’s flexible. We can replace all of those variables dynamically. We can run this thing through a for loop. We can have dynamic control over every door.

So, for example, if we have a room with a puzzle that has 100 doors, we could do something like:

100.times {|i| $game_self_switches[[5,i,"A"]]= $game_self_switches[[5,i,"A"]]? false : true}

which would “toggle” all 100 doors – open all closed ones, close all open ones. With one line of code, and not 100  event calls, nested in if-then statements. And without 100 different switches in our global switch list, which we have to navigate for months to come. Even if you’re not going to do something in-depth, you can easily clean up your game using this method instead of one-off global booleans.

This is the starting point for Switches in Vidar. There’s obviously a lot more – Switches do different things depending on the puzzle they’re in, and having them know what function to call is its own can of worms, but we’ll save that for another day.

Dev Blog – Dialogue Trees

Double-post day!

One of the core features of Vidar is that the interpersonal relationships between characters, their story arcs, their development as people, changes from game to game. The main mechanic of this is the Indiscriminate NPC Killer. When a character dies, those close to him or her need to respond accordingly. And indeed, the loss of a sister may be greater than the loss of a friend, which would still be greater than the loss of an acquaintance or even an enemy.

I’ll use Bernadett, the town nun, as an example (and not just because she’s the only NPC fully implemented!) Bernadett is judgmental – she believes that the Beast killing Vidar’s citizens is a harbinger of the Gods sent to punish the people for their sins. And she is vocal about it. She’s got opinions about lots of people in town, but specifically:

• She thinks Robert and Cecilia, the town’s Romeo and Juliet, are despicable, putting the pleasures of the flesh above respect for the Gods.
• She thinks Rosza, the innkeeper, may be well-intentioned, but in trying to take care of everyone is in fact embracing sinners when they should be cast out
• She does have pity for Tomi, the child, but believes it’s only just for children to suffer punishment for the parents’ sin
• She respects Borbalo the priest, and while noting he is full of sin himself, admires his practical approach to religion
• She has a tenuous relationship with Mihaly, the musician, which can end with her believing that he is a good person, a wicked person, or a dangerous person, depending on how, whether, and in what order certain quests are completed.

In order to mirror the fact that some deaths are more important than others, Bernadett had an order of priority for each of these characters. She’s almost always in the Church, so it makes sense that she’d comment on Borbalo’s death over Tomi’s. Her relationship with Mihaly is complicated, so it’s likely to take priority over Rosza. The old system then looked something like this:

if Borbalo is dead, “I’m sad Borbalo is dead”

else if Mihaly is dead, “I’m conflict about Borbalo being dead”

else if Robert is dead, “I’m glad Robert is dead”

…you get the idea. Also, the dialogue is not that awful, I promise. Like Bernadett is a judgmental character, but she’s not incapable of stringing a few sentences together.

Unfortunately, this led to a relatively static conversation with Bernadett if Borbalo died on day 1. By virtue of him taking the highest priority, Bernadett would not comment on later, less important deaths. You would always stop at “I’m sad Borbalo is dead.”

I’ve now built a system to account for this a little bit. Each death also gets a “days old” date, which can be set based on the relative importance of that character as well. Bernadett will now only comment on a death for so long before it gets boring. While higher priority deaths can still leapfrog to the front of the line, there’s a chance now you’ll hear about multiple deaths from the nun in the course of a single game. So we replace the above with, for example:

if Borbalo has been dead for less than 10 days, “I’m sad Borbalo is dead”

else if Mihaly has been dead for less than 8 days, “I’m conflict about Borbalo being dead”

else if Robert has been dead for less than 6 days, “I’m glad Robert is dead”

This allows for greater flexibility while keeping Bernadett’s priorities straight. Right now, this is Bernadett’s dialogue tree:

This isn’t just about who is dead; it includes all of the possible options concerning her quests as well.

What’s absent from this system, and one of the next things to implement, is more variety for multiple deaths. If Bernadett is still vengeful over the deaths of Robert and Cecilia, Rosza’s death shortly thereafter would only fuel the fires of her religious fervor. Indeed Robert and Cecilia are the only two people handled in a single-or-multiple setting on the chart.

What’s also absent from this system is recognition of unrelated quest events. For example, it’s possible in the game for Cecilia to move in with Robert, or for Robert to move in with Cecilia. If that happens, Bernadett would surely be even more upset about these two teenagers living in sin, and her dialogue should reflect that as well.

Making Maps – Outdoors Foundation

When you first start with RPG Maker, you might be overwhelmed by the sheer number of resources online. Dozens of creators, hundreds of tilesets, thousands of options – but none of them are going to make your map for you. In this post, I want to talk about making a gorgeous map using nothing but the assets RPG Maker ships with. Learning these techniques are important; once you get the fundamentals, you’ll know which tilesets you need, why, and in what combination.

This is a multipart-post. We’ll start talking about outdoor maps here; there’s plenty more to come, and of course we’ll need to make an indoor map as well!

1) Choose the basics.

     Some people turn to RPG Maker to build their 80-hour epic. Others are excited to create a world they’ve built in their minds over several years. Still others want to make a game to play rather than tell a story. While you don’t need a 300-page game design document, everyone needs to answer a few questions before they make a new map.

• What’s the environment we’re exploring? Jungle? Desert? Tundra? Volcano? Any adjectives that truly define your environment, like Shadow Jungle or Domain of the Ice Goddess?

• How big is this map? Generally you want to alternate between large and small maps – too many large maps can make a player feel overwhelmed, too many small maps and the game feels disconnected from itself.

• What do I expect the player to do in this map? Are they just getting from point A to point B? Are they solving a puzzle? Fighting a boss? Experiencing a cut scene?

     Are there more questions you can ask? Sure! Some designers might encourage you to think about what happened here 100 years ago, what kind of vegetation would grow in this climate, come up with the unique characteristics that define the map. That’s all well and good if you’re trying to impart meaningful story, but what if you just wanna blow stuff up?

     I’m a fan of starting right away and fixing problems later, otherwise you can spend decades planning your game. Answer the above three questions, and you’re good to go.

For the outside of Vidar, we settled right away on a snowy hamlet, where all of the domiciles fit on a single screen. I wanted the player to easily enter each house, and I wanted a single area where a player might experience cutscenes at the start of each day.

2) Choose the floor.

     With that information in mind, it’s time to pick out some good basic tiles. We’ll first need 2-4 floor tiles. Find tiles that look great when spread out over massive areas, and look for variations on the same theme (or try your hand at making your own!). Using a grass floor? Get a floor with darker grass than your base, and another floor tile that looks patchier. Make sure that, when interspersed with each other, they look delicious. Looking at something more in the desert family? Find your basic tile, then one where the sand is mounded up on itself. Slight variations in the autotile can make a world of difference.

I chose the following tiles for our snowy hamlet:

Some snowy ground, snowy paths, snowy water, and snowy buildings. I think I’m set.

3) Get to mapping.

      Don’t kill yourself looking for everything right away; start drawing out your layout right away. Use placeholder tiles to indicate to yourself that an item should go in a specific place. Identify your methods of ingress/egress. Some notes on layout:

• Avoid large open spaces. Remember that the player’s screen will always be 17×13 tiles wide; if there is any place the player can stand where they won’t see something interesting or engaging, that place is in an open area that is too large. Smush it. 

• Be consistent with wall height. This occasionally requires some tweaking back and forth, but be sure to keep track of wall height and stairs. Here are some examples:

• Function over form. While your forest might look like the streets of Boston, remember that NYC is infinitely easier for a newcomer to navigate. Unless you’re intentionally designing a maze, avoid too many forking paths or branches, and too many turns.

Here’s the quick layout for Vidar. I had a sense of how many houses I wanted, marked those areas off, and marked off the exit.

 

Castle to the left, tent in the center, church up top. We have the start of our town.

4) Level with your level.  

One of the most dynamic things you can do to change up your map is add terrain levels. Not only do cliffsides take up space (and fill in otherwise empty zones), going up and down cliffsides creates a sense that the player is doing something more, even though they aren’t! Look for areas where a cliffside may be appropriate, and fill in your walls.

So let’s add some easy levels:

Cliff levels are easy filler that make your map infinitely more dynamic. If the map feels flat, it’s because, well, it is flat. Add a cliff.

5) Get a border.

     Unless you want your player to be able to leave at any edge of the map (always an option, though from a player’s perspective not the most intuitive), you’ll need a border for your map. You want it to look natural – if you’re designing a walled city then by all means, a brick wall will do just fine. But if you’re playing in the desert, you’ll need to get creative. Here are some tips:

• Water and terrain changes make excellent impediments. Can you have a body of water in your map? If so, you may be able to cut off a player’s path (lava lakes count!). Can you have a cliff, or are you on a cliff? Using terrain height adjustments is a fast method to create borders.

• Look at your layout to see if you can “extend” anything to create a blockage. If a fallen tree is critical to your map, can you place it to block off a player’s exit? If there’s a house, why not have it take up the entire “back wall” of a small map?

• Use a filler border, like a tree line, to finish the job, Ideally you don’t want your entire map covered in trees, but it can be an excellent tactic to cover large areas of terrain.

• At this stage it’s ok to leave a few holes. You might be able to fill them up with rocks etc.

Let’s take a look at how we might add some borders:

Here we used trees, stumps, and graves to block certain exits. As we build our map, we want to continue to layer these so that it doesn’t feel like we’ve blocked the borders with a single stone.

6) Sleep on it.

     You’re well on your way to your map, and it’s important at this juncture to take a step back and think, maybe even overnight. Remember way back at the start when you asked what the player would do here – looking at your map, is your answer the same? Has your design inspired you to some better or different gameplay? Will you need to add an area? Has something become redundant? Take a moment to ponder and consider what you’ve got so far before moving on to Part II (coming soon!)

Friday Script – Yanfly’s Gab Bar

This gab uses Liberty’s amazing ghost sprite edits – check out the end of the post for a link!

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.

Yanfly is one of the Great Scripters for RPG Maker VX Ace, from overhauling combat, to customizeable skill sets. Truly using Yanfly’s scripts one could finally implement their dream jobs/abilities/materia?/weapon/talent tree system. But today I want to talk about something far more frivolous, and yet just as important. Yanfly’s Gab Bar!

The Gab Bar allows you to post ambient dialogue that’s not important enough to warrant a full box, or any response from the player. It helps you set the scene and convey story in an easily digestible way. Got a wall of text that the player needs to understand your game? Consider instead the Gab Bar, in your tutorial or intro level; have some soldiers give some background, and your player will thank you.

Download the script from Yanfly’s blog – and while you’re there, browse his other scripts! They’re all quite useful! Add it to your game, and away we go!

Gabbing

Calling the gab window requires a script call. It’s pretty easy:

gab(string)

Where you replace string with what you’d like to say. A very straight forward example is:

Make sure your dialogue is in quotes!

When we talk to our soldier, rather than opening a dialogue box, our soldier’s text will show up on the top of our screen, in a little gab window. The window won’t impede our player’s progress; she can walk around and play the game without having to “respond” to the dialogue. This can often prevent players from just rapid-fire clicking through conversation. It also separates “chatter” from important dialogue, encouraging players to pay attention when there *is* a dialogue box.

We can go one step further with a slightly different script call:

gab(string, spritesheet, index)

Here, in addition to the gab, you’ll get a little actor sprite indicating who actually said it. For example,

If you’re looking for the name of the sheet, it’s on the left side of the window when you pick the graphic for your NPC.

Spritesheet refers to the file name with the character’s graphic – here, “People4”. Index tells you which character on the sheet he is.

As you might imagine, the gab bar is hardly limited to talking to an NPC. You can use this script call in a parallel process in, say, a crowded bar. Every so often, a patron might pipe up with a comment about recent political events, a cave north of here with legendary treasure, or a rumor about a monster’s weakness. This doesn’t even require the player to interact with something or someone, instead just adding chatter to give the player guidance and create a more lively world.

It can also be used to build inter-party dynamics, and that’s what our challenges are based on:

Beginner Challenge

Set up a common event parallel process that, every five minutes, chooses a random party member and has them say a catch phrase unique to that party member.

Intermediate Challenge

As above, but add a variety of catch phrases for each member, and have one chosen at random.

Advanced Challenge

As above, but instead of a catch phrase, create a dialogue between two present party members.

We’ll go over the answers in a few weeks! And you can grab Liberty’s ghost edits – along with a good deal more gorgeous artwork – over on the RPG Maker forums.

Iteration Homework

In Level Up!: The Guide to Great Video Game Design, Rogers proposes a theory of “fun.” According to Rogers, fun is what you have when you take all of the unfun elements out of your game. Maybe is sounds intuitive, but for 99% of RPG Makers, it’s a mantra worth repeating.

Consider where Vidar was 3 months ago. The Ice Cavern mazes were massive, map-wide puzzles that required the correct sequence of slides and dashes, finding switches to open doors, and backtracking frequently. As a puzzle designer, I felt masterful. This stuff was complicated, often reused puzzle elements for new challenges, and was quite difficult but solvable.

The problem was, it wasn’t fun.

No seriously, where the f am I going?

The player might make a wrong turn, or get hopelessly lost. The player never had an actual indication of where they were supposed to be headed on the map. Retracing your steps because you opened a door all the way near the entrance was cumbersome.

A good puzzle doesn’t make the designer feel smart, it makes the player feel smart. And so I scrapped the intricate Ice Cavern entirely and started making puzzles that could fit on a single screen. I filled the caverns with shortcuts back to the entrance. I made sure each puzzle had a clearly identified exit. And with these smaller concepts, was able to create something far more enjoyable.

Part of my goal in sharing Vidar with the RPG Maker community is to get makers to practice good game design, and for that, I’ve got some homework for you. Some iterative homework. This week, in addition to making your usual progress on your game:

1. Play though 30 minutes of your game not in debug mode. You choose where to start. Did you ever feel frustrated you couldn’t clip through something? Did you ever feel like there were moments you were waiting too long? Did you spend the entire time playing random battles? Note these moments.
2. At any point where you weren’t having fun, the player won’t be either – you’ve got a lot more invested in this game than they do! Make a list of all those moments, and brainstorm some solutions. It may mean adjusting the encounter rate down by half. It may mean cutting a planned feature entirely. No one says you have to implement the solution, but write down what it would be, and keep those notes safe.

 

Balancing Act

Wall of text post today! Undoubtedly when you first start making your game, the heavy lifting of balancing your game to be a surmountable but enjoyable challenge is far from your mind. As it should be – get your game done first, then start making tweaks. But in order to avoid dramatic changes or problems with your game, it’s worth sketching out a few ideas at the start. Today, I want to talk about balance, and specifically, balance concerns that should you should tackle early.

These topics assume you’ve got a lot of basic RPG Tropes in place. I encourage you not to – I encourage you to challenge convention, and, where appropriate, ignore this list entirely because it doesn’t fit in your game.

Design

Development of your characters is intrinsically tied to game design and philosophy. If a character levels 5 times in a 40 hour game, without getting new skills, without a change in how the game is play, you’ll end up with a very flat game – which can be ok! If a character levels 40 times in a 5 hour game, remember that the character will steamroll anyone back in the first forest should he ever revisit it. So let’s ask the following:

• How often do you want to level, and how many levels do you anticipate the party achieving (more or less) per broad section? Once you have that, break it down into specifics – I expect roughly two levels in this dungeon, one in this cave, none in this forest path, etc.
• Assuming you’ve got a party, figure out their roles now. Do you have a slow tank, a HP-weak mage, a fast physical rogue, etc? Determine what stats each member has emphasized and weakened (assuming they do at all – maybe everyone is a blank canvas).

With these two questions, you should now be able to generally set some numbers for your party. Pull them out of thin air, and make a chart that looks something like this:

Please don’t sue me, Square, they are common names!

 

Now, we’ve got some raw numbers. We can put those into RPG Maker’s leveling system and be comfortable with that.

But people don’t wander this world naked, no! They carry with them stat sticks – sometimes a dozen stat sticks! – that change all these numbers accordingly.  So at the start of your game, let’s also think about:

• What kind of equipment is there? What does it do (generally speaking, each piece of equipment could obviously have idiosyncrasies)? Who can wear/use it?
• How often do we expect an equipment change?
• To what degree is the latest and best equipment “required”?

Balancing Around a Fixed Point

We do all of the above now because balance involves several moving targets – experience, gold, encounter rates, player stats, monster stats, drops, chests, time – and that is impossible without a fixed point of reference. The chart is our reference. If you have a Game Design Document, it goes in there; if not, keep it handy and refer to it regularly as a guiding principle.