Vault-Tec Labs
Register
Advertisement

A tutorial by Pjnt of Fan Made Fallout, part one is specific to the FMF Dialogue Tool; part two is specific to Dialogue Techniques in Fallout, which is highly recommended. I would suggest reading part two first. The FMF Dialogue Tool quick start tutorial is also a good read. There is a new article which is the spiritual successor to this one called Dialogue Training Continued.

Writers Training I[]

This is the first part of 3 guides to help with writing. Here we’ll cover the Dialogue Tool. Using the right tool for the job is important. This will try giving in-depth information to use the tool to complete a dialogue. I’d like to thank Dj Unique and Agrajag for providing both the tool and a good chunk of the training material, respectively. I hope Agrajag doesn’t mind some editing I have done on his work!

The Dialogue Tool[]

It is preferable if you use FMF's special designed Dialogue Tool, made by Dj_Unique, since it will greatly speed up the process of putting the dialogue into the game. However, if you for some reason really don't want to use this tool, you may use any form of text document to store your dialogue, so long as the dialogue tree isn't totally incomprehensible. Use a system similar to the one you had in your application. The latest dialogue tool is 0.27.0-stable, and can be downloaded from here.

Dialogue Tool Techniques[]

==The Switcher==

One thing that might not be strictly necessary, but still quite useful and easy enough to do, is using so called Switcher nodes. A switcher node is just a normal node in the dialogue tool. You only need one for each dialogue. Let the dialogue start at the switcher node, and for each different situation that the PC can speak to a NPC, add one player option to the switcher node, leading to the correct starting node. Different situations may be (but definitely not limited by) when the PC speaks to a NPC for the first time, if the PC spoke to that NPC anytime before, if the PC accepted a certain quest, if the PC solved a certain quest, etc. Okay, maybe that was confusing. It's easier to show in an example, instead. Let's pretend we have a character called Robin. Robin can give the PC quest A and quest B. Here's an example of how you can do his switcher node:

Node: Switcher.
1. PC never spoke to Robin before -> Greeting_0
2. PC spoke to Robin before, but is not doing any quests -> Greeting_Return_0
3. PC have accepted quest A -> Quest_A_0
4. PC have accepted quest B -> Quest_B_0
5. PC have insulted Robin -> Insulted_0

Node: Greeting_0. "Hi, I'm Robin. How can I help you?"

1. You tell me. -> some node

2. Blablabla -> other node

3. Bye. -> end

Node: Greeting_Return_0. "Hello again."

1. Hi. -> whatever

2. Blabla. -> node

3. Bye. -> end

Node: Quest_A_0. "Have you solved quest A yet?"

1. Not yet. -> ...

2. Yes. -> yay


Node: Quest_B_0. "Have you solved quest B yet?"

1. Not yet. -> ...

2. Yes. -> yay


Node: Insulted_0. "Get outta here you asshole!"

1. Fuck you! -> combat

2. Okay. -> end

Node Names Naming your nodes appropriately should help in keeping the dialogue well organized. For small dialogues it isn’t such a major problem, however, when tackling massive multi-quest dialogues, it can cause headaches trying to keep everything in order should a simplistic naming system be used.

Please review the node names in the Switcher Node information above. You’ll notice that the node names chosen reflect corresponding parts of the dialogue. If you have to take a break from the dialogue and return it is much easier to determine where you left off. The number at the end would increase with each additional node within that particular piece of dialogue.

All nodes require names, but the names can't be just anything. They may only consist of any of the following signs:

Code:
 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_

Furthermore, a node name may not start with a digit. So for example, "A_B_C_8234" is a valid node name, but "123_A" is not. A node name must not have any spaces in it: "Node A" is not a valid name. The very same rules apply to all the skill check names or procedure names you may have to enter while using the dialogue tool. The reason for all of this is of pure technicalities: the syntax can't handle any other characters, and you would get errors if you tried to compile the faulty node names. While the tool may or may not crash if your node names are invalid, the dialogue will still be unusable once put into the game.

Another thing to be aware of is that you can't use the normal quotation marks (these: "") in the designer's notes - it will make it impossible to open the dialogue file with the tool (to fix it, you have to remove the quotation marks "by hand" by opening the dialogue file with a text editor).

Skill and Ability Checks Occasionally you’ll only want an option to appear if the PC passes a Speech requirement. Or if the PC needs to complete an act of strength within the dialogue, you’ll need to know if the PC succeeded or failed. The Dialogue Tool makes this easy.

When you’re adding a response option you’ll notice a button called “Set up conditions…”, bottom left. Click it. Now you’ll be able to attach different conditions to the dialogue option. For example, if the PC needs to throw a knife into a target within dialogue you’d select ‘Skill’ under ‘Check type’, ‘Throwing’ under ‘Field names’, say, ‘>(larger than)’ within ‘Evaluation type’, type a number that you’d check against, say ‘50’ in ‘Value to check’ and finally you would click ‘Add’. This would add the condition that would check the PC’s throwing skill vs. a 50% requirement to hit the target.

