I am not talking about the normal twists one might expect the module builder to include, but I refer to the twists that players may add of their own. You know the type I mean, when they manage to do something completely unexpected and "break" the module. The difficulty for the builder comes as they give the player more freedom, and the player eventually uses that freedom to get around a plot "choke" point in a way the builder may not have first thought of. A simple example may be when the player discovers a way into an area before they are supposed to. On the face of it, that may be a fairly easy thing to fix, but "fixing" it so the player does not feel cheated or forced in a certain direction is a much more difficult task to pull off.
In the next few sections, I have tried to discuss various aspects of PC freedom and what might be done to help overcome the type of problems I mean both for the builder and, therefore, the player as well. And because when we design a module we tend to have the outcome in mind, I will start off by giving my overall conclusion to act as a governing point to all those I am making, but will include individual suggested solutions for each problem along the way as well.
Plot Considerations Poll
As a result of my pondering this week, I thought I would submit another poll to find out what other builders and players alike thought about the problem. Please submit your answer and add any comments that you think might be useful. (Top left of the page and entitled, "How Much Freedom do You really Want?")
In the end, I concluded that it all depends on how much the module builder wished to prevent the player "messing things up" whether deliberately or unintentionally. BUT, to the defence of the player, the more we (module builders) try to do this, the more the player may feel they are not playing the game the way they want to, but may feel railroaded down a certain path. Therefore, I recognised the builder needs to carefully weigh the level of freedom they offer the player in their module and then ensure the players recognise and accept to co-operate within the limit before they start playing it. However, once the terms of the gaming have been accepted, it is the responsibility of the builder not to backtrack on what they have offered, or, to put it another way, not to forget what a player might like to try to do within the capabilities you have allowed them.
For my own module, Better The Demon, I have set the level of freedom quite high (too high?), which has forced me to look at these points differently as I have gone along. I share them with you now, hoping they may help other builders.
To Plot Or Not To Plot
Does the builder make items "plot" or not? Doing so ensures the player cannot destroy an item and can always work with it (cannot sell it), but does that always make for fair/free play? For example, if a player casts a fireball in a room, should it be allowed to destroy the frail ancient book that holds the answer to the quest they have been working on or not?
Suggested Solution: Personally, I prefer to remove this particular "freedom" from the player and make the book indestructible, simply because I like conclusion in a game. However, are there any "purist" players or builders who think they would prefer otherwise? Furthermore, I like to change the state of this type of plot item after it has served its purpose. Once the PCs no longer need the ancient frail book, maybe it can crumble, burn or even be sold.
Other Points: What if the book represented the start of an adventure? What if it is only one book in a collection of books? Should a plot item be made undroppable as well?
A Key Is Required
Are there times when only the key will unlock the door? The player starts the game and finds a locked cellar door. They start to pick it, only to be told that only the key will work. The wizard tries the knock spell and likewise cannot get past. The fighter tries to bash it down, but the door refuses to budge. So the party walk away from the inn's cellar door mystified and disappointed. The point I am trying to make here is to avoid misuse of this facility.
Suggested Solution: I find this one of the more difficult problems to overcome within reason. My own conclusion is that most (if not all) doors should be possible to pick, knock or bash and that requiring a specific key should be reserved for special fortified entrances and exits only. However, this can be difficult to govern as there are a number of variables that a clever player can add to their chances to bypass a lock. It only takes one miscalculation by the builder and the player suddenly has access to an area before they should have. There is no easy answer to this one, except for the builder to be ready with a very good reason as to why a door is impassable without its key (E.g. The cellar door actually led to a wizard's dungeon and was protected with magic.) or be prepared for a change in the story and events if the PC is resourceful enough to get through to an area before events would have otherwise transpired. To make a plot still work requires a greater number of plot status checks (as I have discovered). Even using a monster as a guardian comes with risks.
Other Points: In my opinion, there really should be no reason for relying on a required key within a fantasy environment in most circumstances. Furthermore, difficulty settings should not be unreasonable for the door in question. After all, how many doors have super locks? For Better The Demon, I have used other reasons why PCs cannot bash at a door or even enter certain areas after picking it, like using witnesses and NPCs who prevent the PCs from doing so. However, even this method can come with potential issues. (See next.)
Why can't the PC attack the NPC who holds the key? The NPC in question does not have to be holding a key specifically, but can be said to have anything the PC requires but won't part with it until the PC has performed a certain task, or are preventing a PC from doing something just by their presence. Would not an evil or impatient PC just simply want to attack the NPC and take the item from them or get past them?
Suggested Solution: Make it so NPCs can be attacked by enabling the option in the campaign settings. This, however, is easier to enable than it is to support. For example, the PCs meet an innkeeper who has a number of tasks for them, but a "twitchy" assassin gets a little frustrated with the innkeeper's lack of co-operation and decides to kill him before all tasks are delivered and met. Now, in this case, I believe the player should "suffer the consequences of their actions" and perhaps miss out on certain quests and results. That said, however, I would recommend having a backup plan to help the player achieve any main quests. Good writing may even allow the player to achieve even minor quests, but this would involve a lot more effort from the builder. The main issue one is trying to offer to the player here is freedom of choice once again. Here, however, it is the ultimate freedom of choice of whether to co-operate with people and society or go against it and risk becoming an outcast.
Other Points: Balance and plausibility are the key factors to account for here, and even the player must co-operate to a degree. After all, while they may potentially end up being able to kill everybody in the module, what would be the point of it? The odd discreet assassination or random kill reflecting the role of the PC is one thing, but even the best written module must reach a point where it recognises a maniac PC who must be destroyed by the world's inhabitants at all costs. There must also be recognised limitations with respect to killing traders. If achieved, a player should not expect to recover all store items, and even find themselves short of a way of trading items. However, a builder must be ready to consider allowing plot item drops that they may have only otherwise created at a conversation time. Lastly, systems need to be taken into account that can restore factions between PCs and targets if attacked by accident or if accidentally damaged by spells.
Pick A Pocket Or Two
Should plot items ever be pick-pocketable? The player knows the NPC carries the key they need and decides that they want to pick-pocket it rather than do the task asked of them. (They have learned that attacking the NPC is a bad idea.)
Suggested Solution: This one really depends on the item more than anything else in my opinion. Not just from a perspective of size, but also of relevance to the NPC and where the NPC is likely to store the item on their body. E.g. The key to the NPC's treasure chest is likely to be very well concealed on their persons in a place that cannot be pick-pocketed. Whereas, a few gold coins in the outer pocket may be easy to reach. NB: Some NPCs will ensure even this may be too well hidden to pick pocket, subjct to their own values and character. Things like armour and swords should never be pick-pocketable in my opinion.
Other Points: What happens when a PC pick-pockets in public? Does the victim stand mute if they discover the theft or shout for help? Does every potential victim have anything worth pick-pocketing? After all, what is the point of having the skill if the module does not cater for potential benefits of that skill?
What About You?
The plot points raised above are the ones I consider the most important. However, there may be more I have missed and if so, please let me know. And don't forget the poll!
BUILDERS: How do you plan your plot paths and balance that with freedom for the player? Do you prefer to write more streamlined interaction for your players or have other ways of offering an illusion of freedom?
PLAYERS: Do you prefer the DM to restrict certain aspects of reality to ensure a plot can be resolved. (E.g. Prevent a plot item being destroyed.) Or do you believe that every action should bring about its own consequence? How much "freedom" do you really want as opposed to a tighter story? It's an age old debate, but maybe in the light of a builder's problem, it may have you re-evaluate your own previous decision?
I managed to do some more conversations this week to do with a side quest. It was while writing this quest that I discovered the potential issues I raised above, in particular the problem of a player working their way into an area before I had originally planned. In the end I added many more checks and story paths to accommodate the player freedom of overcoming the challenge, but even so, I eventually had to reach a "stop point" to manage the coding. (From all the paths, I imagine this final point will never be found.) It does mean that the module's completion percentage could be upped. ;)