So this will be short and sweet: I just wanted to quickly document where I’m at and where I’m going in the game design process (given the two-week hiatus in blog posts).
- The past two weeks, aside from being phenomenally swamped with life, I’ve been wrapping up a few bits of playtesting for other designers. It’s been phenomenally instructive (you can read about my overall thoughts in my previous post).
- I’ve been documenting a number of kernel ideas for games. Some of them are fast, word building card games. Some are more substantial, including a colony survival/light RPG game. One of them is a terribly-themed, wedding-planning game, but I like the overall structure that was the impetus for the game, so wanted to roll with it to see if I could uncover a theme that sucks less.
- Overall, I’ve been doing a fair bit of background work – basically, things outside of directly designing my games. The thought process is to alternate between game design and these alternate tasks so that I don’t get too bogged down the minutiae of game design or get frustrated when I get stuck. Also, it’s to ensure that I’m constantly drawing on new sources, not just getting stuck in a narrow track of skills/thoughts.
So, the plan for the next week is to take what I’ve learned and jump back into the games I’ve started designing (mainly the colony survival and light word games).
I recently took some time to blind playtest the games of other designers and wanted to share my experiences. The short version is that I’m fantastically glad I did. I think everyone interested in gaming should do some playtesting (if for no reason other than an intellectual exploration and appreciation of the design process).
The slightly longer answer is that I think there’s a lot to be learned from stepping outside your own creative process to really evaluate the work of others. You get to objectively see what works, what doesn’t, what’s polished, and what’s confusing – all without the fog of design to obscure things. Here are some of my takeaways:
How I Anticipate my Playtests Will Impact my Game Development:
- Spend ample time on the rulebooks, focusing on overview and simplicity
- Start with an overly-verbose, excessively long, and tediously-thorough rulebook with plenty of explainer graphics, reminders, and overviews
- Spend multiple edits paring down the text; increasing clarity and reducing walls of text
- Play through the game alone several times with an emphasis on questioning everything
- It’s impossible to be truly objective, but reading the rulebook verbatim and not skipping steps should help reduce some of the blind-playtest confusion
- Really focus on the balance between ‘easy-to-learn’ and depth of replay
- Easy-to-learn games are fantastic for adoption, but often fizzle out quickly
- I want to try and inject complexity into my games through content and varying strategies rather than an increased number of mechanics and/or required steps. Tension via options per decision + concise # decisions >> # Options via multiple decisions and rules
How I Plan to Utilize Playtesters for My Future Games:
- Make it clear
- If it’s lengthy, or requires many components be supplied, make sure the playtesters know up front
- Provide discrete questions to guide their review. “Did you like the game? What would you change?” is difficult to answer well.
- Make it easy
- PDF PNP files that don’t need explanation on printing, cutting, or assembly
- Make it consistent
- Web forms aren’t sexy, but they should be great for getting and tracking consistent data points
- One person citing a problem isn’t as powerful as ten people citing the same problem
- Provide an incentive
- It doesn’t have to be grandiose – a simple mention as a playtester on the website or rulebook to give credit is far more than nothing
- Can be substantial if it makes sense (e.g. lengthy game)
My Thoughts for Those Who Wish to Playtest:
- Really consider why you want to playtest and what value you can provide to the designer
- Even if you’re not a designer – think about how they might utilize your feedback
- Being nice isn’t helpful if the game is garbage, but neither is slamming their game without explanation
- Your observations are likely close to priceless, and your proposed solutions are likely close to worthless
- Don’t worry about trying to solve their problems (that’s their job), but being thorough and precise is crucial; you try to imagine coming up with a solution for “the setup didn’t make sense”.
- Get basic information about the game ahead of time
- Things like number of players, expected time of play, required components, etc.
- The goal is to ensure that you have an understanding of what you’re taking on so you can follow through
- At least one of the games I playtested ended up requiring WAY more time than I expected, which resulted in some longer, more frustrating nights on my end (as I wanted to keep my word to the designer)
- DON’T, however, be tempted to get too much information about the game if you’re blind playtesting
- Every piece of gameplay information you have undermines your ability to objectively stumble through the rules
- No playthrough videos, no overview of the setup…nothing
- If you’re getting stuck, either because the rules or rulebook are broken or unclear, come up with something plausible and keep moving
- Something might clarify itself later in the game
- Even if the game is broken, you can still provide insight into the rest of the game (and problems), by moving past the sticking point
I often write terribly. I’ll ramble and ramble – starting at one idea and ending at another with naught but sleepy pontification between. This type of writing doesn’t even deserve a clever name. I’ll call it Monkey Garbage.
Monkey Garbage typically stems from the combination of reckless excitement and a desire for productivity. I get an idea for an article/post and start vomiting words on the page. The post on Pareto the Craftsman is a good example: I went down the rabbit hole, only to find out that I no longer had anything resembling a cohesive product.
The real problem with Monkey Garbage is the time it takes from doing more productive things. I’ll subconsciously think I’ll be working hard, but won’t realize the hour I’ve wasted writing crap and the hour after I’ve wasted fixing it. What’s worse, writing is involved in almost everything I do, so the problem compounds. Although a blog post, an email, and a rule book all require different mindsets and skills, they still need to convey data effectively and are susceptible to time distortion.
Fortunately, I think the fix (or at least a starting fix) is simple. For each blog/article/quip moving forward, there are two questions that I need to answer before I start writing:
- What am I trying to talk about?
- e.g. how I noticed I often write inefficiently and how I think I can improve
- What value am I adding to the reader?
- e.g. my initial proposed solution to solving this problem, which would prove valuable if they experience the same trouble I do
Basically, this method is tricking my mind into starting an outlining process by just answering two questions (rather than fill in a skeleton of bullet points). I hate outlines, but also understand how they can be useful. Limiting my focus to the two points above serves as a spoonful of a sugar for my writer’s medicine.
It’s what I’m going with for now – let me know if you’ve found something that works best for you.