Skip to main content
Process Post

Trails of Embers Process Post

By February 1, 2024February 8th, 2024No Comments

Trails of Embers is a system designed around the experience of a survival RPG. Players should go in expecting a harsh environment with difficult consequences. It is most directly inspired by systems such as Mage: the Ascension by White Wolf and Blades in the Dark by John Harper, with other elements inspired by Dungeons and Dragons 5th Edition and the board game Betrayal at House on the Hill by Wizards of the Coast.

We began our brainstorming not with mechanics but rather with a setting. We decided pretty early on that traditional fantasy was boring and overdone, so we turned our attention to a setting more set in gritty reality. We found survival horror to be an interesting medium to explore. After talking through a couple of options, we landed on an idea that we all thought was incredibly intriguing, flavorful, and mysterious: A world where the sun has burned out, and yet the moon still shines. Nobody knows where the light from this moon is coming from, but this moon bathes the world in a crimson hue; that is, when it is out. The darkness provides comfort, as the horrors come out during the light. Best be careful, scrappers.

With this setting in mind, we set to design the mechanics to fit it. With the survival scrapping aspect, we thought that it might be cool to have a loot system based on the video game Subnautica. This game’s progression is based on slowly traveling to more dangerous areas in order to acquire higher-tier items to continue surviving. The session run during the playtest will be more of a day-in-the-life experience, as exploring everything this environment has to offer isn’t feasible in an hour or so.

Our first idea for a looting mechanic was to play with a standardized deck of cards: players could go out to loot, and where they searched would determine how many cards they could draw. The suits would be different types of items, such as natural, technological, man-made, etc. This idea didn’t get very far, solely because we didn’t have an idea for an application. We eventually scrapped this idea because once we fleshed out the system more, we realized that it was too contrived to make what was essentially a reskinned random loot table, and figured it would be better for the players to say what they were looking for and have them roll for it.

For character creation, a system derived from Mage: The Ascension was constructed, with the characters having 9 primary stats separated into categories and skills associated with each. From there, players can put points into both categories and skills to determine how many dice are rolled on a given skill check. While it is not something that we were able to develop in a week, with the second iteration we hope to add some different playable classes for replayability. That being said, the point-buy system allows enough variability and choice during character creation for a lot of different builds to be distinct and interesting.

For dice checks, we devised a system similar to many d6 systems, where you roll a certain amount of dice, and success is determined on a variable scale. Here is where we changed it slightly though: rather than only the highest die determining the outcome, the success level is determined by how many successes the player rolled. For each check, a player rolls a number of d10s equal to the points in both their ability stat and the skill they are rolling with. For example, if a player has 2 points in Stamina and 3 points in Survival, they will roll a total of 5d10 to determine their check. The GM sets the difficulty class (DC) for the check (1-10) and after the dice are rolled, any dice that are equal to or greater than that DC add one success. A 1 subtracts one success. Dice that do not meet the DC but are not 1s are ignored. After the amount of successes is calculated, that value is compared to a table to determine an outcome. <0 is a critical failure, 0 is a failure, 1 is a partial success, 2 is a success, and 3+ is a critical success. This system is the basis for both exploration and combat.

For combat, we wanted a system that relied more on narrative and less on numbers and styled it off of Blades in the Dark’s combat system. This is a game that we wanted to be able to be played without battle maps, and so the GM determines the nitty-gritty such as distance, line-of-sight, terrain, etc. We also opted to remove an element that is often intrinsic to combat systems: hitpoints. We thought that it was both narratively interesting and more punishing for players to adopt a health bar similar to Betrayal at House on the Hill. When a player is hit by an enemy, they remove a point from one of their physical stats, strength, dexterity, or stamina. If a player should ever need to reduce one of these values to 0, they are dead. We thought that this was really interesting to toy with because as a player continues getting hurt, it is more difficult for them to stand back up. We want combat to be difficult and punishing, and additionally, we want players to use the resources they have acquired. We, unfortunately, did not get a chance to playtest this mechanic before bringing it to the playtest session, so it may end up being too punishing or difficult to keep track of. We’ll be watching it closely during our playtests.

