Friday Script – Modern Algebra’s Message Options

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 isn’t the only scripter with a message manager. Modern Algebra has come up with an amazing way to let you change the position of text boxes so you’re not so limited to top/middle/bottom. Coupled with dynamically adjusting window-sizes, this message manager may be exactly what you need to make your game look, well, less out-of-the-box. Today I’m talking about the “Message Options” script (I’ve linked you to a bunch of Modern Algebra’s dialogue options). Download the script, add it to your project, and let’s get started!

Options

There are a whole lot of features in this script, and each one has it’s own customization options. Roughly speaking, we can do the following:

• Have text follow-on or “append” to the previous text. That is, if you have two “Show Text” commands in an event, one right after another, the manager will appear to connect them in a box.
• Scroll within your message box at variable speeds, line by line, and allow scrolling up so a player can see earlier parts of the conversation
• Have various sound effects, including dialogue start, pause, stop and typing
• Name plates
• Automatically place the message window to not obscure certain characters or NPCs.
• Shrink the window to the minimum size necessary to contain the text
• Position the text in relation to an event on the screen

Look for this section of the script where you can edit the defaults. But all of the defaults can be changed on a message-by-message basis.

Here are some of the interesting ones:

• append_text: when set to true, all commands to add text to the message window will be shown consecutively, that is, scrolling in the same window. If this still doesn’t make sense, set it to true and give it a spin so you can see  what it’s like! False would return to default.
• Pause_before_scroll: combined with append, you’ll get a nice crisp pause before the next page scrolls into your window.
• letter_sound_on: play a typing sound as the text starts to appear. It’s like Phoenix Wright!
• message_windowskin: with this, you can actually change the window skin used dynamically in your game. Use a different skin for different contexts!
• do_not_obscure: this is an awesome feature. Put the ID of the player or event that you want to make sure is visible on screen, and the message window will never obscure that player or event. Really helpful when building cutscenes.
• fit_window_to_message: this will change the size of the window box every time so it’s only as big as necessary.

A note about combining fit and append. Suppose you have several dialogue boxes in a row in your event, like this:

Here’s an example conversation from Vidar – let’s beef it up.

If append is on, even if fit is on, the window isn’t going to change size from text to text – it’s going to be as large as necessary to accommodate the biggest text. So definitely four lines tall. And then probably as long as “a tunnel to dig from our yard that would” which is several boxes down. This means that “What is it?” is going to be in a much larger box than necessary. It’s not bad, it’s not good – you should just be aware!

Example Dialogue

In the example above, we have a conversation from Vidar between two characters – Dorottya and Katarina (who affectionately call each other Dorry and Kat). Even if we’ve set up some of our presets in our script, we can (and probably want to) change them here where it’s not just on NPC yapping at us, it’s a conversation.

First, we want to add name boxes so we know who is talking. We can prefix each dialogue with a command to insert a name box using \nb{Name}. So something like this:

Even though the characters have nicknames, better to be more formal in the name block.

As we put this in, we see that each character gets 1 command, and then it passes to another. Even if we’re using append throughout the game, it would make very little sense to use it here – each character should really get their own box. We can use a script call to turn off append for just this event.

ats_all(:append_text, false)

We’ll want to call the same thing at the end of our conversation, subbing in true, to set us back to the default.

Next is a really fun feature – dynamically setting the position of the box. Now, we can move the dialogue box to above the NPC that’s actually talking so it looks more like a conversation! First we need the event numbers of our NPCs – you can get it at the top of the event page for the character itself.

Even if you change the name of the event, the event number is still at the very top of the window.

Then in our conversation event, we add yet another command – \et[EVENT NUMBER]. The message box will be above the event – you can use \eb for below, \el and \er for left and right. Add them right before the namebox command.

Don’t put any spaces between \et[x] and \nb{Name} – that space will show up at the start of your text, and you don’t want that.

Combining all these elements, we can get a really cool effect that makes the game look less…defaulty.

Our first NPC talks…

