Murder-Hobo Control - Looted Equipment

What is a "Murder Hobo"?

It is a trope seen in pretty much every RPG, be it table-top or electronic. In a nutshell, it's the "kill them and take their stuff" mentality. Players tend to start seeing the world in dollar (or gold, crown, credit, insert currency here) signs. Just laid low a group of bandits? Strip 'em bare and sell the stuff later on down the road. Enemies become a lucrative business for the players, whether it makes thematic sense or not.

Is it really a problem that needs addressing?

That depends largely on you as a GM and on your players. Murder-hoboing is often seen as breaking immersion, or otherwise acting contrary to the accepted conceit of the game. Take standard fantasy - how do you reconcile a Paladin with what amounts to desecration of corpses for monetary gain? If things like that don't bother you or your players, then game on. There's absolutely nothing wrong with that, but this post isn't really geared towards you.

The Road So Far

I've gone through many, many iterations of this - each time refining it to be closer and closer to the motto of Savage Worlds: Fast, Furious, Fun. I did not want to slow the game down in search of greater verisimilitude, but at the same time I didn't want to constantly be making on the fly determinations of what players are actually able to acquire.

The Beginning

At the core, I wanted to use Savage Rifts' Technical Difficulties setting rule. It's an easy way to represent various levels of quality for similar gear. I'd love to take credit for the idea, but I actually saw it on the Savage Rifts Facebook group. Each level of Technical Difficulty adds a penalty (-1, -2, -4), a repair time, and a repair cost (0%, 20%, or 40% of book value).

Initially, I had players roll on the Technical Difficulties table for any item they wanted to pick up from a body.

I also wanted to incorporate the idea that a thug blasted by a Glitter Boy is not going to have nearly as functional equipment as the thug with a laser hole through the head. I called this Overkill.

This originally manifested as adding to the Technical Difficulty roll based on wounds past incapacitation. Then, because I really didn't understand the concept of "Fast, Furious, Fun", I decided that if the total was 7 or higher (off the table), the player would draw a card per point over. So, say they rolled a 5 with 3 points of Overkill - a total of 8. They'd draw two cards. If it was a 2, 3, or 4 of Clubs, the item was destroyed.

Yeah, I know, even I shudder when I think of that convoluted mess.

Iteration - Improvement!

Then, I settled on a more streamlined mechanic - do away with the roll altogether, and just draw a card. Starting with Spades, if it was a face card or a non-face card of a previous suite (2 of Spades through 10 of Spades OR J of Hearts to A of Hearts, for example), it was, in order, No Effect, Glitch, Serious Problem, Severe Failure, or Destroyed.

For Overkill, I changed from every wound over to every other wound over incapacitation causing a point of Overkill. Rather than add to a roll, however, it simply shifted the results to a worse effect. Severe Failure became Destroyed, Serious Problem became Severe Failure, etc.

A buddy of mine then made the suggestion to have Overkill draw extra cards, but pick the worst. This made for an interesting mechanic where bennies could be used to remove low cards, potentially drastically improving the results.

As you can probably notice, still a bit of clunk to it. If I draw a 10 of Hearts, is that a Glitch or a Serious Problem? Dangit, time to check the chart again. As for the Overkill change suggested by my friend, while interesting, would ultimately slow the game to a crawl. Got ten extras with at least armor and a weapon? That's twenty draws before Overkill is brought in. Granted, for something like that I'd probably abstract it to a draw per item type (all of one type of armor on one draw, all of one type of pistol on another draw, etc), but still - clunky.

Sweet Compromise

The current rendition is a simple card draw per item. On a Spade, it's fine (No Effect). On a Heart, it has a Glitch. And so on.

Overkill is still 1 point per 2 wounds past Incapacitation, but it has returned to moving the effect down one level. It is also an Optional rule as it does require more record keeping.

Jokers are always No Effect, regardless of Overkill, and Spades can never be reduced past a Severe Failure. I toyed with this for a while, but decided that there should always be a chance of recovering the item, albeit in about the worst condition possible.

Once the result is known, after the effects of Overkill have been applied, a player may spend a bennie to move the result back up by one.

Even if there's been 25 points of Overkill (50 wounds over Incapacitation), a Spade will always be a Severe Failure, a Joker will always be No Effect. If any other card is drawn, the item is Destroyed unless a player spends a bennie, in which case it now has an Severe Failure.

