[Musings] So, you want me to look at your wargame rules? A checklist.
As someone who loves tinkering with homebrews for all kinds of gaming, as well as a (slow) writer of my own original rulesets, I find it rewarding to do playtests and read-throughs of up-and-coming systems from other developers. Lately, I have found myself doing this for five different games from four devs.
I decided to write this blog post as a catch-all of the format I try to use when reading, critiquing, and playtesting rules, mainly so I can send said devs here as a baseline for what they can expect from me.
What You Get:
1. I am a veteran wargamer and TTRPG player.
My foray into TTRPGs started in the late '80s whereas wargaming started with WFB in '91. I have also played board games to a somewhat lesser extent from that time onwards. I love a vast array of rulesets and settings in different gaming styles and generally prefer either super-simple systems that do exactly what they say on the can, or heavy granularity and crunch. The middle of the road seldom excites me, and I tend to get bored fast with systems that at the surface level are easy but become cumbersome due to a vast array of special rules.
2. I am not a native English speaker.
English is in fact my third language and I approach the readability in your rules from that perspective. Is it too verbose without being clear? Do terms you use take on a different meaning to someone outside your grammar-o-sphere (i.e., British or American English mainly)? If something reads weird to me, I often go to the dictionary (Merriam-Webster being the favorite) to look at the proper definitions of terms to decide if I am right or just mistaken about the word's true meaning. Readability and flow are big parts of understanding rules, and while this can be done in many ways, clunkiness is something I tend to notice quickly.
3. I don't care if I like your game or not.
I first and foremost base my testing and/or reading on disregarding my own likes and dislikes. It is your game, and I am only here to test it from various angles while trying to find errors in what is written rather than asking myself, "how much do I want to play this?"
4. I LARP as a newcomer to the hobby.
The second principle I try to adhere to is to read from the perspective of a new gamer. This means I will focus on not filling in the gaps too much in your writing or mechanics IF you are writing your game towards a general group of players. As we get somewhat used to wargaming, we can often play a new game straight off the Quick Reference Sheet and just use the rulebook itself as a reference piece when something comes up that isn't specified too well on the QRS. Newer players can't do this, and it's from that starting point I try to test from, again, only if your ruleset is written with new players in mind.
5. I write lists as feedback.
I try to give my feedback in a page-to-page and paragraph-to-paragraph list of things I find problematic and/or might need more polish to be explained better. I tend to use questions here and there as feedback; these are mainly meant for you to answer for yourself, as they are meant as rhetorical.
6. Your game, your rules.
I try my best to stay clear of giving you suggestions on rule mechanics unless you specifically have asked me to, or if you have a very broad "just test my game bro"-assignment to me as a tester and I slip into a more editorial mindset by mistake. Sometimes the easiest way to give feedback on things might be to show an example on how it can be made differently, so don’t view any breaking of this point as an attempt to get you to rewrite the rule to what I suggested.
7. I will not talk about your game unless you want me to.
I won't disclose anything I am testing to others. If you ask me to keep quiet about the game, idea, or what you are working on, I will. Let me know if you'd like me to drop hints about your work-in-progress publicly.
8. I don’t use any kind of AI or LMM when I playtest.
Because you can do that yourself, and you want a person to do it instead.
What I Expect:
1. Try to be specific with what you want me to look at.
This can be as simple as "Can I publish this on itch.io now?" and as specific as "Is it easy to understand how Dashing works?". I prefer a number of specifics over the more chunky "look at all of my game"-request, unless you are in a late beta stage of development. The broader your request, the shorter the feedback—or a massive teardown explaining all the holes you have. Neither is beneficial for your game.
2. Be clear with how much of an editor you want me to be.
Let me know if you are completely against editorial feedback regarding rule phrasing, layout, and readability. Decide how much nitpicking you want me to do. That is generally something that shouldn't be done in early versions, as any type of writing often needs a lot of editing no matter who we are as writers.
3. Let me know how pressing it is to get the feedback.
Playtesting is one of many hobbies for me, but with an easily excitable brain, I can often overdo it and stress over not doing stuff for others fast enough. If you don't need the feedback "now", please let me know. It is good to set clear deadlines, so let's do it.
4. Tell me if you have any pain points in your rules.
This can be anything from being self-conscious about your prose to the feeling of just not getting a mechanic right. Let me know if you want me to disregard or focus on that part, and what kind of feedback you want on it.
5. A simple thanks is cool. If it comes with a promise that you would be glad to check out one of my upcoming projects in the future, even cooler.
/Skald