Friday, December 18, 2015

Developing a Social Interaction Mechanic - Part II

Goals

This next post will focus on the goals of the mechanic. Since we're building this mechanic for a very specific purpose (representing non-guaranteed informational exchanges in D&D), we need to keep a few aims of the system in mind:
  1. Strategy. The system should provide a degree of choice, allowing players to make meaningful decisions based on the abilities of their character and the situation at hand.
  2. Meaningful outcomes. Completing an EM should have a meaningful outcome which can change a given situation to a previously-inaccessible one. This also implies that there should be some incentive to completing an EM.
  3. Simplicity. When I say this, I'm being relative. The system has to be balanced: it should account for the various nuances of social interaction but remain simple enough that it takes only a few actual seconds to determine an outcome. Note that, since D&D combats can offer take over half an hour to complete, the total running time of the interaction can stretch out, but individual steps should be easy to complete.
  4. Progression. Failing an EM must never deadlock the game, but instead progress to a new state. Similarly, progression must be ensured within the sequence: even if we take half an hour to complete a full interaction (which may happen if say, a legal trial is taking place or a person is under interrogation), each step should reveal some new information.
If we do not follow these aims, the system runs the risk of being boring, over-complicated or having no effect.

Features

Now let's consider some of the features of human communication.

  1. Information is transmitted, usually imperfectly. All instances of communication involve information transfer, as touched on in the last post. There is a sender and a receiver of meaning, The sender relays some information to the receiver, who then interprets the information. There are several ways in which meaning can be lost: the Internet is particularly prone to this. Wiio's laws comment on these problems, remarking on the inherent differences in language, culture, personal beliefs and the weaknesses of the transfer system all as ways in which meaning is distorted or destroyed.
  2. The meaning of a message depends on prosodic features, nonverbal communication and word choice. Messages, even ones using the same words, can have very different meanings depending on how the message is produced and the context of its production. Sarcasm and irony are great examples of this: just consider how many different meanings can be obtained from the phrase "You look terrible" (some of them: mockery, pity, concern, even admiration...) Furthermore, message meanings can depend on the relationship of the sender and the receiver: the above phrase is interpreted very differently when a stranger says it compared to, say, a parent.
  3. Interpretation of a message's features depends on the receiver's prior knowledge. This idea builds on 1 and 2, as ultimately it concerns how the features of meaning are misinterpreted. Jargon provides a good example of how the features of a message require certain prior knowledge of the receiver, but this can apply to many other features of communication: if the receiver does not know that a particular inflection suggests sarcasm, or that a certain gesture symbolizes approval, or even if they don't speak the language, they are incapable of fully comprehending the message.
So based on these factors, we can see some goals which overlap with features. Progression can be ensured by the continual transmission of information: each successive "pass" informs the receiver further, allowing new options to open up, thereby satisfying the need for strategy, as new options require deeper choices. Furthermore, message meanings depend on features which provide different nuances, another level of strategy which can be categorized for simplicity. And, of course, enough information can lead to a final interpretation and action, providing a meaningful outcome. So now we can experiment with how to actually implement this system!

Designing the Mechanic

Based on the needs and features we've outlined, I'm inclined to rely on a connected, acyclic directed graph to represent the systematic progression from each state of information-sharing to another, until a given "goal state" is reached. This doesn't require any actual implementation yet; we'll get to that in a future post. For now, we can construct a graph that obeys the following rules:
  • Each vertex represents a state of information
  • Each edge represents the addition of new information in a given form. While there are multiple ways to add new information, they will result in different states (e.g. the receiver may trust the information differently, or misinterpret it...) depending on how addition takes place (the given form). Since information is always added (we can't take away information), edges are directed and acyclic (can't get back to an earlier state).
  • Vertices with an outdegree of 0 are "goal states."
The fact that we consider the graph to be acyclic means that every state - even those in which communication fails - has a small effect on the progress towards a meaningful outcome, which we need to be able to quantify. This becomes rather difficult as the number of states increases: if there are a thousand different states (easily doable with a routine outdegree of 10, which would require only 4 "rounds" of exchange, since 10^(4 - 1) = 1000), we would need more and more information to store changes.

This of course assumes we always have around 10 choices. If we limit the number of outdegree of the vertices, however, we can decrease the number of vertices we need to keep track of significantly. Furthermore, we can limit the number of vertices by adding prerequisites to certain edges. Certain choices only open up when we're at a certain vertex. Without jumping too deeply into implementation, if we have a vertex representing a particular state of information, the specific details of that information may naturally lead to other information being uncovered (if directions to an address were being provided, we'd have to know how to get to point B from point A before trying to understand getting from point B to point C).