…and our second picks up the conversation. Visual cues tell the player who is talking when.

Now just write some good dialogue!

Boston FIG – Post Mortems

Finally, a full summary on my experience at Boston FIG.

Background and Application

Vidar has been in semi-development since December 2013, and in earnest development since March 2014. The game was accepted to the Boston Festival of Indie Games Digital Showcase, a curated selection of roughly 50 games from developers in the Northeast. For the application, I sent the then-working build of Vidar which included the entire ice cave area, a build which by September was several substantial changes old. Specifically:

• Level length was miserably long
• Puzzles were way too difficult
• Time spent in the ice cave got boring
• There were only 12 quests in the ice cave, and because of the random mechanics of the game, it was not unheard of to see only 1 or 2 in a playthrough
• All of the art was stock RPG Maker art, from title screen to the end of the demo
• Bugs everywhere!

In spite of all of this, the curators let me in. I have no idea how that happened, but as I’m slowly finding out, people believe in the game as a concept. I hope I can deliver.

Before Boston FIG, the game was demoed only once, at NYC Games Forum’s July Playtest Night. During that event, roughly 2 dozen people played. Last year’s Boston FIG had 7,000 attendees, so I needed to gear up for a totally different scale of volume.

Preparing the Demo

The core of any showcase is the product, the demo. I have put a lot of thought into what a demo of Vidar looks like, and have mostly come up empty. The game’s core selling feature is a story that evolves not just in response to player choice, but randomly as the game progresses over a 4 hour playthrough. Paced random story generation can’t be demonstrated in 2 minutes, it just can’t. I’m candidly not sure how any RPG does it. Ultimately, I settled on a roughly 10 minute demo. I included 7 NPCs out of the 24 in the game. To demonstrate the random aspect of the game, I killed 2 at the beginning of each demo, and adjusted dialogue and quests available to the player accordingly. I fudged a little and made sure that both Sandor and Bernadett couldn’t die at the same time.

Close up of all the new artwork incorporated for the demo.

Depending on whether the player got Sandor’s or Bernadett’s quests, after free time in town they were sent to the part of the cave where they could complete that quest. Where a player got both quests, a coin was flipped. Sandor’s quest, to rescue his son, is a more contained but more intense story aspect of the game. Bernadett’s quest, to return a ghost to its grave, takes place in the same area as other quests. This allowed players to see elements from the quests they picked up in town.

At the end of the demo, depending on which quests the player did (and who died at the beginning), the player would see a little bit of text indicating what would come next in the game.

Booth Stuff

Because we were going for a 10 minute demo, I needed to have a lot of units. Having only one laptop would’ve meant that we got a whopping 40ish people to play the demo during the day. Not nearly enough. With that in mind, I wanted to have 4 laptops at the event. We were told we’d get a 10×10 booth with a single table and 2 chairs. Realizing that I couldn’t easily convert that into space for 4 laptops, I brought a cheap folding table and 2 extra folding chairs.

For signage and booth decoration I brought two table clothes, a runner with the Vidar logo printed on it (way cheaper than doing it on a full tablecloth), and an XL printed vertical banner.

The tag line drew a lot of people in – so many attendees wanted to know more. If any single piece of marketing did it’s job perfectly, it was this poster.

I also brought a candy bowl with some Reese’s cups, a clipboard with an e-mail sign-up sheet, stickers, business cards, beanies, and a placard saying that if people tweeted @VidarTheGame during the festival with a picture of them enjoying Boston FIG, they’d be entered to win a beanie. My plan was to give out 5 an hour. See below for how this largely failed.

Set-Up

