Reply to thread

Message: <blockquote data-quote="kenada" data-source="post: 9248793" data-attributes="member: 70468">I happened to catch this right before bed, but I wanted to post something before the thread got moving too quickly. These are (roughly) principles I have for designing my homebrew system. If I missed something, that wasn’t intentional. I preemptively blame its being late. The list is numbered, but only the first few are really more important than the others. After that, the order is more what I happened to write when posting.<ol> <li data-xf-list-type="ol">The target audience is me. I’m designing a game to suit my needs first. If there were a game that did what I needed already, I wouldn’t be doing this. If the resulting system is not to your taste, it’s not for you anyway.</li> <li data-xf-list-type="ol">Iterate. Theorycrafting is inadequate to know how well something will work. I’ve had ideas that seemed nice in theory that turned out awful in play.</li> <li data-xf-list-type="ol">Create an MVP. The faster you can get something that can be played, the sooner you can start iterating. It doesn’t have to be good. It can be kitbashed out of other games. It needs to be enough to play.</li> <li data-xf-list-type="ol">Exploration-driven sandbox. I want to run what I have called the “campaign as science experiment”. We establish what the campaign is about and play to see whether the players can do it.</li> <li data-xf-list-type="ol">Post recaps. I try to put session recaps in the 5-words commentary thread with discussions of how mechanics work. I’ve missed a few sessions here and there, but I’ve posted quite a few of them.</li> <li data-xf-list-type="ol">It needs to be reasonable. I mean that literally (not figuratively). Players should be able to reason about how things work and make informed decision. Consequently, there should be very little hidden information.</li> <li data-xf-list-type="ol">Avoid confusing players. If players are confused by something at first, they’ll probably be confused about it again later at an inopportune time. Keep things simple and avoid special cases.</li> <li data-xf-list-type="ol">All tech is on the table. Consider other tabletop RPGs, board games, and video games as sources of ideas for how to solve problems. Don’t do stuff just for the sake of carrying on tradition.</li> <li data-xf-list-type="ol">Do not provide mechanics for everything. There should be a core set of mechanics that can be used to adjudicate a variety of situations.</li> <li data-xf-list-type="ol">Do not depend on rulings. The mechanics should be complete enough that the GM does not need to improvise a mechanic. Having to do that is okay while designing the game, but it’s a non-goal of the complete system.</li> <li data-xf-list-type="ol">Manage conflicts of interest. There is a conflict of interest between adjudicating the game and playing a character. When to allow exercise of discretion (adjudication) should be handled systemically.</li> <li data-xf-list-type="ol">Use system to manage the sense of a living world. Factions, events, etc should be delegated to the system as part of implementing #11.</li> <li data-xf-list-type="ol">Use abstractions but keep things feeling real-ish. The system is designed for a specific setting. There are not pages of polearms. Technology is fantasy-ish, but it did not happen in a vacuum.</li> <li data-xf-list-type="ol">Design for limited prep. I’m lazy. I want to run a sandbox hexcrawl without prepping one. The system should facilitate this in a fair way. #11 and #12 are important to this point.</li> <li data-xf-list-type="ol">The milieu is D&D-ish, but the game is not D&D. I have a fantasy setting, classes, magic, etc. Characters have attributes and skills. There is a specific flavor I want, but I’m not aiming for D&D per se.</li> <li data-xf-list-type="ol">Aim for compatibility with B/X content. Compatibility is defined as being able to use site-based adventures and translating monster math to my homebrew system. Story- and plot-based adventures should not work.</li> <li data-xf-list-type="ol">Play is player-driven. No plots. Do not prep them. The system can (and currently does) fight trying to impose a plot since the GM lacks discretion that could be used to push play in a specific direction.</li> <li data-xf-list-type="ol">Use archetypes but keep mechanical heft minimal. Multiple classes can fit on a page. Most of your customization comes from your choice of specialities.</li> <li data-xf-list-type="ol">Handle time and distance concretely. The chunk size varies (10-second rounds, 10-minute turns, weekly downtime, daily overland movement), but it should remain consistent. That helps with #6 and #13.</li> <li data-xf-list-type="ol">Resource management should matter. If the game is about exploration, there needs to be an element of skilled play in how you go about it. There are systems for handling attrition and supplies.</li> <li data-xf-list-type="ol">Aim for 16 pages A5 for the player-facing rules. This is a goal I have for the amount of rules I want players to have to know. It excludes things you pick like specialities, spells, etc nor procedures, GMing advice, etc.</li> </ol>There are some other aspects that are important, but they’re more a consequence of the design rather than a principle. For example, all magic uses MP. If it uses MP, it’s magical. This keeps it very simple to know whether an effect requires Resilience or Magic Resistance to resist. Does it use MP? Then magic. Otherwise, no. Everything has the same calculation for HP (4 × level + 5 × Endurance) and MP (3 × level), but I don’t consider that a principle either. Same for armor and mitigation, which has had several revisions with very different designs.</blockquote>

Verification