v0.1 - Adventuring

Let's start to get into the meat of the system a little bit more. I am going to break down the next few posts/chapters to cover the general flow of the game including Adventuring, Delving (going into dungeons), and Encounters. These three chapters are hierarchical in a way, with Adventuring covering the most broad strokes and then each subsequent item will cover smaller and smaller gameplay scopes. 

Why OSR(ish)?

If you have played any OSR based games before, then most of what you will read in the Adventuring chapter will be generally familiar. I've tried to take the general concepts and ideas that are common amongst various OSR systems and distill them down into simplified rules. 

Why am I focusing on this OSR concept though? Well, this is my first game design, and I am new to this. I might as well start from a solid foundation, but it is mainly because there is a breadth of content out there for these system and play settings already. This is a passion project for me and I can fully recognize that I am not going to be able to write dozens of adventures, supplements, and random generation tables. Those are already being made and have been made for nearly fifty years. I'm aiming for general OSR compatibility to leverage that content that is already out there. 

The OSR (and NSR) communities have really caught my attention over the past year or two since the OGL debacle. I find the approach to play in those games is really appealing to me and I appreciate how the math is structured, and how general play is approached. The emphasis in many of those systems on resource management, compromise, "low number" math, and "rulings over rules" really appeals to me and I think it is really conducive to a West Marches style game. 

Now, I don't think what I have below is inherently a "rulings over rules" approach, as there are plenty of rules here, but I wanted to break things down into what I felt were the most logical terms and conditions that relate generally back to our own world when trying to develop rules. I wanted to create enough rules to make sure everyone could easily understand the game, but at the same time, not need to go back and look something up back in the book. 

This is perhaps most clearly represented in the adventuring phases in a day. 

Phases

Phases of the adventuring day is something that is very common in many OSR systems. Some systems use hours, some use varying phases. I broke this down into the four most common terms that we use in our natural world:  Morning, Afternoon, Evening, Night. 

I also wanted to make sure that I do not reference time in any more specific detail than those four phases. I've found in most cases getting into any finer detail (for traveling)  just adds unnecessary complexity that bogs down the gameplay at the table. 

Refuges

One idea that I am developing to my game is the concept of a "Refuge", a set of secure supplies and a safe place in the wilderness where players can rest and recuperate. As I mentioned in the Principles and Concepts post, the world is dangerous and managing risk and reward is a strong component of this game. It is hard to heal and players in fact won't be able to heal when they are in the wilderness adventuring, unless they can find a safe harbor that has a bed (i.e. a town) or a refuge. A Refuge is an expendable resource that players can setups a key strategic points in the world that might be the different between life and death. 

It costs a lot of time and resources to setup a Refuge so characters will have to determine how to best deploy one.

Player Roles

Finally, another idea I am trying to play around with is the Player Roles. This is not a new concept for many classic games. Many will designate a player at the table to draw the dungeon map or to summarize the adventure. The more administrative work I can offload from the GM to the players I think is good, as it will incentivize players to remain engaged with the game even if their character is not active. This is a problem that I have seen across game tables, so I am hoping i can "kill two birds with one stone" here to offload some responsibility from the GM and also give something to the players. 

I want to bring this into the game world though as well, to possibly incentivize players who may not want to do something like that. The preliminary set of roles I have defined can also apply to the characters as well as the players. It is the hope that this will provide a small bonus in the game that will encourage players to want to take on these roles at the table. 

Google Docs - v0.1 - Adventuring

GitHub - v0.1 - Adventuring 

v0.1 - Town Creation

Let's begin our look of the play system with what I think is one of the starting points for a West Marches campaign, the Town. When I envision play in a WM campaign I picture the game centering around the home base that the players will be basing their adventures out of. I would like to have the town develop as a character unto itself as the game progresses. Characters will come and go in the town, some will die from adventuring or living on the frontier and I want that to be reflected in the story that is told. 

I've gone back on forth on a bunch of different town creation ideas over the past several months on my internal documents. I've toyed with some pretty in-depth ideas on creating a town, applying a layout to the town and having that recorded by someone in the player party. After some internal play-testing of some concepts, I found that what I was originally going for ended up being way to complex and crunchy for town creation. As much as I want the town to be an integral part of the gameplay experience, I came to realize that players don't want to spend a ton of time setting up the town, its denizens and all of the relationships. I also realized that all of that stuff doesn't have to happen before the game starts. One of my core tenants with character creation is that your characters aren't heroes before they start this game and to a large extent, who they were and their backstory before this town doesn't matter. Your character will be made through their adventures. That same concept needs to apply to the town itself, that the makeup of the town, the flavor of it will all be determined from the play that occurs moving forward, not from before hand. 

It was with that in mind that I scaled back my town creation concept quite a bit. I wanted to create something that was fun, quick, but still gave the players a general concept of how their town would be laid out and who the people in the town would be. 