When we arrived at MIT, we definitely did not have 10×10 booths. The 6-foot tables were all adjacent to each other, and about 5 feet behind us was another table. So we had 5×6 booths. Panicked that this totally scuttled my plans, I emailed, tweeted, and smoke signaled the coordinators. Almost immediately I had several responses telling me that I could set up in a 10×10 space so long as I talked to my neighbors about it, neither of whom were there, and neither of whom had set up the night before. So I moved their tables out to a 10×10 space for themselves, and then for me in between them as well. The result was that we were really the only 3 showcase exhibitors that had the space we were promised, and I heard a lot of other people grumbling about changing their booth plans to accommodate the layout they started with. Had they only asked, I’m sure they could’ve expanded as well, there was plenty of space at MIT for everyone to actually have what was promised. I can’t imagine Boston FIG had set them up smaller than announced out of malice, and everyone I talked to was nothing but warm and helpful.

Because of all of this, our booth looked fundamentally different than everyone else’s. For starters, we had 2 tables set up as a T, with the top of the T facing the attendees. All laptops were set up on one table, and then a monitor showing one player playing the game, plus swag and sign-ups, were on the other table. Having never done a convention, I can’t say this was better or worse. I do know that it seemed to work for us, and that we stood out. We were large and in-charge, and it felt awesome.

Business in the front, party in the back. Of the booth.

All of the power was daisy-chained power strips. Beyond being a fire hazard, this meant that if someone tripped over a cord on the other side of the room, we lost power. This happened several times during the day.

Reactions to the Demo

People were generally very responsive to the demo. Make no mistake, this wasn’t uniform, but people at conventions tend to just move on if they don’t like a game (rather than vocalizing what they dislike). It was important to make note of the people who started the demo and left halfway through, as much if not moreso than those who played it through and engaged me in a 20 minute conversation after. Because the goal should be to limit the bucket of the former as much as possible. While the statistics indicate that number was higher than I’d like for Boston FIG, I’m comforted by the fact that most of that was young children who instantly grabbed a laptop because WHY NOT IT’S VIDEO GAMES!!! Seriously, the joy you could see in these kids’ faces was priceless. And it’s maybe a good thing that they couldn’t get into Vidar; there’s occasional inappropriate language, and it deals heavily with death, with loss, with depression, with nostalgia. I don’t want to be responsible for putting these 8-year-olds into years of therapy. These kids often would start the game, run around town, not be able to find a puzzle or big bright graphic in the first minute, and leave, so it skewed our numbers concerning walk-aways. And I’m not even upset, those kids were having fun running around in a wonderland of gaming.

After generally trying to get a sense of positive/negative reactions to the demo, I wanted to see what was positive. Biggest selling point for the game was the random story telling. In fact, as I would go through the pitch, people’s eyes would widen or they get a big grin a split second before the punchline (“With this system, because the order of deaths is randomized, the story itself becomes random.”) And seeing that light-bulb moment, with people starting to get excited about the possibilities of this story-telling system, was awesome.

Full booth, happy gamers, exhausted and nervous developer.

There were also plenty of negative reactions to the demo, most of which are very easily fixed (and indeed are in the main game). More tutorials on controls; easier ramping up for puzzle difficulty; eliminating unnecessary menu options for the demo. Some more interesting take-aways:

• I added a handful of points where people could interact with the environment. Since NYC Games Forum, I’ve noticed that we’ve all been so conditioned by FF6 to check the grandfather clock for Elixers that, as soon as we see SNES-style graphics, we click on everything in every single house. Seriously, players just want to investigate every bookcase, every bed, every picture, every crack in the wall, and of course every clock. It’s crazy. So, in response to that, I added about 5 in the game. This only fueled the fire. Where before people would give up checking everything after a full minute where nothing was responsive, now when one thing works, players spend a good five minutes hitting enter in front of every table. I need to make a game-design decision to fully embrace this compulsiveness, or do away with it entirely. Half-assed was the worst way to go.

• People who “beat” Erik’s puzzle were incredibly disappointed that Erik still died. While I’m mindful of “kill your darlings” issues, I’m sticking to my guns for now on this one. Everyone dies in this game – it’s the tag line on every business card, poster, website, etc. And I’m extremely hesitant to change that. That being said, customers are rarely wrong. I’m curious to see how this ends up playing in testing as part of the whole game. In context, Erik’s death may be more tolerable for players. If it’s not, I’m already playing with ways that you might save Erik. Of course, if he joins the main cast of the town, he’ll still need to die.