Floaters[]

This is fairly strait forward. At the top of the dialogue editor you will be on the default ‘Regular Nodes’ tab, clicking the ‘Floater Nodes’ tab will allow you to add, delete and edit floaters. Floaters are text that the PC see’s hovering over NPC’s within the game. Junkies would float text like “I need a shot.” Etc. The node names should reflect the condition which the node would be displayed, it almost always reflects the Starter Node. IE, when the PC has not met the NPC before or if the PC has completed a quest which helped the NPC. Then you just add –short- floaters under that node. Couldn’t be easier.

Other info[]

I like to save often. The dialogue tool comes with an auto save function which I love. It doesn’t overwrite previous saves, so can be very handy. Also, there is a small ‘dumb option’ box which makes creating text for dumb PC’s easy. Just click in on and you’re done.

Great! On to part II. Next we’ll cover writing techniques.

Writers Training II[]

Here we will look into the techniques you’ll need to write convincing dialogues and how to present them in a uniform manner so the game flows nicely.

Dialogue Techniques[]

When writing dialogue, there are a couple of things that has been decided upon to help all the dialogues in FMF to be consistent with one another. Here is a list of common things:

  • When you want to describe something, write it in [brackets]. Eg: [The man laughs at you.], [He coughs.], [Her eyes are blank and she looks very pale. She is shivering as if it was very cold.].


Descriptions are used to make the dialogue feel more "alive", to make the NPC sound more real. Be warned however, that using it too much may take some of it's effect away. More often than not, more is less. Never write what the PC thinks or says or does in a NPC response. Things like "[She is pale. You think she hasn't slept in days.]" should always be avoided. Only write what the PC is observing, not what he is thinking - the thinking should always be left for the player to do. A NPC response like this should also be avoided: "[He laughs at you. You hit him over the head, and he falls to the ground.]". What's wrong here is that the player didn't choose to hit the NPC over the head - it was an action forced to him. To avoid this, you could instead add a player option that goes "[Hit him over the head]", to which the NPC responds "[He falls to the ground]", or something.

  • Actions. Sometimes, rather than writing "[He coughs]", it may be more effectful to actually write the cough. This is done by writing the action in *stars*. Examples: "Hi there, *cough*", "Wow, you really suck! *Laugh*".
  • It's quite common that you end up with a situation where the PC has nothing to say - the dialogue is supposed to end here. In those cases, write "[Done]". Following the example above, where the PC can hit the NPC over the head, whereafter the NPC falls to the ground, the next player option would probably be "[Done]".


Sometimes, most commonly when a NPC is telling some kind of story, what the NPC needs to say is quite long. The dialogue screen in fallout is not very big though, and rather than having the player scroll down five pages, we strive towards having only short replies. If the NPC needs to say something that would probably take up more than 2 or 3 pages (in the game), try to break it up instead. Write the first part, and leave the only PC option as "[MORE]". This makes the dialogue easier to read.


In some cases, variations of [Done] and [More] may be appropriate. For instance, if somebody tells you to wait, one player option could be "[Wait]". [Done] and [More] are the two most common ones though.


  • Non linearity. One of the things that differs a good dialogue from a bad one, is non linearity. A good dialogue includes a lot of ways for the player to get what he wants. While non linearity is greatly influenced by the character and quest design - something that is done before the dialogue is actually written - there are still ways to spice up certain situations. The truth is of course that the player is always limited to what he can choose to say in a dialogue. He can't, for obvious reasons, phrase his own questions and say exactly what he wants in a dialogue. Hence, the dialogue writer will have to guess what a player might want to say in any given situation. This is what makes dialogue writing tricky. It's easy to get carried away here, but if you're not careful, it's also easy to miss certain things that the player might have wanted to say. We are forced to balance somewhere in the middle - we can't give too many choices for the player, but we don't want to force him into a specific path either.

So what can be done to create the illusion of choice (for it is indeed an illusion, as we have seen)? A common situation that you will probably find yourself in sooner rather than later is where the NPC is telling the PC a story. It's easy to just have a "Go on." node here, but there are ways to make it more interesting than that. Interactivity is the key. If the PC can ask questions about the story, rather than just urging the NPC to "go on", things immediately becomes more interesting. A simple "But why didn't you..." or "That's too bad", or "You got what you deserved" improves the feeling of choice tremendously, without necessarily requiring a lot of extra nodes. Sometimes a simple "go on" or "[Continue]" is quite enough, but if it goes on for more than two or three nodes, it quickly becomes boring. A trick that is often effective (though it should only be used moderately) is the one where you have two nodes that leads to the same things.

