Interpersonal Interaction Map - Beta concept

    I played my first game of Starfinder a few nights ago.  I don't have any deep thoughts about the system, it pretty much felt like playing Pathfinder again.  But one thing did jump out at me.  The party was trying to negotiate with a gangster and things got very complicated.  I'm a veteran role-player, I've been playing RPGs since I was a kid (which was a very long time ago).  But in the party I was the tank, an Android Soldier with a -1 Charisma mod, a racial penalty to Sense Motive checks, and no skill ranks in any interpersonal skills.  I am just in the party to shoot stuff.  Thus, I was sitting back and listening to the negotiations.  The ones talking were two friends who are new role-players, they've been playing with some of my other friends for a few years now, so they aren't totally green.  While I was listening I was struck by how badly the scene was going.  After a few minutes I had to jump in and try to get things on track so that we could wrap up this side quest and get on to the main story.  But what really struck me was not that my new players were having trouble - no, I was really hit by the fact that the game does not give any help to players about how to handle talking to NPCs.  Really, no game I've ever played does a very good job of helping the players with conversations.
    It's taken a few days, but this morning I woke up with a crazy idea: what if I created a map for talking to people?  I have a rough draft that I'd like to share with everybody in case this is a useful tool for someone out there.

The Interpersonal Interaction Map
    Yeah, the name is a work in progress :)   Here is the image file you can print out:

    I want this to be system-neutral, so I'm going to describe how to use this, but you'll have to customize it to your game.
    We start at the top, there are two sections for Incentives and Obstacles.  An Incentive is a reason for the NPC to do whatever it is the PCs want.  Each incentive is rated from +1 to +5.  A +1 incentive is a small reason to help, while a +5 is a very big/ compelling/ forceful reason to help.  Opposing the incentives are Obstacles, which are rated on the same scale but as negative numbers instead of positive.  Now, it's very possible that an NPC will not have any incentives at the start of the conversation - but almost every conversation should have at least one Obstacle, or else why are we bothering to play this out?
    Incentives and Obstacles combine to create the Co-operation Level.  This is a statement about what the NPC is willing to do for (or to) the PCs.  The edges ("Extreme Opposition" and "Total Support") mean that the NPC is willing to engage in behavior with significant risk to themselves for or against the party.  That may mean risking jail or death to help or stop the party (so a fight could break out at that level).  Moving a step inside, the "Active Hindrance" and "Willing Aid" means the NPC will take action for or against the party, but only if there is relatively little risk to themselves.  "Passive Resistance" means the NPC will not help at all, and will attempt to flee the PCs or call for help if possible/ necessary.  "Secret Assistance" means the NPC will help, but only in a way that will not draw attention to them - this could be a tip, or a pointer to someone else to talk to.
    What Co-operation Level the party needs and where they start is something the GM needs to think about when setting up the encounter, of course.

    The NPCs do not start at the level the PCs want, if they did there wouldn't be a need to play this out, so how do the PCs change the Co-operation Level?  Well, they use their skills/ role-playing.  That side of things is covered by the bottom half of the map.
    Rapport and Authority represent the NPCs outlook towards the PCs.  This is kind of the "reaction roll" of D&D/ Pathfinder, but I want to break it into two parts and explicitly give it a measurement.  Rapport is personal, how the NPC feels towards the PCs.  Authority is impersonal, how the NPC views the PCs position, reputation, or connections to other people.  Both are measured as positive or negative numbers.  The exact values are going to depend on your game system - a +1 in Pathfinder is a trivial bonus, it's a little more useful in D&D 5th ed, but it's a big deal in Fate.  So exactly how to measure this you'll need to work out for your rules.
    These can be negative, if the PCs are elves and the NPC hates elves, then Rapport could be a -3.  Likewise if the PCs are police officers, usually that would be a bonus to Authority, but it may be a penalty to some criminals (or 20-year-olds with laptops and authority issues, to quote Nate Ford).  The scores for Rapport and Authority are combined, and they are a modifier to the PCs rolls (or weighed by the GM in diceless or skill-less systems).
    Finally we have the NPC themselves.  While the Incentives and Obstacles talk about the NPC's motivations, weather they want to help or not, the final section of the map talks about the NPC's personality.  There are 6 broad action types, which you should be able to map to your skill system (if you have one), and the PCs need to choose one to roll/ use to change the NPCs mind.  This can take 4 forms.  The PCs can...