The Ubiquitous Example

Noble the Glitter Boy pilot blasts a Coalition Grunt with his Boom Gun. Let's say that he did average damage, 32. The Grunt gets no armor due to the AP 25 of the Boom Gun, which leaves him with a Toughness of 7. That leaves 25 damage, which resolves to six wounds. The 1st Incapacitates the Grunt, leaving five wounds over.

The Grunt has on armor, a rifle, and a pistol. Noble draws a card for each: 10D, 6S, and 10C.

If we don't use the Overkill rules, then we're done - the armor has a Serious Problem (-2, 20% value to fix), the rifle is fine, and the pistol has a Severe Failure (-4, 40% value to fix).

If we do use the Overkill rules, then those five unresolved wounds become two Overkill points - the armor is now Destroyed (Serious Problem =1=> Severe Failure =2=> Destroyed), the rifle acquires a Serious Problem (Fine =1=> Glitch =2=> Serious Problem), and the pistol is destroyed (Severe Failure =1=> Destroyed =2=> Destroyed).

Noble would've liked to have recovered the armor, as it is worth the most, but it's also hard to offload due to the obvious Coalition markings. He knows a guy, though, who could do it. So, he spends a bennie and brings the armor from Destroyed to Severe Failure.
It won't be worth nearly as much, but he should be able to get about 2250 credits for it. If he can scrounge up 18000 credits in parts (unlikely as he's hurting for credits), he can repair it and sell it for 22500, getting 4500 back in profit.

R.chi.3

What now?

R.chi.3 is my current project for Savage Rifts. At its core it is simply a random table generator for missions, ley lines, rifts, etc.

Why R.chi.3? If you're a Rifts fan ... think about it for a minute.

For the rest of you, one of the major players in the game setting is an AI from before the Cataclysm named A.R.C.H.I.E 3, often loosing the acronym status and simply going by Archie 3.

The apps name is a play on this and is pronounced the same way. The use of the 3 at the end is both as an e for Archie and a 3 for the full name. No, I'm not terribly creative.

Obstacles

The actual generation part is fairly straight forward. I could hard code the entire process, but that's not how I want to hand things. My desire to make the application extensible, allowing for new results and options to be added as needed or desired with as little fuss as possible.

To that end, there are two major obstacles that I've identified:

A responsive GUI

GUI has traditionally been a weak point of mine. I don't find the same joy solving GUI problems as I do more traditional programming issues, and I often feel like it takes away from "real" development. 

In addition, any UI I design needs to be able to be viewed across multiple devices without negatively impacting the look and feel of the application.

Because of the above, I've decided to start with a web-based service as I feel that's about as cross-platform as I can get. In addition, there's several UI centered libraries for Javascript to make my life easier - I can just lay out the application in HTML, assign classes, and CSS / libraries do the rest.

Now I just need to learn how to use said libraries

Data loading and formatting

In order to make the application as modular as possible, I want to make all of the data be separate from the application. For a web-facing app, this generally means some form of XML or JSON files.

I've already decided to go with JSON given the platform, but the real task is figuring out the paradigm I want to use for organizing both the files and their contents.

Progress

I know in broad terms how I want to approach the actual task of generating results, but I'm not 100% sure on the specifics. Part of the design of the back-end will be driven by the design of the front-end (I know, it shouldn't, but here we are), but other than that I have some thinking to do.

In the mean time, my efforts have been mostly in wrestling with the UI and making sure it's responsive. Here's what I've managed to work out for the main generators page:

Viewed on a standard monitor

Viewed on an iPhone 6

Each content area (the white areas under the grey headers) are collapsible, allowing the user to hide areas not in use to regain viewing area as needed or desired. 

The biggest triumph (for me, anyway) was getting the tabs to convert to an accordion on smaller form factors. I wish I could take credit for it, but that goes to github contributor flatlogic: https://github.com/flatlogic/bootstrap-tabcollapse. All of my effort was spent finding his work (spent most of last night playing around with various solutions before I came across his) and subsequently getting it to work.

Summary

Overall I'm happy with how the UI is breaking down. The next step is to start working on fleshing out the actual layout, and then adding functionality.