Finally, we added a couple of things that we thought would be fun. In lieu of the flashback mechanic in Blades of the Dark, we wanted the player to be able to influence luck a little bit. However, nothing comes free in the apocalypse. Once per session, each player may choose to upgrade a single roll to any success level. However, the GM can decrease one of that player’s rolls in the future by the same amount. This mechanic allows the players to succeed at the brink of failure, but let the GM tear away a future success when it is a good moment narratively. It is a boon for both player and GM.

As for the design of the one-shot for playtesting, we landed on the idea of the players being sent out scrapping by one of the refugee camps. However, they are unable to make it back to the camp before the moon rises, and must try to survive the night while the horrors lurk about. This session should allow us to get a good look at how the system works during both exploration and combat, and will make us able to see how the players engage with the system, how straightforward it is, and what needs tweaking. We are all genuinely very excited about this system and setting, and we’re hoping people vibe with it as much as we did while creating it.

Process Post Playtest Revisions Edit:
After playtesting, we found that the system was incredibly promising, but we needed refinement with the level of detail we went into with the rules. Namely, the rules had some inconsistent wording and a lot of things were found wanting in terms of specific categorization. We also gave players a character sheet with attributes that could go up to 5 Points and gave them no way to boost their score to that level. These were our goals for improvement.

In our revisions, the main thing we did was tackle the rulebook, hard. In the initial design, we slightly misunderstood what was expected out of the assignment, and decided to go along the design of a campaign-style system that could be applied to many different worlds, rather than designing a one-time experience system with a world baked into it that would allow players to experience everything there is to see in just a couple of hours. One note we got from Bruno was that while this was still acceptable as a system to be graded for this project, this kind of design meant a lot of documentation. So we gritted our teeth and got to work.

In our refined rulebook, we went through multiple iterations of changes, holding consistent terms and themes all the way through without compromising our initial visions for the system. Our base mechanics went largely unmodified, all that we really changed was formatting and documentation. Where we added a lot was in the application of the base mechanics rather than the mechanics themselves. We figured that for designing a survival resource management-style TTRPG, we should probably have a well-defined and laid-out system for scrapping. We did this, applying our tier-based success system to specifically lay out what the characters get at every stage of success.

Additionally, we modified and refined how combat works. We decided that it was for the best if the GM did no rolling, and monsters instead did damage if the player failed their attack checks. We also clearly defined what each of our stages of success did in this category as well.

We added a system for XP that the players can exchange for Points to increase their statistics, to give a sense of achievement and getting stronger. Unfortunately, this XP system is designed with a campaign setting in mind, so when it is being played as a one-shot the players will likely not experience this mechanic.

Perhaps most importantly, as we tripled the length of our rules, we realized that as they were currently laid out, they were a lot to digest so we completely overhauled the layout. We separated everything into clear categories and defined consistent terms that we used all throughout the rest of the rulebook. Additionally, we included a Quick Reference on the last page of the rules so that players don’t have to look through 12 pages of documentation to define the term that they are looking for.

Finally, we wrote a premade 1-hour long adventure that, while it won’t allow players to experience everything the system has to offer, should give a good grasp on the core mechanics and should hopefully be fun as well. We had a lot of fun writing our exquisite corpses into the game, transforming them into stat blocks for our system that players can fight if they get themselves into trouble. However, the fighting route is only one of three end-of-session options, as fighting is designed to be incredibly dangerous and punishing in this system.

In all, we feel like the changes we made should drastically improve the play experience both for playing and running a game in the system. Unfortunately, we had a couple of ideas that didn’t make it into the final product solely for time reasons, but maybe we can add them at another time. For now, though, we are very happy with our final product and hope that you enjoy playing it!