• Try to create or increase an Incentive - making a new Incentive should be harder (higher DC), either way you add one point to an Incentive (max is still 5).
• Try to decrease an Obstacle - this removes a point from an Obstacle (min is zero of course).
• Increase Rapport - this adds to Rapport, by an amount that will vary depending on your system.
• Increase Authority - as with Rapport above.

Of course, the PCs need to describe a logical way they can do one of these actions.  Then, they need to choose one of the 6 methods of interaction...

• Threat/ Intimidate - this does not have to be a direct threat of violence, it can be anything that points out how not co-operating will hurt the NPC physically, emotionally, mentally, spiritually or socially.
• Offer/ Entice - with this method the PC is going to offer some reward for co-operation, either directly (like a bribe) or implied (the princess will like you if you save her, and she's rich).
• Prey Upon/ Manipulate - this is an appeal to the NPCs weakness, using an NPCs greed is this method.  The Offer/ Entice is for NPCs who are not signficantly greedy.  This can also be an attempt to prey upon the NPCs fears or sense of duty.
• Reason/ Convince - this is an attempt to calmly and rationally lay out why the NPC should help the PCs.
• Negotiate/ Exchange - while Offer/ Entice is giving something to the NPC, this is a quid-pro-quo exchange (or you scratch my back I'll scratch yours).  It could also be negotiation between other parties (help me and I'll get my friend to help you).
• Flatter/ Promote - this attempts to show how the NPC will be a better person, or be seen as a better person, for helping.

Right now these definitions are works in progress, and the area where I'd appreciate feedback the most.  The idea though is that this method sets the DC or target number for the roll, how hard it's going to be to convince the NPC.  Trying to bribe a loyal and honest guard is pretty hard (even perhaps impossible), but a shady guard might go for it.  A part of the challenge for the players is to assess the NPCs (either through the GM's description or by researching an NPC they know they'll have to interact with) and pick the method that would have the best chance of success.  And then, in skill-based games, the question also becomes how good the players are at those interaction types.
    Also, there may be outside elements that could help a certain method.  For example, if the party has found some blackmail information about the NPC then they should get a bonus to Threat/ Intimidate (or, if they can find a way to give the NPC more of what they want, a bonus to Prey Upon/ Manipulate).
    I would love for the system to track the NPCs future reaction (while a threat may work to elicit co-operation it's going to leave a bad taste in the NPCs mouth and may make a future enemy).  Generally speaking the top row of methods are not going to make the NPC like the PCs much (even giving a bribe just makes you a source of money, not a friend) - while the bottom row is neutral to potentially favorable.  That's up to you about how you want to use any future repercussions or not.

    Finally, along the left side there is a track for the number of failures.  No one wants to talk forever, you only get so many chances to change someone's mind.  I'm currently thinking of tracking that by failures.  As long as the party is succeeding at their rolls I'd figure the conversation is going well.  And giving the group 10 failures is pretty generous - you could say that the NPC is in a bad mood or caught at a bad time and thus starts with 1 or more failures.  Or, you could track it in turns, and give the party a maximum of 10 turns (or fewer) to change the NPCs mind.

Conclusion
    I know this is pretty rough, I have some ideas on how I want to refine the system so you'll see an update to this sooner or later.  This might be way too much detail for some tables, but I think for some groups - in particular new players - having different factors laid out and clear/ easy to see might help them formulate a plan on how to talk to people.  Let me know what you think in the comments below :)

Character Viewer: How To Save User Input - part 2 - From Form to Table

    And I'm back to the Character Viewer tutorial, sorry about the delay (unless you're reading this years later, in which case no time has passed thanks to the magic of the internet).  We started by writing data we had hand-coded to a table, nice but useless.  Last post we added a form to collect the character data from the user, also nice but useless.  Now we're going to make this actually useful and take the data from the form and add it to our table.  Well, as useful as it is to have a very limited character summery - hmm... we'll have to add some more to this project.  Later.  We've got enough work for today :)


Measure Twice and Cut Once
    That's old carpenter's advise, but it applies to most everything.  A good plan will keep things from going off the rails, and looking ahead lets you avoid problems instead of fixing them.  So let's look at what we need to do before we start coding.  I'm going to need a new function that takes the data from the form, formats it, and then calls the existing function to write it to the table.  So I'm going to add that function and fill it with some comments about the things I need it to do...

Now, I might have missed some steps, we'll see as we go along, but this is enough of an outline to get me pointed in the right direction.
    So let's set the foundation.  First, I'm going to use the same function from the first post to iterate over the character object's properties and populate the table - so I need a blank object with the same properties...

I'm going to pass that object to the function to write it, so let me add that too...

And at the moment I can't actually run the function because it isn't tied to anything.  So let me add an onClick to the button I put on the form.  I can do this in two ways.  I can create an event listener in JavaScript or I can add it to the element in HTML.  Under the Model-View-Controller paradigm I should keep it in JavaScript, where the "controller" stuff happens that makes the program run.  But I actually like adding it to the HTML of the button itself, so when I look at the button I know what it's supposed to do.  Neither is really wrong as far as the browser's concerned, it's a matter of style.  Since the button is the only event handler I need, I'm going HTML.  If I was using something like jQuery UI where I had to initialize a ton of elements I'd do it in JavaScript to keep things together.  Anyways, here's the HTML attribute to fire the function when the button is clicked...

Okay, that sets up the framework, one blank object ready to be filled, a call to the function to display it, and a handler for the button to launch it.  Now we just need to start getting some data.


Do You Want To Do This The Easy Way Or The Hard Way?
    Let's start with the easy way.  Some of our form data is going to need to be processed, so let's grab something that we can directly display - the HP total.  The user is going to put in a number and we're going to directly copy that to the table, so it's a easy place to start.  Or is it?
    In order to get the data from the form we have to tell JavaScript where that data is.  Which turns out to be more complicated that one might expect.  There are actually a couple of ways to do this simple little thing.  Let's go from most complicated to least (the latter being the one we want to actually use).
    Like all things computer-related JavaScript has grown and developed over several versions.  The last big version, or ECMAScript was ES5.  In that version there are two main ways to select an HTML element, by Id or Class.  There are two different functions for each.  In this way to select an element we'd type:

document.getElementById("id")
or
document.getElementByClassName("class")

    ES6, the latest version of JavaScript consolidated those into just one function:

document.querySelector("#id") or document.querySelector(".class")

     The ES6 method isn't bad, but it also isn't great.  It's kind of long, 26 characters without the selector.  And we have about 14 form elements we need to look at.  The easiest way is to create an alias, to define a function that's shorter to type and make it the same as the longer function.  That's what something like jQuery does.  In a simplified version (very, very simplified) jQuery does this:

function $ (selector) {
    document.querySelector (selector);
};

which means you can type $("#id") instead of document.querySelector("#id"), which is 25 characters less typing.  25 characters may not seem like a lot, but when you make a few hundred selections that comes out to a short story's worth of saved code.  And we could do the same thing jQuery does.  But we won't.  Honestly, if I'm going to do something jQuery-like then I might as well just use jQuery instead of reinventing the wheel (and a poor version at that).  So for this tutorial I'm going to stick with the ES6 syntax and just copy-and-paste the code I need.  14 elements isn't a big deal, and if I decide to bulk up this app and add a bunch of features I'll just use jQuery and we'll have a tutorial about that :)  So, now that we know how to select something let's do it.
    Because our target is a textbox we need to select it, and then get it's "value" property.  Then we're going to save that to a variable and write it to our object.  Here's the code...

    And here's what it looks like when we run it...

 Woo Hoo!!!  We just took user-input and wrote it to our form, high-fives!  Okay, I'm way too happy about something so trivial :)  Now that we got the easy part done, it's time to get more complicated.


Formatting The Attributes
    This part is going to be ugly.  The next hardest, in a very general sense, are the attributes.  The attribute scores themselves are easy, we're going to take them from the form and input them directly to the table.  It's the modifiers that are tricky.  We decided (well, I decided and you got dragged along for the ride) to have the user only input the score and let JavaScript calculate the modifier.  This is good because it prevents the player from messing up the modifier, people are human and and make mistakes, so things like this - just looking up data on a table - are good candidates for leaving to the computer.  It was also a kind of dumb decision because it means adding more work for us with questionable reward.  But this is a tutorial, so it gives us something to learn (and if I do develop this further it's likely something I'll change).
    Our task then is three-fold, we need get the value and then use that to get the modifier, both of which get saved to the character object.  Getting the value we've got, like with HP, we're going to look up the value and save it to a variable.  To calculate the modifier we're going to write a new function that will apply the correct formula and return the modifier.  Let's write that function now.  So what is the formula for an attribute modifier in Pathfinder?  It's the ability score minus 10, divided by 2 and rounded down.  We save that and return that variable, which makes our helper function look like this...

 Cool, we can calculate the modifier.  Now comes the really tricky part.  Our function to write the character object is really easy, it just iterates through the object and writes each property.  Which means we have 6 properties for the attributes all of which are going to do the exact same thing, take a score, calculate the modifier, then make a string with both.  So let's expand out helper function to do all of that, it'll cut down on the duplicate code.  Or final function is going to look like this...

We have to call it 6 times, once for each attribute, because the way the form is set up we can't easily iterate through it.  Okay, let me correct that.  I know some ways to iterate through it, and how I could change it, but I don't know the best way.  I'll look at changing this section after I've done some more research.  For now, while this is not the ideal method, it isn't that terrible, so we'll go this way...

Which now looks like this when we create a character...

Woo Hoo again!  That's a good chunk of our character done.  Three more table cells to go.


Name, Social Security Number and Date of Birth, Please
    Okay, let's get the name section done.  There are 4 things we need: the name textbox, the race drop-down box, the classes (which are checkboxes and there can be more than one checked), and the character's level number box.  Three of those things are easy :)
    Let's grab the easy variables, with this code...

    Which leaves the trickier part of checking the checkboxes.  And I discovered something, when I wrote the HTML code for the checkboxes I didn't give them any Id's to be able to target them later.  Ooops... so here's the fix to that...