Unfortunately, I'm helping a friend move this weekend, and the trip there and back is going to be a total of 12 hours. Odds are good I won't have a chance to work on this much more until Monday.

[Savage Rifts] Particle Beam Weapons and Crew Served Options

Introduction

As expressed, however briefly, in a previous post, I am unsatisfied with how particle beam weapons work in Savage Rifts. They just increase the die type by one and leave it at that. From what I recall of the Rifts universe, particle beams were the energy weapon king of anti-armor warfare - or at least that was the intent. Palladium's stats tended to vary based on who was writing the book, so I can't really go off of them.

In any case, I've set out to standardize how particle beams function and bring them in-line with my own expectations.

In addition, I want to see heavy weapons viable as a crew served weapon and not require a robot, PA, or vehicle to hook up to. The second part of this post address that aspect.

So, without further ado, here we go.

Particle Beam Weapons

The premier energy anti-armor technology, particle beams are expensive compared to other forms of energy weapons and harder to maintain. All particle beam weapons suffer from Technical Difficulties. Remember, as well, that any weapon with a Mods value requires a Strength of d12+Mods to wield effectively as a personal firearm.

General rule of thumb for creating a particle beam weapon: take a comparable laser, reduce the range to 2/3 of the laser's. Increase the damage die type by one. Add +2 AP for personal weapons, +5 AP for heavy / vehicle weapons. Add +1 to the Mods value for heavy / vehicle weapons. Double the cost. Reduce shot count to 3/4 of the laser's (for personal weapons).

This gives the following profiles for Vehicle / Heavy particle beams

Vehicle Particle Beam Weapons

Weapon	Range	Damage	RoF	AP	Shots	Mods	Cost
Light	100/200/400	2d12	1	10	Special	3	900,000
Medium	100/200/400	3d12	1	15	Special	4	2,000,000
Heavy	100/200/400	4d12	1	20	Special	5	4,800,000

Notice the special under shots? That's where the second part of my introduction comes in ...

Energy Cells / Canisters

Sometimes you need a big gun, but you need it in the field with the grunts and not strapped to a lumbering behemoth. Problem is, those big guns need energy, and they're usually tied into the on-board power supply of said behemoth.

The solution are Energy Cells, although different manufacturers call them different things. Each cell has energy equal to its rating times 12. A weapon uses energy equal to its max damage, so a d12 uses 12 energy. 2d12 uses 24 energy, etc.

For example, an EC10 contains 120 power. That means that each shot of a Light Vehicle Particle Beam consumes 24 energy from the EC10, giving the weapon a realistic shot capacity of 5.

Energy Cell Costs

As can be imagined, Energy Cells are not cheap as they're handling a draw usually handled by fusion reactor. The cost to recharge a cell is the BASE number of shots unit rating (10, 20, etc) * 1000 credits, with a new unit costing 5 times the recharge cost.

Here's a table with all the math figured for EC10 up to EC80

Energy Cells

Cell	Energy	Weight	Recharge	New
EC10	120	5	10000	50000
EC20	240	10	20000	100000
EC30	360	15	30000	150000
EC40	480	20	40000	200000
EC50	600	25	50000	250000
EC60	720	30	60000	300000
EC70	840	35	70000	350000
EC80	960	40	80000	400000

Examples

Using an EC60:

Heavy Particle Beam - 15 shots (720 energy / 48 max damage)

Heavy Laser -  18 shots (720 energy / 40 max damage)

Heavy Ion - 18 shots (720 energy / 40 max damage)

Crew Served Weapons

Any Vehicle / Heavy Weapon can become a crew served weapon. It requires the use of Energy Cells (see above) to power the weapon, and it has to be outfitted with some form of ground mounting and stabilizing platform such as a tripod. Setting up or breaking down a crew served weapon requires a full round (six seconds), after which it may be used without a minimum strength. It is, however, immobile until it is broken down (again a full round).

When transporting the system, the individual pieces are typically distributed among the crew. Humping the weapon itself requires a minimum strength of d4 + Mods die steps (so 1 Mods requires a d6, 2 requires a d8, and so on). Depending on the size of the cell used, each crew member other than the weapon carrier has one or two cells added to their kit.The larger cells are almost exclusively used for semi-permanent fortified positions.

