Status Update – 4/19/2017

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).


Playtesting: Self-Imposed Objectivity

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
Happy playtesting!

Writing that Surpasses Monkey Garbage 

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.

Pareto the Craftsman

In an attempt to incorporate some of the experience I’ve gained in creative projects, I’ve decided to implement a framework for my efforts in the upcoming week. Although the goal is to better guide my journey in designing a board game, I think it’s certainly applicable to any boutique-level endeavor.

I’m a firm believer that any creative project needs to be both effectively done AND be of exceptional quality. So for my proposed framework, I want to focus on the initial speed and efficiency of action required to iterate quickly. But I also want to keep a high-level perspective and track the elements that will eventually be required to produce a well-polished game.

The name I’m giving this framework is “Pareto the Craftsman”:

  • Pareto – smashing through the first 80% of game design as fast as I can so I can identify fatal flaws early on
  • Craftsman – Really honing in on the details and providing a polished, amazing product. I don’t really see another way to success as an individual, unknown, wanna-be designer

I find this idea of Pareto, not as an economist in an office but as a craftsman in his shop, to be quite powerful. He moves from task to task; swiftly and efficiently completing the portions of work that matter most so he can identify problems early on and work to resolve them. But after the major tasks are over, he sits down to finish the finely detailed work – sanding, painting, adjusting, finishing – so that the end result is of the quality expected of an artisan.

It’s this imagery that I want to keep in mind. It’s far easier to apply “What would Pareto the Craftsman do?” to multiple situations than to try and remember which inspirational quote needs to be applied to which step in the process.

I also want to share how I intend to implement this framework in my creative process. For me, this involves more than just going fast and working more. My aim is to create a structured focus on self-testing before playtesting, developing systems that scale, and being able to defer with impunity:

  • Self-testing is, in my mind, the fastest way of making early-stage progress
    • External/Blind playtesting is critical, but I suspect it will take an exceptional amount of time to conduct the tests and collect/parse the data
    • I want to smash through enough self-testing first so I’m not wasting time/resources on the slower efforts through other’s people’s insights
    • If I’m still going through games and finding glaring weaknesses/not having fun, there’s no reason other people need to tell me the product needs work
  • Developing systems that scale is an umbrella phrase for anything that might make design iterations faster/easier – both now and as things progress. The goal is to free up more brainpower for infusing quality during those iterations. Examples of this include:
    • Building a system for batching prototype card JPEGs/PDFs
    • Utilizing Tabletop Simulator to swap out/add/remove/edit components and rules on the fly
    • Adapting my working style to allow for more consistent throughput (via workflows on my phone and creating Google Docs that allow me to work anytime, anywhere)
  • Deferring with impunity is a concept that revolves around rapid memory dumping so ideas don’t get lost. Then I can go back to quickly iterating what’s important without the fear of losing potentially great concepts
    • I plan to use Evernote for this, again using workflows to speed up the process
    • Specifics including quickly tagging and tracking potential mechanics, theme changes, rule changes etc.
    • When I finally get to the last 20% of development, I can then quickly pull up the tagged notes for reference

You’ll notice that none of the above mentions how I plan to be a craftsman. That’s because it’s not yet time for that. The last point – deferring with impunity – is intended to set myself up for future craftsmanship success. I’m fully aware of how important it is to produce something amazing. The problem, for me at least, lies in letting the desire to produce something amazing get in the way of producing something viable (or at all). I need to stay mindful, in the moment, and let the desire and need for quality be noted, but not dwelled upon while it’s time to be moving quickly.

If you have any strategies you’ve found useful in navigating between moving fast and producing quality, let me know in the comments below!

Let Me See Your Package

So, um, what’s your project? What’s your company? Aren’t you the Ultra CEO Overlord of something? How are you packaging yourself?

My sincerest hope is that this post doesn’t stand the test of time. I hope to look back on it in a few weeks/months/years and realize that the lack of branding et al on this post/blog on March 10th, 2017 is hilariously no longer relevant. That said, there’s a whole lot of work to be done beforehand, and the only way for me to convey value right now is through the unadorned journey.

Yes, I could make up some random name for a company (that doesn’t yet exist) and an over-inflated, self-aggrandizing title (been there, done that, felt silly while doing it). Yes, I could share tidbits of the games I’m working on before they’re *cough* ready (I will). But for now, there’s no value to be conveyed to you by my doing so…so I’m not. The value is currently in the journey, in the process, in the trenches. Right now the games are barely more than ideas with rules and components that change daily.

Quoth the Gary Vee: Ideas are shit and execution is the game.

I’m sure there are things I could do via Twitter, Facebook, etc. that would help me manufacture an audience, and creating those accounts would be best served by having some package in which to wrap and contain my design efforts (i.e. a company or game). But the truth is, there just isn’t that much to say right now that isn’t best served by these posts. It wouldn’t help you. First, I want to focus my efforts on creating value (which is most effectively done via blog posts/articles). Then I’ll worry about distribution.

This is only post #10 – I sincerely doubt the tens of follower bots that would comprise my current social media audience will mind waiting a few days/weeks until this content has grown and coalesced.