And then I just need to query each checkbox and see if it's checked.  If it is I'll add it to the string I'm going to display, which makes the function this...

With the final app looking like this...

En garde
    That leaves just two more cells, the ones for the weapons and armor.  Let's handle the weapons first.  So we have three weapons, and they are on radio buttons so the player can only choose one.  We need to get which one the player selects first.  The weapon will give us the name and damage.  Then we need to check the Base Attack Bonus field and add the appropriate attribute modifier to get the final part, the to-hit bonus.  Those three strings get concatenated, or added together, to give us the table cell.
    Or at least, that's how it should work.
    There's just one little problem, our character object isn't formatted that way.  When I first wrote this app I was looking for something simple, an easy way to write the data to the page.  So each attribute is just a string, with both the score and the modifier together.  And now that's a problem since I want to deal with those values separately.  I could just take the score and calculate the modifier again, but the function I used to do that is the one that also returns the complete string.  I did not structure these functions properly to fill in these last cells.
    Now, I try with these tutorials to show things that work.  I've written a few versions of the code so far and they didn't turn out right, so I omitted them.  I want these to be learning experiences, not full of things you shouldn't do.  I'm leaving this mistake in though because it does go back to the beginning of this post, that part where I was outlining what I needed to do.  During that step I really should have looked closer at how to structure my data, what different pieces I was going to use.  I didn't and now I'm in a bit of a fix.  It's important to have a good plan, to be able to see what you're doing in your head.  Even still you'll make mistakes, that's just how it works, but a good plan means fewer mistakes.
    So how do I fix this?
    I'll give you a minute, if this was your program what would you do?..........
    .....
    'K, time's up.  I can see two options.  The good one is to re-write the character object, so that I could use the modifiers in other ways down the road.  That, however, would mean re-writing the function to put that data on the page.  That's a lot of re-writing.  So option two is easier, and what I'm going to do.  I'm going to take the function I called to make the attributes and split it.  I'll leave the part that makes the final string, I'm just moving the part that calculates the modifier into it's own function.  That makes the least changes to the attributes code.  Then, for the weapons and armor I can just call the function to make the modifier and use that.  It'll basically double those calculations - but it's not like that'll matter in such a small program.  It's not an elegant solution, but it's the least re-coding.  Honestly this whole thing was a mistake from the beginning.  My function to write the object directly to the table is simple, but it's also way, way too simple for something as complicated as a Pathfinder character.  If this was a real app, meant to be useful and not a learning tool, I should have used a totally different design.  But I didn't, so we'll go with what we've got and get this done.
     That means that this is the revised code for the attributes function and the new modifier function:

     Moving on from that glitch, now we need to get the selected weapon.  And again there's another problem, just like with the checkboxes I didn't give each button an Id to reference it by.  Ohmygosh, and the armor radio buttons are the same way of course.  So let me fix all that...