• I loved seeing friend-groups come and play the demo together. When three friends each grabbed their own laptop, and the death notifications popped up in their demos, without exception they’d turn to each other and say “oh who died in your demo???” And that followed through – “oh which quests did you get?” “what room are you in?” “wait so is that guy really not in that room because he died???” And if one finished, they’d go over to their friend’s laptop to watch, help puzzle solve, and see something new. It was awesome, and it was the best expression I could have for Vidar.  In a weird way, this leans towards having fewer demo units in favor of a single bigger screen which a crowd can watch. Or perhaps, two units hooked up to two monitors so people can compare side-by-side. It’s tough to know exactly how to recreate this inspection of several simultaneous playthroughs, but it’s something worth brainstorming for the next event.

• The end of the demo, which told the player about what would happen the next day in Vidar, was too much wall-of-text. How to convey the sense of exploration without that text is also something which needs to be resolved.

• Some people immediately walked away on realizing that the game was made in RPG Maker. There’s not really much I can do for them. Even though I continue to strip out elements which clearly identify the game as RPG Maker-made, some parts will always be there. You can feel it in commercially successful games like Always Sometimes Monsters or Actual Sunlight. And that’s ok. Indeed, for every person that scoffed and mumbled “RPG Maker” under their breath as they left, another said “how did you do all of this in RPG Maker?! That’s crazy!” I never want to be a developer that says “if you don’t like my game, I don’t care,” because that leads to leaving money on the table AND a bad game. At the same time, this bucket of people may just not be the target demographic for Vidar. 

Reactions to the Booth

The stickers and the beanie giveaway were both duds, for different reasons. No one wanted a sticker – indeed, the only people that took them (besides the kids, who had dual focuses of playing every single game and collecting every single piece of swag, so matter how small) were those who thought they were business cards. So, now I have 400+ stickers and no idea what to do with them. My husband has suggested that maybe people only take stickers when there is brand recognition – no one wants a Vidar sticker but they might want a Destiny sticker. So maybe the rate at which people take stickers can be used as an unofficial metric of brand recognition? Who knows.

Nobody wanted any of those stickers. At all.

People actually really liked beanies, but were totally uninterested in tweeting. While my goal was to give away roughly 70-80 beanies, I gave away 4 to non-children. It wasn’t a drawing; it was a conditional. If you tweeted, you got a beanie. But, people saw them and thought they were pretty cool. Unlike the stickers, I think this one suffered because of the method of obtaining them. At the next event, I’ll simply hand one out to anyone who signs up for the mailing list, and see how that goes.

Interviews

I did four interviews during the day, and I was progressively worse at each, likely due to exhaustion. The only one which was not video recorded was by Jacob Wood from IndieHangover, and you can read his glowing review here. As of writing this post, the remaining interviews have not been posted. These interviews themselves were eye-opening. In advance of Boston FIG I made the conscious decision not to contact too much press, and to only focus on a handful that I thought might help at such an early stage. The thought process was that Vidar is too early. As it turns out, press responded to the concept despite how far we are to a release. I still don’t know that not reaching out to press was a mistake per se, and think that, with list in hand, I can now contact these outlets, journalists and podcasters as I approach a kickstarter saying I was at Boston FIG, the game was still so early but got into the showcase on the strength of the concept, and I’m about to kickstart.

Summary, Going Forward

Boston FIG gave me the courage to do a few big things:

• Go back to NYC Games Forum in October. While I was concerned that the demo was not different enough since then, it is actually. It’s new art, new puzzles. But even if not, so what? The name of the game is exposure, and I’m sure that for every 1 person that says “oh I played this last time, no thanks” there will be 2 that wanted to but didn’t get a chance, and 5 that weren’t even at NYC Games Forum 3 months ago. It’s worth it.