There are a couple of "standard" things the player often can say, such as "Can I ask you something else?", "Goodbye." and "I will kill you now!". Basically one option leading to the "general questions node", one that peacefully terminates the dialogue and one that initiates combat. These are available in most dialogues, which is good. Keep in mind though, that it's not necessary, or even good, to have these three options available always. The best is if the PC only gets them if the situation somehow calls for it. As a rule of thumb, an option to quit dialogue should be available every three nodes.

  • Emphasizing words. Sometimes it's good to really emphasize certain words in a sentence. For example "Why don't YOU do it then?". How to actually do this in the dialogue is still a somewhat unresolved issue however, but it's rumored that there is a way to make words bold in the fallout dialogue. If that's the case, we'll use that as an emphasizer. Until the issue is resolved, I'd like you to write things in CAPITALS if they are emphasized, like in the example above.
  • The reaction modifier. You may have noticed that it is possible to change the reaction modifier for a player option. This is used to determine the colour of that player option, if the PC have the Empathy perk. You shouldn't bother too much with it now though - this is one of those things that we're returning to fix at a later time.
  • Stupid dialogue. All NPCs will require stupid dialogue, which means dialogue options for player characters with an intelligence of 3 or less. How much will be needed for each NPC is decided individually, on a case by case basis. Each quest is worked through for "dumb" quest resolutions separately, and each fully finished quest should have some mention about how that quest applies to dumb characters. For NPC dialogues, everything that's required in the dialogue that has something to do with a specific quest should always have some kind of mention about what a dumb PC can say/do. If there is no mention of what a dumb PC can say regarding a specific quest, don't write any dumb dialogue for those paths! How and what a dumb PC can say for non quest related things in a dialogue may be chosen by the dialogue writer. For example, if the NPC thread says that the PC can ask about the weather, that is not a quest specific thing, and the dialogue writer can feel free to come up with whatever he think fits to that situation for the dumb PC.
  • American spelling. All NPCs in FMF will be Americans. Hence they speak American english, and they write "color" instead of "colour", "armor" instead of "armour" etc.. I'm not very good at separating the two, but you should in all cases try to spell things the American way. The Texan way is to prefer, if you know the difference. I can tell you I don't... Also, measurments are all in lbs, miles, feet, etc., and not the superior SI system that everybody else in the world uses because it makes all calculations a billion times easier...
  • Mannerism. The player options should always be kept as neutral as possible. Avoid accents, and things like "I ain't never done nuthin', y'hear?". NPCs may speak like that, but not the PC. We're role playing here, and the player is in charge. He shouldn't have mannerisms forced to him.
  • Player options. There are eight lines available for player options, but any player option may take up more than one line of space. Hence, a good rule of thumb is to not have more than six player options available for a single PC (there may of course be more if some options exclude others - for example stupid player options won't count towards this number for smart PCs, since they won't be able to see the options).
  • OK, ok, O.K., okay or O-kay? It's been decided that we're always going to write "Okay", instead of any other variation. Another consistency thing.
  • Ending nodes. The PC needs to know if the node he chooses will end the dialogue. Therefore, each ending node should include a "goodbye" or similar. There may be exceptions to this, but they are quite rare.
  • Don't over-do the "three dots". Or to phrase it like Stevie D: "dialogue writers should avoid... over-using... the... three dots to punctuate their dialogue. That's what commas and such are for. Used sparingly, they can be very effective. Used too much and they're daft".
  • Note: the "three dots" are actually called an elipses
  • No player option should end by trailing off into dots (...)

For example:

NPC: Now listen, youngster. I first moved here fifteen years ago, before Alex founded the Brewery.
PC: But wouldn't that make you....
NPC: I said listen! Don't interrupt. Now, where was I...

This is because the player will not know what it was he was going to say. The player does not know when he is to be interrupted. We're not writing a novel here, we're simulating a freedom of choice. In short: avoid any player options that might be unclear to the player what they mean.

  • References. In 95% of the cases, they should be avoided. When not avoided, they really should be left subtle. Don't cram in references for the sake of cramming in a reference.
  • It is very bad form to be able to attack a PC in dialogue. You can initiate combat, but not actually accomplish it. Avoid [You hit the guy in the nose.] or [Joe Blow kicks you in the groin.]. These both would require a combat roll. Giving free hits is not ‘real’.
  • We are sticking with the standard ftbab (fade to black and back) screen when you’re humping. In the dialogue tool, be certain to include this effect within the designer’s notes that there will be a ftbab.
  • When you terminate a dialogue, that option comes last.



NPC Followers[]

Your companions have dialogue, too. If you’re assigned a NPC which can become a follower you’ll be responsible for creating in-party dialogue. You’ll have created a Starter Node entry which would be something like ‘NPC_in_party_greeting_0’ which will link to the tasks you wish your follower to complete. Here are the basics for a generic NPC, it’s just a guideline and you you’ll need to fill in the NPC’s text;


* I need to talk to you about your gear.
o What weapons can you use?
         o Put away your weapon.
         o Take off your armor.
* Wait here until I come back.
   * We need to change our distance.
o Come closer to me.
         o You need to be further away from me.
* It’s time we part ways.
   * Nothing, bye.


There might be other information that the NPC has specifically for the PC. The quest description will have all necessary dialogue listed.

Links[]

Advertisement