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.

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.

Advertisements

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.

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"

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.

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.

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.

Making Maps – Outdoors Details

The town of Vidar was made entirely with RPG Maker RTP - it's possible!

The town of Vidar was made entirely with RPG Maker RTP, no fancy photoshop business. It’s possible!

 

Last week we talked about laying the foundation for an outdoors map. The principles could be applied to anything – a forest maze, a volcanic dungeon-crawler, or as the example discussed, a snowy town. But laying a proper foundation only gets us halfway there – to continue, we need some details. As with before, you can use these tools in every outdoors map you make!

1) Flesh Out the Important Parts First

Mapping is all a means to an end – if you have a gorgeous map but the player can’t reach the exit, the map is useless! Now that you’ve got a semblance of structure in your map, make sure that it does what you need it to do. Define the maze. Add your puzzle, with all of its switches and statues. Build the shop. Even if your map is just an entrance to a dungeon, now’s the time to nail down 100% that transfer event. Because the rest of the stuff is just gravy.

Add your doors, from here on out we need to build around them.

Add your doors, from here on out we need to build around them.

2) Vary the Floors

One nice thing about the RPG Maker RTP is that each floor has a few variants, and now it’s time to put them to use. When you’re outside, unless you have a man-made area, curved and irregular lines tend to dominate straight ones. You might’ve noticed in the picture above, we added some grass under the trees, but we can certainly go further.

 

If this were the entire map, I'd say this is a good amount of variation. As you can tell from the top post, this is but one corner; so let's fill the whole thing up with grass!

If this were the entire map, I’d say this is a good amount of variation. As you can tell from the top post, this is but one corner; so let’s fill the whole thing up with grass!

If you’re not using the RTP, but you are relying on someone else’s tileset, make sure to look for one that has multiple floor variants, otherwise things can start to look a little samey.

 

3) Go Big to Small

When it comes to accent pieces – those rocks, flowers, trees, tools, etc. that decorate our map and make it come to life – start with the biggest pieces first. Four-tile trees are big, and can often block a path. You’ll want to know this information before you start drawing little cracks in your roads. Work your way down to individual rocks, tiny thing that the player will pass over without even noticing. A few extra notes for when you’re placing your decorative tiles:

  • As you work from big to small, also go from rare to frequent. That is, have a few big items, some medium items, and a lot of small items.
  • Since you’ll only have a few big items, there’s no reason to have two of them in the same 17×13 (screen size) space. When big items are duplicated, the duplication is noticeable.
  • However, duplication of small items is not only necessary, it’s encouraged. Grouping small items in an area can make them seem both like they belong, and like they’re part of the ground or tileset. A lonely tile of fallen leaves looks like a stray mark (or worse, like something your player should interact with). A bunch of them under a tree look like Fall.
  • There are very few things people need two of. Avoid duplicating tools, manmade objects, etc.
One statue, two lamp posts, one log pile. But then we duplicate small rocks and grass variants.

One statue, two lamp posts, one log pile. But then we duplicate small rocks and grass variants.

4) Level with your Level’s Levels

Last time I strongly suggested adding varied height, because it’s a great way to fill up space and add a dynamic visual feature to the map. If you’ve got some really good height, let’s mix that up even more by creating intermittent ledges. It’s simple!

  • Using your ground tile, draw a 1-tile high ledge right into the middle of your wall. You can do it at any height; I like to play between 2 off the ground and 2 from the top.
  • In any column where there is a ledge, add another wall tile to the top of that column.
  • Add in shadows on the left of your ledge.
Ledges can do wonders to even further break up a cliffside, particularly if you're defaulting to 2-high.

Ledges can do wonders to even further break up a cliffside, particularly if you’re defaulting to 2-high.

5) Shift Click

The most tedious, the most painful, and the most important step. BigEd781 has a great tutorial on how to shift click – go read it if you don’t know how! We’ll need to use this technique in a few places. The most important thing about shift clicking is to be consistentexperiment with different looks!

  • Any time a path reaches a doorstep or a stairway
  • Any time the ground abuts a building in a way that looks funky
  • For bridges, or anything that goes under another thing

 

Cleaning up around paths, connecting them to form a straight line. Now Vidar is starting to feel like home!

Cleaning up around paths, connecting them to form a straight line. Now Vidar is starting to feel like home!

6) Tinker

The last part is up to you. Look at areas in game and see how they feel. Play with them accordingly, until you’re satisfied!

7) Revisit

In a week or a month or two, you’ll come back to this map and realize you’ve learned a lot about mapping (notice how the top image for Vidar doesn’t have any inset cliffs?). After you feel comfortable with a map, put it aside for a little while and revisit it once you’ve made some progress. You’ll be surprised how much you can always improve!

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.

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.

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.

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.

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!)

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?

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.