Furthermore, we can categorize states of information based on multiple factors. Adding information can have multiple effects, depending on the success of the addition. Failure will naturally tend towards certain responses (frustration, anger, confusion...) that will not occur during success, while the way in which information is added will naturally provoke certain new emotional states between the sender and the receiver.

Conclusion

This has been a bit theoretical, but it should provide some good groundwork before diving into methods for implementing the mechanic. Let's review where we stand. The mechanic should allow for clear, comprehensive and meaningful player choices. These choices should allow progression to a clear goal without the players getting lost or confused. Additionally, the mechanic should represent the imperfect exchange of information inherent to conversation, which eventually leads to a decision point at which the parties decide how to act based on this information. Given this, we can use a tree graph to "store" the information: each vertex storing multiple attributes of the current state of information and a list of possible choices to move to another state, while aiming to keep the number of states low enough that the system is easy to use.

In the next post, I'll start on an implementation of these ideas.

Tuesday, December 15, 2015

Developing a Social Interaction Mechanic - Part I

Introduction

As of now, whenever social interaction comes up in my D&D games, it's a clusterfuck. There's a bit of actual acting roleplay, which is a bit clunky (mostly for me since all my off-the-cuff characters are essentially the same), and a bit of narration (I explain as DM what the NPCs say or do or want), which is hard to make interesting. The whole situation is disorganized and stressful: it's totally up to me how much information I do or don't share with the players, and usually I don't even know myself (since I generally just write down a few characters and their motives before starting an adventure).

I don't want to do that anymore when there is an alternative: come up with a social interaction mechanic.

Many DMs have tried different ways of doing this. When I started playing D&D with 4e, we used skill challenges from time to time, which were really railroady. Other times, a simple one-off skill check (roll Diplomacy, roll Bluff, roll Intimidate...) was all that we did.
Other worthy efforts I have seen have been a card system and a modified diplomacy check. I'm sure there's a lot more out there, but I also have a good feeling it will come across the biggest problem with representing social interaction in a RPG:

Social interaction is made up of a vast and complex matrix of relationships, emotions, beliefs and physical actions which are obvious to anyone who is capable of social interaction.

Most D&D players are not very familiar with creating fireballs out of pure energy or headbutting a hobgoblin off a bridge, but if they're in your D&D group they are capable of social interaction (the skill at which varies between people of course). So most of us are aware of patterns of social interaction - things to expect or do. We know that, for instance, a hungry person might be more irritable, or a grieving person may not be in the mood for levity, or that a superior may expect a certain degree of etiquette from a subordinate, and we modify the way in which we interact with these people appropriately.

And most of the time in D&D, these expectations are met: the baron is upset by the rudeness of the players; the lost child is grateful to be found; the pirates are excited by the prospect of riches. But occasionally there are situations where it is difficult to know how best to proceed.

Say the players are investigating a close NPC friend's murder in a small frontier village. The villagers can be assumed to be generally suspicious of the players: in a dangerous region like this, outsiders could mean trouble. Authorities are less accommodating and will harass foreigners. However, certain qualities are valued highly among the villagers: strength, resourcefulness and honour are all of importance. The social structure is one of clans, divided along family rather than professional lines. Keeping the peace among villagers is more important than fair justice, as each clan cares for its own and is indifferent to the plights of the others.

These are all beliefs held by the members of the village about how their world works. It means they will not be coerced or threatened into disclosing information, and any outsider must prove their worth if they want to be treated warmly. If the players march into town, traipse into the bar and say, "Barkeep, what can you tell us about the murder of William the Wanderer?" the barkeep will politely say "never heard of him" and ignore these arrogant strangers. Anyone else questioned will likely say the same thing, and if the players continue nosing around they will be escorted out of town.

If, however, a single player comes up to the bar and, noticing a prominent hunting trophy on the inn wall, asks the barkeep to tell the story of how the stag was killed, the player can use the barkeep's beliefs and emotions to gain an "in" to the village's culture. The player may respond appropriately to the barkeep's story, speaking at the right moments and encouraging the barkeep to continue, in order to lead the barkeep to believe that the player is not a threat.

In the first situation, a group of strangers barge in looking to enforce justice in a way they see fit. In the second, a single instigator persuades an insider to trust them. Both situations are based on a fundamental exchange of information: in the first, the players want to know what happened to William the Wanderer. In the second, the player wants to the barkeep to know I am your friend. The first situation is an interrogation; the second, a manipulation. These are both tactics used to draw information out of the barkeep, but they work in very different ways and their effects are very different depending on the receiver. If, rather than the village barkeep, the players tried to interrogate a defenseless craven, they would presumably have more success.