Just like with the checkboxes we're basically going to do a bunch of if/then statements on each button.  There is a better way to iterate through the form, again though this is a small and limited app so I'm not going to worry about that right now.  This gets kind of complicated, so let me break it down step by step.
    First, I'm going to use the parseInt() function and get the Base Attack Bonus.  Even though this is listed as a number field in HTML I want to make sure JavaScript treats it as a number.
    I'm then going to check with some if/then blocks what radio button is checked.
    Another parseInt() on the function to find the correct attribute modifier gives us the other half of the to-hit modifier, and the damage modifier (except for the bow, which doesn't add any attribute for damage, only to-hit).
    Then we check if the To-hit modifier is 0 or higher, if it is I'm adding a "+" in front of the number; if it's negative there is no "+" of course.
    Lastly the same 0 or higher check for the damage modifier, for formatting purposes, and then the string is assigned to the character object.
    It's a lot of code for something so simple, here's the unarmed code block (for brevity's sake):

I missed the screenshot of the table, oh well, we're almost done so you can see the final version soon :)


Hide Behind The Pile Of Dead Bards!
     Ohmygoodness... we're almost done.  Yeah, this is a way too complicated "tutorial" for a fairly simple concept.  I know I haven't been the greatest teacher so far, and I'm sorry about that.  I'm learning myself.  But this is it, one last section and we'll be done.
    So armor is a lot like weapons.  First we need to figure out which one is selected.  Then, instead of getting a BAB score, each type of armor is going to have its own armor class modifier.  Then we just add different modifiers to the base armor class to get the "touch" and "flat-footed" armor classes.  So, like weapons this is going to take a fair amount of code to work out.
    Let's examine the individual components before we start madly coding.  There are three things that make a character's AC.  First there is the base AC that everybody gets, a 10.  This is the universal "naked man" AC.  Then there is the armor's modifier.  This is easy, each type has it's own mod (with "none" or no armor being a 0) - but, the catch is that you add your armor mod to your "full" or default AC and to your flat-footed AC, but not to your touch AC.  Last is the character's Dex modifier, again easy, but while you add it to the full AC and touch AC, it is capped depending on the type of armor, and it isn't added to the flat-footed AC.
    So first I'm going to determine what type of armor the character is wearing.  That will let me get the Armor AC modifier, the name of the armor for the final string, and then I can get the Dex mod and do an if/then block to make sure it isn't above the max dex for that type of armor.  Here's the code:

Then I can finish by adding the right things together, forming them into the string and writing the final string to the character object.  Here's that code:

And here are what a few finished characters look like:

   Great goodness, that took a very long time.  Well, for me at least - you're lucky you can just read the end results.  So at last we have looked at how to get data from a form and write it to an HTML table.  Is this app very useful?  Well, I guess it might be in a limited way.  If you changed everything to textboxes you could easily let people write their own stuff, and that would cut out a lot of the programming headaches, and it might actually be a somewhat useful app.  I will leave that to the reader if you want to try it :)  Here is the link to my Google Drive with the code.
    This little project spiraled out of control into something of a trainwreck, but hopefully it was a learning experience - it was for me :)  Who knows, maybe it would be worth it to play with this some more and turn it into some kind of character creation utility... hmmm.... we'll see.  For now I am going to sign off and go get that breakfast I'm 8 hours overdue for.  Until next time!

The Elemental Empire - part 7 - I Don't Really Like Setting Books (so why am I writing one?)

    I have rarely run games from a module and I don't like reading most setting books.
    This could be a problem now that I'm writing a setting of my own :)
   
    I've always liked creating my own worlds.  Once I started playing RPGs I discovered I also like tearing apart games and seeing how they work.  I've mostly been the improv guy.  You know the one, the guy you turn to when everyone wants to play but nobody knows what.  I can't count how many adventures I've created while my players were creating characters.  And I've got boxes of notebooks of game ideas and house rules.  Most modules never really interested me.  Most settings for that matter.  Honestly I can only think of a few games where I've liked reading the setting material: Shadowrun, Exaulted and Earthdawn.  I can remember reading all of those books and seeing story potential in my head, little bits and pieces that inspired me with adventure and campaign ideas.  I loved Shadowrun for it's density in brevity- the rulebooks (3rd/ 4th ed I think, I haven't read the latest) had great section at the beginning that introduced the world just right.  These sections were detailed, but not too detailed, they hit a sweet spot of saying a lot in the fewest words.  Exaulted I read several books about, each major faction had it's own book - and I loved all the different kinds of stories they presented.  With a neat fantasy-inspired-by-anime setting I could see so many different campaigns that you could run out of the same world.  Earthdawn was like Shadowrun (maybe 'cause they were by the same company) in saying a lot with little, but I also love how they created their own magic system, and presented it in fantastic detail.  But the best RPG book I've ever read was an Earthdawn supplement, The Adept's Way.  This was basically a class guide, each chapter was one class from the game.  The magic of it (to me at least) was how it was written as if one of the characters was talking to the player.  It was like a member of this class was telling you how to play that class.  I loved that style, how it drew you right into the world and the shoes of a member of your class.  I have never read another book that did that, and I'm sad because I thought it was the best style of writing a player's guide.
    The biggest problem I've had with setting books/ material is usability.  The World of Darkness books used to have a short story at the beginning of each chapter.  And that's cool and all, but what am I supposed to do with it?  If the story isn't in the same style as the adventures I'm running, then it's not really helpful.  Same with the story as a tool of building the setting, if I am making the same sort of campaign as your story then cool, but if not then I don't really get anything out of that story.  On the flip side, a breakdown of the percentage of every race living in a city is the kind of detail that makes my eyes glaze over.  Again, when I create the census campaign (in a fit of madness) then I might care about such minutia, but in the game all I need to know is if one race is dominate or if there is a good mix of races.  And are any races in conflict?  Knowing there are 80% Dwarves and 20% Elves is kind of useless ("mostly Dwarves" would have said the same thing without the scary math) (I'm easily scared) - but knowing that the Dwarves drove the Elves out of the community several generations ago and recently the Elves have tried to re-open ties to heal the old feuds; that's useful.  Now I know that this town is a good place to set a story of racial tension.
    That's the thing about a setting, I'm not reading it for my own entertainment, I'm reading it to figure out where to put my players for the story I want to tell.  Or, I'm reading it to figure out what kinds of stories I can tell.  I don't want the game material to entertain me, because of Paranoia.  I love the Paranoia RPG, more than I have words for - I think I ran it once.  I don't love it to play it, I love it to read the books and adventures.  This is a hilarious game, reading anything for the system (the old 2nd ed at least) was like reading a comedy novel.  I don't really care if I ever run it for actual players, because reading it was likely more entertaining than the players would ever be.  It's a terrible system because it's so much fun to read the books that actually running the game is a bit of a let-down.

    Okay, so I have a wee bit o' problem with writing my own game world given that I don't really like reading them.  This is going to be a tricky situation.  So what kind of guide do I want to write?  What is this setting for?  Well, I want this setting to be a tool, not a straitjacket.  I want to create a world, of course, but I also want to leave enough wiggle room to let each GM customize the setting to their group.  The kinds of stories I like are not going to be liked by everybody.  So I want to make something, well no, I want to make a core for storytelling.  I want to make the skeleton of a world, and help the GM with deciding where to build off of and change the world to fit their own group.  Most setting material I've read is like a story, it's there telling it's own tale.  I think instead I want to write 2 books, or two types of books, the GM books and the PC books.  Both are going to have the same style, talking directly to the audience, but there are going to talk in the same way as the group they're written for.  Argh... let me try to clarify what I'm thinking.  As a GM I don't want a collection of stories and statistics.  Their stories are not my stories, so they don't help.  The statistics are minutia, tiny details that don't matter without a story in the first place.  So for my GM books I am going to write GM to GM.  I'm going to write as me, The d100 Mechanic and creator of this setting, and I'm going to talk directly to the GMs out there about how the setting is structured and what they can do with it.  But for the PC books, I'm going to write like The Adept's Way, I'm going to talk to the PCs as if I was a member of this setting, teaching or telling them about the world.  Because while the GM needs the Lego-pieces of the world to create, the PCs need to be able to put themselves in the world and feel it as if they lived there.  So I think I need two different styles of writing, because I think both groups have different needs.
    Which brings up another problem, the minutia.  I started the crazy idea of writing my own setting because I wanted to work on my own game - and I think every game needs a setting.  But while I'm currently working on something based off the 5e SRD, I don't want to lock my setting into that rule-set.  So when it comes to the details things are going to get difficult.  I may need a third set of books with specific numbers for each of the games I want this to be compatible with.

    Okay, so that's the groundwork of what I'm thinking, the way I'm looking at writing this setting.  Now comes the big question- does this sound good to any of you?  I think this sort of layout would be useful, but does anyone else?  I know it's hard to form an opinion off such vague musings, and I'm working on actually writing something, but just from first impressions does it sound good?  Of is there another style you'd prefer?  Let me know in the comments below, please!

The Last Jedi shows a key thing about Rules Lite/ OSR play (no spoilers)

    I saw The Last Jedi over the weekend.  I have a lot of thoughts about the movie (and Star Wars in general), but the firestorm the movie ignited among the fans actually illustrated something about role-playing games.  So I can rant about Star Wars and sci-fi in movies if you really want me too, but for this post I'm talking RPG stuff.  I'm also going to avoid spoilers, I can actually make my point with a single scene from the beginning of the movie that is not key to the plot (the parts I'm going to describe at least).

    Okay, let's start with the scene as you see it in the movie.  There is a really big bad guy spaceship the good guys attack.  At first we see the usual X-Wings of the series, but then we see a new type of spaceship.  I don't know what they're called (don't remember it if the movie said it), but basically they are bombers.  They carry dozens of black spheres that they drop (as far as we can see) on the big bad guy ship and blow it up.  That's the scene.  Simple, right?

    Boy did that spark the flamewar, so to speak.  Every reviewer I've seen who describes it has asked the same thing: how do you drop bombs in space?  There is no gravity.  Yes, they are near a planet, but they are far away and there would only be micro-gravity, not enough to move the bombs very fast.  A few people claimed that the bombs were propelled by some kind of magnet-thingies.  That claim is false however - the movie does not show it.  A movie is a visual medium, it must show what is happening.  Some book written later cannot explain the movie, the movie must stand on its own and be judged on it's own.  It does not show the bombs being driven by anything other than gravity and no one even says (which is worse than showing, but at least would be in the movie) that the bombs are driven by anything other than gravity.  Everyone who blew up over this has a point, from what we know about physics that shouldn't work.  So the critics are right to criticize this decision.

    Thing is, the critics are also wrong.
   
    Something that people forget about Star Wars is that it is not a science fiction story.  Nope, sorry if that burst a bubble but it's the truth.  Star Wars is a fantasy story, it's all about magic and morality and not technology and society (which sci-fi is about, at heart).  The space combat from the first movie (A New Hope) was directly lifted from news footage of World War 2 airplanes.  Somewhere I once saw a video of WW2 black and white footage next to the Death Star attack, and they are almost shot for shot identical.  Lucas liked the WW2 dogfights and he created his space combat to look like that.  He did not create it to be physically accurate.  You want to see accurate space combat from what we know of engineering and physics?  Go watch Babylon 5 and the Star Furies.  That's physics.  That's science fiction.  Star Wars is fantasy.
    So, that bomber scene people are complaining about, it is totally correct and belongs in the movie.  It is exactly like the World War 2 bombers and screening fighters.  It is exactly what Star Wars was built on, from literally the first movie.  So the critics are wrong to criticize it.


    Okay, on to my role-playing point.  I grew up with early D&D, what the hip kids now call "old school" play (impetus for the OSR or 'old school renaissance').  I don't really like that kind of game though, I like more mechanics-heavy rules.  And I like them exactly because of what I've been watching in The Last Jedi reviews.  A mechanically-heavy system tries to define as many things as possible.  Doing this has that effect and needs that roll.  A "rules light" system relies on negotiation between the GM and the players.  Anything is possible in a rules light system, if we can agree that it should be possible.  That is the thing driving The Last Jedi hate towards this scene (and a lot of other things, but again I'm avoiding spoilers) - a difference in assumptions.  The haters of this scene assume there is gravity and physics and such - but the movie assumes it is WW2 in space.  Both are right, that's the thing about assumptions, they are not objective facts.  The Star Wars writers and creators are operating from their assumptions, as they are right to do.  And the haters are operating off their assumptions, as they too are right to do.  The trouble is that those assumptions don't align.  All this hatred (let the hate flow through you... sorry, couldn't resist any longer) is because of differing assumptions.
    And that, in my experience from playing old school games (back when they were just the only games around), is the dangerous thing to be mindful of when playing "rules light" games.  Assumptions become a lot more important, and you need the interpersonal skills to handle conflict resolution when assumptions conflict - because they will, sooner or later.  Hopefully your group all think along similar lines so the disagreements will be few and minor.  But maybe not.  Actually, hopefully the group has had a talk about assumptions and what they expect to be able to do or how the game world works.  Which is another reason I don't like games that ship without settings.  Having a description of the world and how that world works can get everyone's assumptions on the same page (or at least in the same chapter) and prevent conflicts before they happen.

    Not going to be a deep article, just something that struck me.  Be mindful of your assumptions in your games, "rules light" systems live or die by this, but all games have assumptions to some degree.  Talk about them with the other players and GM, not just assumptions about how the world works like magic and physics, but about how the story is going to go and how the characters should behave (some groups will like a player betraying the party for drama, some will flip out - you need to know which you're playing in before you do something like that).  Assumptions are inevitable, but the more we talk about them and work together, smoothing out conflicts instead of blowing up, the better our games will be.  At least, that's how it's been in my experience.  If your is different, leave a comment below, I love having my assumptions challenged !  :)  (not really of course, nobody sane likes that kind of thing, just knows it's necessary)

Happy New -cough cough- Year ! And Post #100

    So I ended up getting a cold yesterday, hit me very suddenly.  Got next to no sleep last night.  And not only is it the new year, but adding my 98 published posts to the 3 posts I've written for Patrons means I've hit 100 posts (yeah, the first ever post was a stupid "hello, world" and so it doesn't count).
    2017 was a bad year for me, in fact it flat-out sucked.  The only two good things that happened in my life at all was the time I spent with friends and writing this blog.  While a lot of disasters, external and internal, kept me from hitting the post-a-day schedule I'd really, really like to maintain; I do enjoy writing and sharing things.  For the first time in my life I'm on Twitter, and I've found a lot of great people to follow and gotten some sage advise and chuckles in the process.  Thank you internet for being entertainment and letting me carve out my own little home in you.
    2018 is going to be more of the same.  No promises on scheduling, I'm still in the middle of a few crisis, but I will write as regularly as I can - and try hard to make it stuff worth reading, I value your time and mine.  And I hope your year is off to a good start and contains many wonderful surprises down the road!