• Bump up the kickstarter to as early as late-January. I’m still going to wait to see community engagement metrics improve – more emails on the list, more twitter followers, etc. But one big concern I had was having a 1-hour press demo sent to press to get some really good quotes in order to further promote the game. And with four interviews at Boston FIG I might just already have those. Which would be awesome.

As for the former, there’s no rest for the wicked. I’m already planning on adding more content for the next showing on October 30. Expect posts about that soon, and thanks for reading!

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!

New Swag!

This awesome beanie has an awesome logo and is awesome for all outside-based hipster adventures. Awesome!

To celebrate the arrival of new swag, I’m giving away a bunch of it! All you gotta do it sign up for the extremely rare, extremely non-spammy Vidar newsletter. It’s so rare, one has never been sent out yet.  It’s so non-spammy, no one has ever even asked me to sell them your email addresses. BUT IF THEY DID I’D TELL THEM NO, SIR!

Go to http://bit.ly/Vidar and sign up with your email address before September 13 for a chance to win!

Alternatively, come by the booth at Boston Festival of Indie Games at MIT on September 13!

Screenshot Saturday

Sandor the clockmaker and Dorottya the blacksmith hanging out in the new workshop. 

 

Screenshot Saturday

Tileset created by Becca Bair, combined with RTP graphics.

Busy week, but I got to use Becca’s new Vidar tileset. Combined with some of the good ol’ RPG Maker standbys, it really creates a beautiful, wintry nostalgia. Which is tough to do when it’s so gorgeous outside!

One Map At A Time

Art courtesy of Becca Bair.

This is my first attempt at parallax mapping! Undoubtedly, I’ll need to fill this space with more trinkets and variation, but it’s definitely getting there. I used Reddit user PieHardLol’s super awesome tutorial and accompanying video on parallax mapping. If you’re going to attempt something like this, watch that video about a dozen times before starting.

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.

Bookshelves – Dev Blog

Super excited about this new puzzle in Vidar. Should you come across a library, you’ll find books all over the place and all out of order. If you place those books in the right place, something quite awesome will happen. I want to show you how I’m handling the bookcases.

To do this, I used a few variables:

• One for each bookcase – this will hold the item ID of the book currently on the assigned bookcase
• One titled “Book to Place” – this will hold the item ID of the book we’re able to place
• One titled “Bookshelf Being Tested” – when you interact with a bookcase, it places it’s number in this variable
• One titled “Tested Case’s Value” – this looks up what’s current on the shelf you’re interacting with

I also use Yanfly’s Message Manager – a Friday script feature will certainly follow, but I’ve been giving Yanfly a bit too much of the spotlight around here recently 😉 The only use here is to be able to reference an item name easily.

Nearly all of this is handled by a common event. Here it is:

Well, almost all of it. Ignore the stuff below the cut-off, it’s just there to handle what happens when you try to put your journal on the bookcase. It doesn’t belong there!

The first line finds out the number stored in the variable associated with that particular bookcase. If the number is greater than 0, it means there’s already something on the bookcase! So, we tell the player that the item is on the bookcase, and ask if they want it. If so, we give it to them, and set the value of the shelf to 0.

If the number’s not greater than 0, we use RPG Maker’s built-in “”Select Key Item” command to allow the player to chose a book from their inventory. That book then gets removed from inventory, and the variable associated with that case is changed to the book’s item ID.

There’s one more step in the equation. The case itself.

This is the actual event the player interacts with. Put it on the bookcase!

This is the event you interact with, and it needs a bit of explaining. The first line is just flavor text. In the second line, we set Bookshelf Being Tested to a number. That number is the variable ID for Case 5.

 

As noted at the top, every case gets its own variable.

In every bookcase, we set Bookshelf Being Tested to the correct variable ID. So, if we were testing Bookcase 8, we’d set the variable to 55. What this does is allow our common event to ask “what variable am I supposed to check to see if there’s an item on this particular bookcase?”

We call the common event, and it handles the rest of the logic.