I'm still trying to come up with a good rule of thumb for how much the weapon itself weighs. For now, assume that anyone humping the weapon itself is considered to be encumbered with a -3 penalty as per the encumbrance rules as if he or she was at 3/4 of their max load, Reduce pace by 2 when carrying.

---

Update 2016-10-18: Simplified the math and design to make it much easier to use, coming back to "Fast, furious, fun".

Savage Rifts and Weapons

First, let's start with the good. Combat is, as advertised, Fast, Furious, and Fun. Combat tends to be more "deadly", in that characters can and will be incapacitated relatively quickly. On the up side, however, incapacitated does not necessarily equal dead. Possibly just maimed, or otherwise marked, but not necessarily dead.

One thing is certain, however - the current release that we backers have needs some TLC. It looks like some sections, and even some weapons (since that's the focus of this post) were designed one way, and then forgotten when another design choice changed how the weapon actually interacted in away completely different from the intent.

For example, let's look at the Portable Rocket Launcher. It has an AP of 20 and does 6d6 damage. The mounted version has the same AP, with 7d6 damage.

Okay, so the PRL ignores pretty much any armor value, ever. The highest armor in the game that I've seen so far is on the Glitter Boy, at +18. What is supposed to be the pinnacle of personal powered armor is useless against a bazooka.

Surely the missiles are just as insane ... wait, they're not?

Vehicle Missile Launchers (VMLs)
VML:Mini - 5d6, AP 6
VML:Light - 6d6, AP 8
VML:Med - 8d6, AP 15
VML:Large - 10d6, AP 20

So, the closest we get to equivalent AP is the large missile launcher. For damage, we're looking at the light launcher.

A theory was proposed that the PRL was put in when they were doing armor like in Hell on Earth, where apparently tanks are running around with +100 armor as standard. When the changed how they were handling armor, they didn't update the PRL.

I think it's an even simpler transcription error. When looking at the text about missiles, the player's guide describes AP missiles over HE (HE being the default). AP missiles lose 2 damage dice, but gain +5 AP. If you look at a medium missile, it has a default statline of 8d6 AP 15. An AP medium missile would be 6d6 AP 20. There's other issues, but most of it can be chalked up to not paying attention when transcribing the data.

Still, I think its a problem that a Glitter Boy is at serious threat from a bazooka. I'll probably swap the medium missile for a light missile and give it the same treatment (4d6, AP 13) - painful, and can possibly take out GB, but less likely. An even less likely one-shot would be an AP mini-missile (3d6, AP 11).

That said, let's break down the categories:

Ammunition and E-Clips

My biggest issue with ammo and e-clips is the overall simplification. I get that it makes things more "Fast, Furious, and Fun", but the way they handle it is that an e-clip is rated based on total shots, not total energy. For example, let's say I have a laser pistol with 20 shots and an ion rifle with 20 shots. I can use the same e-clip between either of them (at least, that's how I read it - the alternative is that e-clips are per weapon, which is just counter to the source material of e-clips being universal). However, I could not use the same e-clip in a laser pistol that has a capacity of 10 shots. That needs a 10 shot e-clip.

This comes into play when pricing new e-clips and recharging them - the cost of recharge is the number of shots * 100 credits, and a new clip is double the recharge cost. So there's a definitive difference between a 20 shot e-clip (2000 to recharge, 4000 new) and a 10 shot e-clip (1000 to charge, 2000 new).

Grenades

Overall, grenades are grenades. Throw 'em, shoot 'em, get them over there somehow and they go boom - preferably amidst the enemy.
One oddity, however, is with the middle to entries, both Fragmentation (as opposed to Armor Piercing or Plasma).

The first one is 3d6 damage, LBT, 550 credits.
The second is 3d8 damage, MBT, 750 credits.

Not sure if the blast templates got switched or it was intended to have a larger blast for less credits. The difference in damage is at most 6 and on average 2, which doesn't really account for a smaller blast radius. I'll probably be swapping them.

Ion Weapons

Apparently in Savage Rifts, ion weapons act sort of like shotguns - +2 to hit due to spreading but loosing of damage at each range past short. Okay ... I can sort of dig that. It gives ion weapons a uniqueness beyond damage ratings, and I'm okay with that.

Lasers

Default weapon type in Savage Rifts, nothing especially special about them except that they provide +2 to vigor rolls to avoid bleeding out after incapacitation due to cauterizing the wound.

