Friday night, I got four players together to run a second playtest of Leverage: The Roleplaying Game. My plan is for this playtest to be somewhat more involved than The Quickstart Job, and includes full character creation with the recruitment job and a job of my own devising. That means two sessions: one for character creation and the recruitment job, and one for the full job. And the first one was, as I said, on Friday.
One of the things I was worried about was the fact that I could only get four players, when the game seems highly optimized for five. I could probably have snagged one more player by expanding the initial invite list, but when I started thinking about that, I realized that it might be a good idea to see how well the game works with fewer players ((Another question becomes how well the game works with more than five players; at some point, I may try and test that.)), so I decided to go with it.
The main issue with having only four players is that there will be one of the five roles ((Theoretically, you could wind up with more than one role going spare if the players double up on primary roles, but the structure of the game seems to encourage diversifying.)) that does not have a primary – a character who has taken a d10 in that role. That means the team has a slightly reduced tool set for completing the job. While that initially bothered me,Â I began to think about other strongly role-based games, like D&D 4E, and how they play with one or more of the core roles lacking. They work just fine; it just changes the options the characters have in approaching the various obstacles in the adventure.
The initial phases of character creation went pretty smoothly, with everyone picking their primary and secondary roles, distributing their attributes, and picking a distinction without any problem. We wound up with a Grifter/Thief, Hacker/Hitter, Hitter/Thief, and Mastermind/Thief. I found it interesting that, recognizing that they did not have Thief in a primary role, the group’s approach was to make sure that they had, shall we say, depth of field in Thief as a secondary role. The prevalence of the Thief role in secondary, to me, created a strong theme for the crew ((The fact that the Thief role is secondary to three characters, in my mind, almost overshadows the difference in the primary roles. Strong commonalities often act as a foundation of unity for a group, allowing the differences in the primary roles to shine out. For example, every member of The A-Team had been a soldier; they could all fight, despite the fact that each brought a different skill set to the table, as well.)) – they were, for the most part, stealthy, sneaky, covert types.
Attribute-wise, we had an even split in the group between the generalist and specialized attribute arrays. That says to me that the two options are nicely balanced, each offering something valuable, yet different. Now, that was my assumption, based on the fact that each array essentially gives you 48 die-sides to spread among your attributes, but equal numbers doesn’t always mean the two options are as good as each other. The test, in my mind, is whether people will use both options equally. In this admittedly small statistical sampling, they did.
Everyone seemed to have a good idea of their first distinction, based on the little bit of backstory they had come up with for their character concept, so that went quick. We wound up with Charming Rogue, Hot Tempered, Tougher Than He Looks, and Bastard. And then we got down to the recruitment job.
This was a little rough. Some of that roughness is my fault for trying to make things a little more elaborate than the way things are described in the rulebook, and some of the roughness is caused by the expectations set up in the rulebook for what will happen during this job.
The part that was my fault was caused by me wanting to inject a little more flavour of the full job into the recruitment job. So, I let the group set the mark and the client, and then I statted them up. They got to determine the plan for the job, within the restrictions that they would each get a spotlight scene. The issue here is that I let things get too elaborate, story-wise, while still keeping the spotlight scene restrictions from the basic recruitment job, meaning the crew had to work things into a very artificial structure. In retrospect, I should have gone all one way or the other: either make it a full job, with none of the restrictions, or stuck with the basic nature of the recruitment job.
The part that was caused by the expectations set up in the rulebook is a little different. See, the assumption that was left with after reading through the character creation session was that the characters would be complete after the recruitment job, with maybe one or two that were missing one or two things that could get filled in during the first job. A little bit of math shows this to be somewhat unreasonable, unless you’re running a full-session job ((Even then, it’s gonna be a tight fit.)).
When you start the recruitment job, each character needs to complete a certain number of things on the rap sheet:
- Three roles still need dice assigned to them.
- Each character needs two more distinctions.
- Each character needs two specialties.
- Each character needs two talents.
Now, the roles are moderately easy to assign – just try doing something in one of the scenes that uses a role you haven’t assigned. The trick is that, by doing so, you are by definition not playing to your strengths, moving outside of your comfort zone. I like this, because it very nicely puts some interesting stress on the character, revealing more information by how they respond under pressure.
It’s the other three categories that create the problems. Each distinction, specialty, or talent is introduced in play with a flashback. That means, in a four-player game like we had, you need a total of 24 flashbacks during the job in order to cover everything. Each flashback took about five minutes to work through ((Mastery of the system would, of course, reduce this time requirement, but given that the recruitment job is going to be one of the first jobs most groups do, I think it’s fair to say that mastery of the system probably won’t exist in the group at the time of running it.)), with time for the player to come up with a flashback, present it to the group, and incorporate its effects into the character.
That makes for two full hours of flashbacks. Two and a half, if you’ve got a full five-person crew. Considering that our play sessions run about five hours, and the first two hours of the evening were taken up with the first part of character creation and an explanation of the system ((Again, this time requirement would be reduced significantly with mastery of the system.)), that leaves an hour of play devoted to creating and completing the job in the present if you’re going to get everything in. That doesn’t strike me as a reasonable expectation.
It’s important to note here that not everything needs to get taken care of in the recruitment job. The book specifically says that if, at the end of the recruitment job, you still have some blanks on your rap sheet, don’t worry about it, because you can fill those in during play. The problem was that I hadn’t done the math on the time factor needed for all the flashbacks, and had assumed that it was unlikely that there would be anything left to fill in if we ran the recruitment job properly. That meant I was trying to cram everything in during the job, and that made things feel very forced and clunky.
I also think that the requirement of a flashback to introduce distinctions, specialties, and talents is not really necessary. In future, if I run this again ((Who am I kidding? Of course I’m going to run this again. I don’t want to start a new campaign right now, but I’m at least going to try another playtest with more than five characters to see how things scale in that direction.)), I’m going to say that you can establish these things after a good character moment – maybe even let the rest of the group pick the moment to establish a distinction for a character. Still allow flashbacks, but not require them. That would speed things along, I think.
Another thing I should have done to speed things along is to have cheat sheets done up of the available talents, to aid the players who hadn’t read through the rules in picking them on the fly. I didn’t do that, and it meant that a lot of times, the players didn’t know what kinds of talents they could pick, and so didn’t try to establish them.
I’m making it sound like the recruitment job was a train wreck, aren’t I? It wasn’t. It was less smooth than I would have liked, and parts of it felt forced, but it still worked and was fun. Considering how smoothly things had gone in The Quickstart Job, I was curious as to why it hadn’t gone that way this time, and so I’ve spent some time analyzing the issues. That’s why I’m talking about problems rather than what went right, here.
The job turned out to be interesting, and showed me very nicely how a good complication can be used as a twist in the job.
The basic set-up was that a real estate developer had a property owner beat up, trying to force him to sell ((Strangely reminiscent of the current storyline in my Feints & Gambits campaign, but only one of the players is in both games, and the set-up wasn’t her idea.)). The crew decided that he was a collector of antique swords, and also skimming off the company profits. The plan was to swap one of his valuable swords with a fake ((An interesting first scene for a group without a Thief primary, I thought. The Hitter/Thief managed it, though.)), then approach him to sell him the real sword. The asking price would be high enough to get him to tap into his offshore accounts for funds, which would let the hacker piggy-back in and copy his financial records for delivery to federal investigators. The money from the sword would then go to the client to cover medical bills and pay off the liens on his property.
Things went pretty much as planned, right up until we got to the end of the scene with the hacker copying the data, and I realized I had three complications that I hadn’t spent. I glommed them all together into one d10 complication, and said, “Huh. According to the financial data, he’s using his development company to launder money for the mob.” Mob Involvement d10.
That changed the objective of the plan to getting him to roll over on the mob, abandoning his luxurious life for witness protection. The Mastermind organized a series of flashbacks where the crew made the mark think that someone in the mob had given him up to the feds, and the mob was going to take him out to prevent him being arrested and testifying, ending up with the asset Worried About The Mob d10 to offset the mob complication. The wrap-up had the mark fleeing into the arms of the FBI ahead of imagined mob assassins, and the money from his cleaned-out accounts going to the client.
The way the complications I had left turned into a twist in the plot worked remarkably well. The rulebook says that, really, all you need to run the game and build jobs are a problem, assets, and complications. This was a perfect illustration of that fact, and one that I need to keep in mind for when I create the full job for the next stage of this playtest.
We wrapped up with a postmortem, where we discussed the issues I’ve outlined above, but everyone said that they had had fun. To help address some of the issues, I had gave those who had not completely filled in their rap sheets the option of doing so before the next session, or leaving the blank options to be filled in during play. The one thing I wanted to complete were the distinctions – most of the characters had one distinction still to be filled in. I got the rest of the group to decide on a second distinction for each character based on how they had done things during the job.
And that’s where we left things. In three weeks, I’ll be running this crew through a full job – they’ve already got a taste of how it works, but now they will have no restriction on number of scenes or who’s involved, or the number of flashbacks needed, or anything like that. I think it’ll go a lot smoother ((I’m using the word smooth, and its variants, a lot in this post. That’s because smooth is the best way to describe the system when it’s working well.)). I’ll let you know how it works.