Thus, the fundamental goal of a social interaction mechanic must be the exchange of information or meaning. Since conversations are almost always for the purpose of exchanging information (knowing how someone is doing, what the weather is like, how to reach a destination...) we can devise a D&D model based on a system where one party tries to encourage another to give information in exchange for other information, essentially bartering what they know - or claim to know - with each other.

For the next few posts, I am going to try to develop this topic with what I call EMs, short for Exchanges of Meaning. Admittedly, there is a whole bunch of research in the topic of human communication which I have yet to embark fully upon, but I intend to move through it as I go and develop the mechanic with it.

Tuesday, September 22, 2015

VBA for D&D

First post since June: I haven't been playing or working on D&D much recently. So it goes.

Today I'll dive into some of the work I have been doing on D&D: working on some VBA functions for Excel. These functions are designed with the goal of simplifying my Excel files which track combatants. Over time, they've gradually gotten more complicated. The last iteration looked something like this:
Rows are combatants; columns are information (including damage taken)
The new version looks more like this:
Columns are combatants; rows are information
Aside from a colour change and flipping the table's axes, I've also added a fair bit of VBA code. Right now, I have code for checking whether a character's class is valid based on their ability scores, code for reducing a character's ability scores based on how far below 0 health they are and code for calculating a character's experience earned. I also have a long VBA-free function for calculating a character's THAC0 against a given combatant.

I'll be posting the code up in my section of the Tao of D&D Wiki, where I am now a moderator. Enjoy!

Tuesday, June 9, 2015

Five Points & Sacrifices

Alexis at the Tao of D&D has recently given DMs some homework:


1.  Name five skills you wish you possessed that would make you a better DM.2.  Name five sacrifices you'd be willing to make to gain any of those skills. 

Few have accepted the challenge it seems: I myself have waited a week since the original post (yay work). Now that I have some free time, I thought it would be a good exercise.

