Tips for a game starting soon?

[delazar]

Finally the time has come, this week-end I'll be LMing the first session, I'm planing to run the adventure in the LM book, then all the adventures in Tales of Wilderland.

I've got 3 players for sure, maybe one more coming, a pretty good grasp of the combat rules, I'll re-read tavel rules before the session, and I'm pretty sure how I want to handle advancement points.

Anything else I should make sure I know?

[Woodclaw]

I think that one of the key spots that you and your players must understand is the difference between Skill Tasks and Skill Tests.
On a basic level the difference is that Skill Tasks are initiated by a request from the players, while Skills Tests are required by the Loremaster. On a deeper level there's a more important difference: Skill Tasks are meant as a tool to achieve a result, whereas Tests are meant to avoid consequences.

E.G.: if you have set-up a scene that includes an important but non-vital clue, then finding it should a Skill Task. Hence, if the players don't ask for it you should simply skip over it.

[delazar]

mh... not sure how important is this?

Aren't all rolls triggered by the LM? I don't allow players to just roll the die, they tell me what they want to do and I tell them, "ok, make a Song test". If there's need of a die roll at all, of course.

[Random221B]

Actually, no, all rolls aren't triggered by the LM. As Woodclaw says, Task rolls are initiated by the players, and Test rolls are initiated by the LM.

When a player wants to take some kind of action to achieve a goal, that's a Task. The player announces what she wants to try to do, and what skill she's going to use to try and do it, e.g. "I want to make a Courtesy roll to try and impress the Innkeeper, and get him to tell me about his sister." As long as everybody agrees that the skill the player wants to use is appropriate for what she is trying to achieve--based on her description--she goes ahead and makes the roll. If there's disagreement, the LM adjudicates.

When something is going to happen to a player or challenges their abilities, and the LM needs them to react to it, that's a Test. In that case, the LM knows that there is something they must react to, and thus tells the player what kind of roll to make, e.g. "You're approaching the tower ruins on the edge of the Mirkwood. I need you to make an Awareness Test."

So, in summary, Tasks are called by the player when they want to achieve or gain something, and the player declares what skill they are rolling to try to get it (subject to the group's approval.) Tests are called by the LM when the player must avoid consequences or something is directly challenging their abilities, and the LM tells the player what skill they must roll.

Obviously, as always, as LM you are free to call all skill rolls, but the above is officially how the game was designed to run.

Thanks for your time.

[Stormcrow]

I agree with Woodclaw and Random221b. Also note that the loremaster always has veto power, bit he should generally use it only to prevent the players from abusing tasks.

Another area to watch out for is traits. If you peruse this forum you'll find much disagreement over how "automatic actions" are supposed to work. Work out an understanding with your players early on, to avoid arguments later.

[Woodclaw]

mh... not sure how important is this?

Aren't all rolls triggered by the LM? I don't allow players to just roll the die, they tell me what they want to do and I tell them, "ok, make a Song test". If there's need of a die roll at all, of course.

As Random explained above, no.
In my eyes one of the key points of One Ring is that the number of die rolls should be extremely limited (especially when compared to D&D 3.something or other similar games). Most of the time the assumption is that the character should be able to achieve what they want mostly through narration. Rolling should be called only to achieve a degree of success above the minumum or to avoid consequences.
For example, let's consider three instances linked to the Song skill.

• The fellowship finally reaches the security of the Easterly Inn after a long ride across the wild. After dinner Robin, the fellowship hobbit, decide to take the stage and improvise a humorous ballad upon a goblin and a bear. He doesn't want to achieve anything special, just add some life to the scene and the LM adjudicates that the patrons of the Easterly inn are in a good mood. Given that there's no need for a task, nor for a test.
• A few months later the Fellowship is back to Easterly Inn, but now the inn is under attack from bandits. A group of weary Beornings is all had kept the inn safe so far, but they're wounded and their spirit is crushed. Robin decide to perform his ballad once more, to remind them of merrier times, and raise their spirit a bit. He asks the LM to roll Song. This is a task since Robin started it to achieve something more than basic. Robin will roll and narrate the result, plus the LM will adjudicate eventual bonuses/penalties that might come from it.
• Some more months later the fellowship decide to stop at Beorn's house to rest. Unfortunatly for them, the skinchanger heard about the witty hobbit and his ballad, but he didn't like what he heard. So before letting them in he demands that the hobbit performs the ballad in front of him once. Since the result of this performance might change Beorn's disposition for the worst, the LM demand a Song roll from Robin. This is test since it was demanded by the LM and its scope is to prevent a complication.

[/i]

I hope these examples helps to explain my point.

[delazar]

Ok got it

[alien270]

I'm still not sure how important the distinction is. IME skill checks in every RPG are sometimes initiated by the player, and sometimes initiated by the GM. In TOR those different instances happen to be tagged with different terminology. I've run TOR for 2 different groups, and I have a successful ongoing PbP game that's over a year old, and I've never put much thought into the task/test dichotomy.

I'd say watching out for trait use and avoiding "AP-spamming" by the players is a more important issue to keep in mind. Skill rolls should only be used when there's meaningful narrative consequences. In one of my FtF groups (they didn't "get" TOR like my PbP group does) the Beorning would constantly try to fish for APs by doing everything "Swiftly," pretty much completely missing the point of the system. Advancement should be a reward for narrative contribution; weak narrative should not be simply a means to an end.

Other than that, don't feel like the rules are a straightjacket. You don't need to bust out the journey rules for every little traveling scene, and you don't even need to use them for longer journeys that you'd prefer to gloss over. The journey rules are for making travel more interesting, and tend to work best when you think of the journey as an adventure unto itself (Don't Leave the Path in TfW is a good example). Similarly, I tend not to be too heavy-handed about the Encounter rules. Don't feel like you need to keep the Encounter going if things get resolved using fewer rolls than you expected.

[Evening]

I'm still not sure how important the distinction is. IME skill checks in every RPG are sometimes initiated by the player, and sometimes initiated by the GM. In TOR those different instances happen to be tagged with different terminology..... and I've never put much thought into the task/test dichotomy.

Same here. Now I'm curious why this is deemed important.

Another area to watch out for is traits. If you peruse this forum you'll find much disagreement over how "automatic actions" are supposed to work. Work out an understanding with your players early on, to avoid arguments later.

Yes, lay down the law the first session. IMO, start with Hardy.

[delazar]

Yes, I had noticed that Traits could be a mechanic easily abused. Due to the many years of DnD, my party has a bit of the mindset to go and look for every possible advantage, but they're also open to discussions.

So hopefully, if I noticed them abusing this, I can talk them into holding their horses a bit.