Integrating Chat Mapper: Part IV

• Part I is here
• Part II is here
• Part III is here

So it’s come to this, we’re finally ready to take our dialogue tree – which we’ve painstakingly crafted in Chat Mapper and exported and converted to a file RPG Maker can understand – and do something with it! For this part, you’ll need the most important script, the parser. You can download it here. For this script, I ask that you give credit to Matthew Canterbury anytime you use it, whether commercial or non-com. Put this somewhere in your materials folder, like you would any other off-the-shelf script.

FACES: A Detour

But before we do that, there is one little customization option we have to consider – whether or not we’re going to use faces in our Game Messages. You must do one of the two options below.

1. Yes, I want faces: Your project should have a directory called Graphics/Faces. This is where the parser looks for face files to combine with the text in your Message Window. The hitch is that it expects one file per “Actor,” and I use that term not as RPG Maker uses it, but as Chat Mapper uses it (check out Part I for all of that stuff). Which means that if you have this in Chat Mapper:

We set up the Actors in Part I of the Chat Mapper tutorial

Then in order to draw a face, you need to have a file called “Cecilia.png” in the Graphics/Faces folder. That file should be 4 faces wide by 2 faces high (just like the default RPG Maker templates) but for right now, really only concern yourself with the Top Left. I’ve just copied and pasted the same face 8 times for completeness. And my Graphics/Faces folder looks like this:*

Why did I do this? For features yet to come of course!

If you don’t do this step for every actor you have in your Chat Mapper project, you’re going to get an error. So make sure everyone is there.

Sometimes, though, one of your dialogue boxes is just “Got a Lantern!” and you don’t want a face for that single box. What to do? In Chat Mapper, make a new Actor that has a completely blank name, and use them as the actor for that one box. Remember, even though the conversation has a default Actor, you can always change it from box to box. There’s no need to create a blank graphics file in your Graphics/Face folder – the parser will know just not to put a face when it comes to this box.

The dialogue boxes above and below this one will show a face – this single one will be faceless.

2. No, I don’t want faces: In the parser you just added, go find the section that reads:

if actor != nil && actor.name != ''
     $game_message.face_name = actor.name
else
     $game_message.face_name = ''
end

And replace all 5 lines with:

$game_message.face_name = ''

Remember, you must do one or the other from above. If you don’t do number 2, the parser will expect graphics for all of your Chat Mapper actors!

Load the File

Next, we need to ask RPG Maker to load the .rvdata option we spent all last week making. Create another script section in your RPG Maker file below where you inserted the Dialogue Parser. Add a single line:

DialogTree::load_dialog_file(" ")

And in the ” “, add the file path to the .rvdata file you made. Remember to start the path from the top folder of your project. This means you omit, for example, C:/Program File/RPG Maker/Honey Boo Boo’s Projects/My Game 1 ……all of the junk that comes before your actual project. If you just put the .rvdata file in the “Data” folder, you’d write: “Data/Dialogue.rvdata” – assuming your file is named Dialogue. Got it?

Make sure this runs AFTER the dialogue parser, but BEFORE main.

Curious as to what the rescue => e nonsense is in the screenshot? If you’re trying to figure out what error is happening, this prints out an error message to the console. It’s particularly helpful for scripting, and if you’re not getting something in all of these scripts and integrations to work, it’s an invaluable tool for your belt.

Call the Parser

It all boils down to a single script call. After everything we’ve done. In your NPC’s event page, where you would’ve had all of these conditional branches, Show Message commands, scripts, switches, variables – we’re going to replace all of it with a single script call:

DialogTree::run_conversation('ConversationName')

That’s it. You’ll obviously need to replace the ConversationName with, well, the name of the Conversation you want from Chat Mapper. Remember wayyy back when, we said that each “tree” is a separate conversation? So basically, you’re picking a tree.

The result is an event that looks something like this:

Elek is ready to converse!

What’s fun about the script is that it’ll print to the console as it travels through your tree. So you’ll get to see each condition, and whether it evaluates to true or false. Hime has a post on his blog about how to enable the console.

And that’s it! Those are the steps to integrating Chat Mapper with RPG Maker. Remember, Part III lists all the steps you need to do to make edits to your tree and re-export. If you’ve done everything right, you won’t have to repeat any of the stuff in this post ever again!

The rest of this week we’ll be talking about Vidar, but next week we’ll pick this up again and look at some advanced ways to integrate with various off-the-shelf scripts that change your messaging system. We can use those for positions, for name blocks, for colors, for all sorts of things!

 

*You might be saying, Dean, this is a really weird way to save these graphics, why not have a face sheet with 8 different faces? Soon, the script will support using Chat Mapper’s “mood” function (most of it’s already built), and we’ll be able to do things like “Cecilia’s Sad Face” for just this bit of dialogue, then “Cecilia’s Angry Face” for the next. You’d have 8 emotions on the same sheet to do this.

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!

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.

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.