Skill 1:
Provide better exposition & storytelling to my players. I struggle to be clear and concise with my players and make firm choices as to how the story shall progress. When describing a scene, I am erratic: sometimes I remember to add details, other times I lose focus trying to remember what details there should be. When I'm stressed, I tend to miss adding details altogether. Ideally, I'd give the players an appropriate amount of exposition and colour whenever necessary (something I'd need to determine). I would avoid cluttering my exposition with trivialities or giving them information that could distract or confuse them.
Sacrifice 1:
Practice storytelling. I am a terrible storyteller and I often forget details and tell stories non-chronologically. I need to practice for maybe an hour a week, or try the technique Alexis suggests in his comments to Connor Mckay's five points. I also need to commit to my choices. I've done several years of improvisational theatre, and under those circumstances I am very comfortable inventing and creating imaginative stories. As a DM, I tend to clamp up. I want to work on telling stories alone and remind myself to simply be firm on my decisions, even if they play tropes straight or sound unoriginal.

Skill 2:
Keep players more engaged during play. In particular, I'd like to hold my players' attention even when it's not their turn in combat or I'm talking to another player (often, my players tend to splinter off into individual goals and then reconvene session-by-session). I'd like to be able to keep my head above the action and let players know when I will be talking to them and who should prepare their actions.
Sacrifice 2:
I am willing to sacrifice some more time trying an activity which will require me to pay attention to multiple things at once: be it a sport or a job or something else. By spending more time practicing multitasking, I think I can get a better handle on doing so and develop this skill.

Skill 3:
Declutter my organization for the game. Right now I've been moving things over to my computer, and it is very messy. I have PDF copies of books open, browser pages to the Tao of D&D Wikispaces, all my Excel files to run the session, plus OneNote notebooks for recording session details and the campaign journal. Whenever I need to refer to something a little more substantial, like a spell description, the whole game slows right down. I've been trying to push some of the weight of doing so onto the players, but that ends up making me need to ask the players what their spells do which doesn't speed things up nor get me all the correct information.
Sacrifice 3:
Spend some time memorizing and learning more of the rules so I need to keep less open. That would mean giving up time I could spend reading more interesting books to push this stuff into my brain. It might even take some time for me to fix rules that bother me so that I can remember them more clearly (I would remember dedicating the time to change them). I already know that I remember my house rules reasonably well: this would simply be an exercise in learning the rest.

Skill 4:
Be less intense about D&D. My players tend to be new to the game and have school and work to worry about between sessions: they can't commit to strict schedules and D&D just frankly isn't their focus in life. It's a healthy choice that they've made, although one I'm less inclined to make as D&D is my biggest creative outlet when I'm not struggling to practice writing. If the group is less intense, I should cater to their needs and desires as players, so as to avoid pressuring them or intimidating them.
Sacrifice 4:
Let D&D be less important to myself, and give up some of the excitement I get to play. It could make the game feel less special and less meaningful if I let myself be less attached to it, and it would also leave me with time I may struggle at first to fill. But that would give me some time to commit to my other sacrifices.

Skill 5:
Get a chance to be a player and learn from that perspective. Honestly, I've never been a player in an actual game of D&D: I've been a player in a few games of Fate, but that's the extent of it. While I know what I enjoy in other media, I'm not sure what I would enjoy as a D&D player, and that restricts my ability to empathize with my campaign's players. I need to find an opportunity to be a player.
Sacrifice 5:
Quit being a control freak and let someone else take charge. Teach a friend how to DM or go to an event in my area. Accept the possibility of being DMed by someone who may frustrate or bother me, just as much as I may be DMed by someone who inspires me or helps me develop my thinking. Even a bad experience can still teach me about what I want as a player and what to avoid as a DM.

So there are my five. Now to see whether I will actually commit to them.

Thursday, April 30, 2015

Musings on the Weight of a Gelatinous Cube

If a gelatinous cube is 10 cubic feet in volume, then it's 283,168 cubic centimetres in volume.

Assuming a density of 1.3g/cm^3 (density of scientific gelatin), that's 368,118 grams, which is 811 pounds.

For a gelatinous cube to weigh more than 15,000 pounds as Paizo and Forgotten Realms seem to suggest, it would be 6,810,000 grams in weight, which, given the 283,168 cubic centimetres of the cube, would make it have a density of 240g/cm^3 or 240,000kg/m^3.

For reference, that's about thrice as dense as bronze, twice as dense as silver and a good 5000 more kilograms per cubic metre on gold. Tell me, did your silverware ever slip out of your hand like jello?

I mean, I suppose it works if your world has a nice low gravity (that would explain all the giant bugs not being crushed by their own weight)... but seriously, why the hell do you need a 15,000 pound cube? That might as well just be a rock. 811 pounds and density that can actually allow solids to pass is good enough for me.

HUMBLING MATHEMATICAL UPDATE: Maximillian remarked in the comments that the typically understood volume of a gelatinous cube is 1000 cubic feet, given that the cube is 10 feet by 10 feet by 10 feet (you'll notice that the cube root of 10 - the length, width and depth of a 10 cubic foot cube - makes for a somewhat difficult to measure cube). I agree with the logic of his comment (although I'll need more help to see how he got 7,774 lbs). Hence, some adjustments should be made:

The cube is 28,316,847 cubic centimetres in volume (converting 1000 cubic feet to cubic centimetres). With the same density as before, that's 36,811,901 grams or 81,156 pounds. Talk about a big change.

With a volume that large, the 15,000-pound cube also ends up having a density of 0.240g/cm^3 or 240kg/m^3. That's actually a quarter as dense as water. Seems a bit weird still, but a lot less weird than before.

Humorously, if you use Alexis' hit points per die mass system like me, your cube just went from having up to 40 hit points to having up to 120. Scary!

Friday, April 24, 2015

Programming Power Brainstorming

Some good discussion over at Tao of D&D about the use of computers and technology in D&D, especially in our post-videogame era. It's gotten me thinking some more about my own attempts to use my computer to speed up play and make things simpler. This post won't actually put anything concrete forward, just some ideas.

So far, I've mostly kept to using Excel. With the Item Durability app, I have begun my first official foray into Android development, with the intention of eventually having a series of inventory sheets for groups of characters which players can adjust and modify at their leisure. Of course, because it's an Android app it's not as available as Excel, which leads me to start considering my other programming options more seriously.

Right now, I am starting a summer job where I will be using XML and Python for some scripting on the web. It's mostly basic backend stuff but it makes me realize the value of these tools as they are fairly universal and beautifully simple to use (Python is so magical straightforward compared to, say, C - albeit because it hides a lot of C's ugliness).

Some ideas:

Movement
Get a GUI of hexes going, create a bunch of labels to represent characters and then move people around on a hex-map. Can be done over the internet to allow real-time updating by players.
- would require some more investigation of GUIs
- I can already make a hex map background (it's really just a fancy 2D array)
- Internet stuff I'd have to just steal what I know from C (which at this point restricts me to console I/O, but hopefully I could snag a domain for this at some point)

Climate
Obviously a major point for any "realistic" adventure in the outdoors. It would be great to have something I can just print the current climate from with a quick shell command, specifying the location and the date.
- seems doable, although I'd either need a big database or a kickass way to download stuff from the web
- if I follow the second option, I can "mask" locations by assigning real-life locations to fantasy ones (what I already do for my world's weather)
- alternatively, I could try to set up a full-on system (dun dun DUN)

Economy
Definitely another big project involving getting access to items controlled by trade routes and such. Would probably pillage the basic concept from my old economic system (itself pillaged from Tao of D&D) and essentially just do all the math for me (yay automating repetitive tasks!)
- would definitely require some databasing, which I kinda suck at (better learn SQL)

Crawler
It would be lovely to have a way to just gather information for my game off the internet for analysis later. I spend so much damn time opening up Wikipedia articles and scanning through less-than-scholarly articles to get a good sense of what I can use for developing my world. This would be a project to speed that up in a simplistic way. I could probably throw together a BATCH file to do it, honestly. All the same, not much of a priority.

Right now, I am hoping to get durability off the ground, but I think I may start on everything else in various stages. Part of what pisses me off with premade stuff is, with all the licensing that goes on, it's only ever made for one or two particular products, when virtually every single DM is going to use slightly different rules. Anything I end up putting online will definitely need to respect the variety of styles and techniques out there, which is why I would want a comprehensive list of settings that can be turned on or off.

Away we go!

Sunday, April 19, 2015

Back to Durability!

So I have a new and promising durability solution, and of course it was an age-old solution.

The fumble.

As I said in the last post, part of the problem with the system as it stood was that it needed to happen every day and that equipment was breaking as soon as the 1% showed up (in cases where the equipment actually lasted longer than a week).

Though I had remarked on potentially using successive rolls before, I didn't really give it much thought until I was looking over the Tao of D&D's use of break rolls on equipment: on a 1 on your d20 attack roll, the weapon has a chance to break based on its quality: 1d4 for crappy weapons versus 1d20 for "mastercrafted" weapons.

I had been using it for a while, but forgot about it during all the time I hadn't actually sat down and played D&D. My DM brain was getting rusty.

So I decided to incorporate the fumble into some simulations - on a 1 in 20, roll a d100 and compare to the break chance - and boy-howdy did it work. I added one special caveat: if you don't break your weapon when you roll a d100, add the d100 roll to your total stress. I suppose this should maybe be changed logically, as you would expect to want the biggest roll possible, so maybe I'll change it to be add 100 minus the roll if the players can manage it (although I might be able to digitize it out of their way).

The results were very positive: I tested 1000 total resistance, 10000 total resistance, and 20000 total resistance.

Resistance: 1,000
Average # of Days Lasted: 76.76
Standard Deviation # of Days Lasted: 44.66 (min was 2, max was 285!)
Average Break Chance when Item Broke: 37%
Standard Deviation of Break Chance when Item Broke: 0.16%

Resistance: 10,000
Average # of Days Lasted: 240.73
Standard Deviation # of Days Lasted: 121.79 (min was 8, max was 782)
Average Break Chance when Item Broke: 14%
Standard Deviation of Break Chance when Item Broke: 0.07%

Resistance: 20,000
Average # of Days Lasted: 336.57
Standard Deviation # of Days Lasted: 170.57 (min was 30, max was 1123)
Average Break Chance when Item Broke: 10%
Standard Deviation of Break Chance when Item Broke: 0.05%

The standard deviations of days are admittedly a little insane: the data seems really spread out. On the other hand, of the items in the 20,000 bracket, over 60% were within one standard deviation of the average (i.e. between 166 and 507). I can live with that, RNG gods.

The one extra caveat I'll need to add is that 1 on a d20 would work plenty well for weapons, but what about other things, like armour, backpacks, books or bananas?

At this stage, I am considering using a 20 on an ability score roll with an associated item as incurring a break roll (e.g. swinging from a rope), but there's no ability score to eat a banana or wear armour. What does one do?

Well considering what causes wear and tear on equipment - stress from fighting, falling or stretching too far - I could call for a d20 roll in those situations, but that starts feeling like DM fiat when I need to personally adjudicate every kind of scenario, and DM fiat leaves a bad taste in my mouth.

I could have players roll for whatever's on their bodies when they fall below 0 HP, but again circumstances should dictate whether or not a roll is necessary.

I could make each attack hit a semi-randomly determined part of the body and have that item roll its resistance to the blow (1d20, then the 1d100 on a 1). But then there are way too many rolls going on for each attack.

At this point, I am going to implement the complex rule for weapons and keep the break roll limited to situations that call for it. Items will naturally still take daily stress while out in the wilderness, so they'll still break if they ever hit their total resistance.

Now time to implement!