Particle Beams

Listed as a sub-set of lasers ... okay. Sure, why not. Supposedly they trade the range of a laser for extra punch, but in this case the "punch" is one increased die type and a straight bonus to damage.

If I recall my source material correctly, PBs were the premier anti-armor energy weapon type, typically used to take out giant robots, tanks, large supernatural creatures like dragons, etc.

As such, I would probably either trade the damage bonus for AP on a one to one basis, or simply double the AP. That would give the single PB example in the book (a pistol), an AP of either 4 or 5. That's enough to negate most of the armor bonus on most body armor, making PBs something to truly fear.

Plasma Weapons

Plasma ejectors are now large, unwieldy affairs, incurring a Snapfire quality.
Plasma engulfs the target completely, all at once, and so is treated as hitting the least protected area of the target. Not wearing a helmet? No armor bonus, then.
Plasma has a default 1 in 6 chance of igniting, causing 1d10 fire damage per round until doused.
Plasma is always Mega Damage.

So, big honking brute force weapons, and always effective (such as it is) against any target. I like it - it really cements its place as a squad heavy weapon.

Summary

Overall I like it, but it needs work. I have issues with how they handle ammo, and I think they need to tighten up some of the entries. Otherwise ...

• Lasers are your default, go-to weapon.
• Particle Beams are armor peelers (the way I have them set up).
• Ion weapons are energy shotguns.
• Plasma weapons are brute-force kick down the door heavy weapons.
• Grenades are grenades.

Modelling CS Response to Player Actions

Wanted: Dead or Alive

So this is something I've been working on since ... a while ago. Couple of years, at least, I think.

The basic idea is to give the CS a form of AI for the game. Something that responds organically to the actions the player group takes.

In the previous iteration, it was a percentage check much like a skill. The group had a "CS Awareness" stat, and the GM rolled it like a skill. On a success, the CS is actively pursuing the players, with the level of success indicating how bad of a response.

I may continue working on that, but with Savage Rifts finishing in about a week, I figure I should start looking at how to adapt my present ideas over to the Savage Worlds rule-set.

In this case, it's actually fairly straightforward. There are a couple of ways to handle it - the RAW Savage Worlds way and the Savage Rifts way.

The RAW Method

The RAW method is to, again, treat it as a skill check. The level of the skill is the general idea of how annoyed the CS is, while the TN is the result of more immediate actions. Suggested starting values for both are d4 and 6, respectively, making it very unlikely that a new group will attract particular interest at any given time.

Suggested modifiers:
Obvious DB(s) in the party: -1 to TN
Obvious use of Magic / Psionics against CS troops: -1 to TN
Within the borders of a CS territory: -3 to TN

Things that increase the die level:
Repeatedly wiping out CS troops
Assisting known enemies of the CS

The Savage RIFTS Method

The Savage RIFTS way, and my preferred way, is to borrow shamelessly from the Savage Juicer mechanics.

Give the players a Wanted level, and a Wanted die. At the beginning of the game session, the GM rolls the Wanted die. If the roll is above the Wanted level, the CS has taken notice of the players and has sent some forces after their group. The players may opt to lower their Wanted level (and lower is worse, in this case) to avoid the encounter, but in doing so they make it more likely to occur in the next session, and possibly with worse consequences: the lower the Wanted level, the bigger and nastier the force that is sent after the players.

Suggested starting points for Wanted are 8 and a d8 (yes, the Wanted die can Ace).
The Wanted die fluctuates based on player action:
+ 1 die level when travelling through CS territory
+ 1 die level when passing near a CS outpost
Still working on what would lower the Wanted die

Finally, the players may actively court CS intervention with flagrant displays of power. This is mechanically represented by lowering their Wanted level in exchange for a "super" bennie. I'm still working on the details of what this would entail, but an example might be that the group automatically achieves a particular task, or maximizing any roll (without raises), etc. It will need to be worth bring the CS closer to finding the group.

Work Still to be Done

These are very rough, off the cuff ideas that need refining and playtesting. In particular I need to determine what the CS response is at a given Wanted level, how to regain Wanted levels, and what voluntarily burning a Wanted level does when used for a "super" bennie.
Still, I think this is a good starting point and there's enough there for anyone reading this to run off with and make their own.