Earlier this year I did an in-depth review of SMRPF (Simple Modifiable Role-Playing Framework), an in-development game by Grey Rocket, which focuses on bringing the feeling of Dungeons & Dragons 5e to a more adaptable generic version for Grey Rocket to build and adapt to his own needs. What was delivered was one of the cleanest in-development game documents I have read to date. If you would like to see the in-development game, you can grab it at: https://greyrocket.itch.io/.
We have all had this dream at some point or another: what if I could make 5e better fit my needs? So, let’s first look into how Grey decided to tackle this by starting where all design reviews start, the game’s pillars.
As simple as possible but as defined as possible.
“A generic system similar to 5e, but simpler, from which I can easily homebrew into any setting.”
Designed to attract players who are new to the ttrpg hobby.
To keep players experienced with SMRPF interested in playing
Keep it Simple
For the first goal, “as simple as possible…”, remember how I said this was a clean document? The game does this really well overall. There are a few cases I encountered that felt more like suggestions, but that can be cleaned up with language. The rules are laid out systematically and tied well into each other for the core loop of the game. You will need to read the book to actually see what I mean here. As much as I enjoyed reading SMRPF, I think it highlights some of the challenges of trying to base your game off D&D 5e and still preserve the character of 5e. throughout this review I will go over some of the things I think were done poorly in an otherwise great pre-release document, why that might have happened, and what we, as designers, can learn from those mistakes.
Explain When to Roll
While the Skill Checks section in SMRPF was relatively clear cut, the first sentence left the act of “when to use Skill Check” undefined. Here is what is written: “When a character tries to do something, the GM may use a Skill Check to determine if the character succeeds or fails." The use of the words tries and may here leaves a very undefined situation. Rules books should attempt to better define exactly when a mechanic should be used, because the frequency the mechanics are used, shape the feel of the game.
Determining the pace of calling for a roll is how a designer can control the narrative of how your game is played. Clear indications of when mechanics are used helps ensure the game is played the way it’s meant to be played, as to highlight the themes the designer had in mind. A horror ttrpg might call for dice rolls rarely (because it carries a severe penalty of failure) while ttrpgs where activating character abilities are tied to dice results might call for frequent dice rolls to provoke interesting events. You are the game designer, so you create the framework of fun for the players to explore around or within that mechanical framework. If the text says nothing about when to roll, then the GM and players might over-roll or under-roll based on their assumptions, which might contradict the game’s themes or design goals. Without clear and complete rules on when to make a Skill Check, the game cannot stand on its own. It requires experience playing another game to cover the rules it cannot. In this way SMRPF fails in its goal of being suitable as someone’s first ttrpg.
Define the Player Characters
The section that really needed more definition in SMRPF was the Character Creation section. The first mechanical sentence: “To create your character, give them a name, a description, any languages they know, their species, their backstory, their allies, and anything unique about them” left me confused with no clear way to resolve it. When I read the above sentence, I would expect the next few sections to explain each of the listed requirements to be explained, instead I found no such explanation for the underlined sections anywhere in the book. While this leads me to believe this is all narrative—without mechanical reinforcement or clearer definition, but, there should still be a description of each explaining such. It’s fine for these aspects to be loosely defined, many ttrpgs do that successfully, but without any understanding of usage, SMRPF needs to rely on other ttrpg rulebooks to support play. For players coming from D&D 5e where these very aspects are more rigidly defined just creates confusion for a SMRPF player.
Examples Reflect Play Expectations
The third thing I want to bring up is a play example in SMRPF. It reads: “Example: A PC wants to jump over a large puddle…” Examples should be representative of what the players will do in the game that would require the mechanic. So, unless jumping over puddles is an exciting and challenging task to the players, skip past them instead. Having representative examples in a rulebook does not just help guide players on what they will be doing, or how to use the rules, it also informs them of appropriate situations to use the rules. So, in the case of the puddle example, and especially since when to call for Skill Checks was so vaguely defined, players are taught to do a Skill Check for all tasks as ordinary as jumping over puddles, and should expect to roll for things of puddle jumping difficulty or greater.
How Close Should An Adaptation Be?
Dungeons & Dragons 5e is not popular for its raw mechanics. In my experience, players generally do not find it engaging for these aspects in comparison with other systems. D&D 5e’s biggest draw is its holistic approach to exploration. Exploring the unique monsters, reading and imagining the class and race combinations to make your character, and discovering new items that appear in your games. Naturally, any game can have these things, but by copying 5e without capturing what I feel is the character of the game, SMRPF becomes less of an adaptation of D&D 5e and more of a game of its own based on D&D 5e.
Players new to tabletop roleplaying games do not play a game for mechanics. This comes from my experience developing a generic system. They play because of friends playing, because of interesting stories or worlds, or because they can be something really interesting. That is why 5e is really good at attracting new players, because it has a lot of friends already playing. It has a brand of fantasy that is mainstream to understand. A system that is based on 5e hopes to carry over the built-in audience, but if it deviates too far from 5e’s play principals it risks alienating players by defying their expectations of what 5e’s character is. There is nothing wrong with taking your system in its own direction, but you’d need to be aware that you lose the built-in popularity, and instead need to highlight the strength of your mechanics and the potential unique stories that can be told with your system beyond the reach of D&D 5e. It would then be the GMs’ role to attract new players, rather than relying on the built-in audience of D&D 5e.
When making your own games, try to remember these points, so you can ensure your understanding of what makes your favorite game magical is not missed in your development. Especially remember this advice if you, like me, are making a generic system.
This is my second time with the new format so let me know if you like it. If you want more/less depth, examples, or whatever in the comments below. If you like my work, join my mailing list for my own system. Or you can give me a follow on Twitter @c22system or @PagodaGamesLLC on Facebook/Instagram. Also, please go check out the rest of Grey Rocket’s work on his itch.io page: https://greyrocket.itch.io/.