With that in mind, players will basically throw their dice set onto the table and assign houses/backgrounds from there. Someone at the table can quickly transfer that idea over to a piece of paper for tracking purposes. Over time as the town grows, denizens change and things change, that town layout and detail can change. Ultimately, I plan to design a town "tracking" sheet that will allow someone to easily track the denizens 

Things can be loose here and not all of the townspeople need a name or need to have their profession fully fleshed out. All of that can happen later when/if a character comes into the story that is being told. 


v0.1 - Principles and Concepts

I am proud to to say that I have my first nearly complete version of Beyond the Torchlight written up and I think it is time I start to share the information to begin the feedback and review process. Over the next week or so, I'll begin to share portions of the files for review and comment. 

I welcome feedback and comments either on this blog post, over on Github or in the Good docs link below: 


Design Concept: Health, Breath and Characteristics

I'm getting close to my first draft of the character creation mechanics and I think it is worth outlining some of my ideas around "health", skills and traits in my system. 


Breath (Health)

The characters in BTTL won't have a hit point or health counter as you might see in other rpg system. A player's overall "health" is instead tied to a stat called Breath and their Characteristics. 

Breath is  your character's  ability to act during intense situations. Damage taken by the character is first applied to their Breath before it is subtracted from the appropriate Characteristic. Characters may choose to spend their breath to take more drastic actions during combat, use combat abilities, or to cast spells. 

Once a player reaches zero (0) breath, any additional damage is applied to the appropriate characteristics. 

At the conclusion of combat or a strenuous activity, characters may rest for ten minutes to "Catch their breath" and restore their points.


Characteristics

Characteristics represent a character's innate abilities, their physical capability, and mental acuteness. Characteristics are comprised of two numbers, which when added will total 20. If you are familiar with games like Call of Cthulhu or D&D, then this would be the closets representation to a Skill in one of those systems. 

The purpose of the two number system is to be able to establish a Difficulty Check (DC) score for characters to roll against yours as well as a Saving Through score for a character to roll against themselves. Characters will only roll dice if they are the ones taking an action. They will either roll to beat another character’s DC or roll a ST roll if there is a risk to themselves.

You might be asking why, for these two numbers? The reason is to maintain a "roll above" system while maintaining some sort of target number that is directly tied to the character in the challenge. I could have kept the math simpler by having players roll under for one type of stat and roll above for another, but while doing a quick survey with my personal play groups, my players just didn't like roll under systems. They wanted to "roll 20" for success. 

The example below will exaplain a common example of how the system is expected to work. 

Example

Player 1 rolls 3d6 for their character Elsa's Strength, Dexterity and Fortitude with the following results: 11, 13 and 5. 

Characteristic DC Check Saving Throw
Str 11 9
Dex 13 7
Frt 5 15

A thief is trying to pickpocket Elsa, but Elsa is pretty dextrous meaning that she has a high chance of detecting the thief trying to pickpocket her. The thief will roll 1d20 and must beat Elsa’s DC of 13 in order to be successful. The thief rolls a 9 and is caught by Elsa. The thief turns and makes a run for it sprinting across a roof top and jumping to the next building. 

Elsa pursues the thief and makes a jump across the gap between the buildings. This is a dangerous jump so Elsa will need to make a Saving Throw to see if she makes it. She needs to roll a 7 or higher on her Dex to successfully make the jump. She rolls an 11 and successfully jumps over the gap.

Combat Mechanics v0.1

Over the winter holiday I had a chance to sit-down and really crank through some of the ideas I had in my head and complete my first draft of the combat system. 

You can find the complete v0.1 document over on Github and Google Drive, but I'll try to summarize some of the concepts and what I am trying to do with combat. 

General Concept: The Battle Grid


One of the things that will immediately jump out to you when you read through the design document is the Combat Grid. I have been pondering on this concept for a few months, trying to figure out how to combine a few different ideas into a single system. 

I knew from the outset that I didn't want to use the common battle-mat and map layout that you see in D&D. This is partially attributed to the fact that I very frequently play those games so I am personally just sick of that mechanic. I also wanted to explore another way to represent the characters in combat. I have played "theater of the mind" in several RPG systems and more often than not, I have found that my players never are able to full grasp the concept. They always lose track of whom is engaged with whom, and the distances characters are from each other.

How could I find some way to get in-between both systems? How could I have something that is simple and streamlined at the table but at the same time could give some sort of visual representation of where characters are in relation to each other? 

The solution actually came from chess, which several of my regular players are really involved in. I knew from the outset that my combat was going to have players all take their actions at once and then have enemies all take their actions at once. This provided for a common mechanic similar to chess that just seemed to "click" for me. Once I had that idea down, I was able to expand from there to allow for a fairly tactical system that doesn't get bogged down in measuring combat distances in feet. 

Characters can act in combat lanes and can have their "stance" represented by the column they are in. I think there is enough information provided her to give people an idea of where and what they are doing in combat without having to spend five minutes on each of their turns trying to measure out 60 feet of movement. Playtesting I suppose will see if my assumptions play out as much as I hope. 

I would love to get some feedback from anyone who would like to provide a comment either on Github or on the Google Doc linked above.