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.

Game Design ≈ Paleontology

As I continue going through the design process, I’m noticing parallels to something that Stephen King talks about in On Writing.

Stephen describes storytelling/writing as if it were a paleontological dig. The ‘perfect’ story that fits your mental image is before you – right there, just beneath the surface. You just have to excavate it. You have tools to assist you: in writing it’s things like vocabulary and dialogue. But in the end, it’s you who has to exercise judgement, choose the right tools, exhibit patience, and ultimately unearth the final product.

In game design, I’m encountering a similar process. Your tools are mechanics, theme, playtesting, graphics, etc. You have to exercise judgment. You have to be patient. You have to choose the right tools and Design With Intent. What’s particularly fascinating, however, is the art of combining the tools and judgment. Through this process we can carefully extract a design – methodically and carefully revealing the prize beneath the mud and clutter. We can also ignore a productive process and either smash the design by using a jackhammer of forced mechanics, or take so long dusting away with a brush of re-balancing that nothing ever materializes.

Above all, it’s the notion of revealing rather than creating that’s proving powerful. Creating something from nothing implies forced connections and overcoming difficulty through power of will. While perseverance and technical skill are good things, there’s something to be said from the natural flow that comes from discovering and revealing. When’s the last time you finished a game and said “Wow! You can really tell the designer spent a lot of time forcing this mechanic/theme/win condition to work! It’s amazing!”? Obviously never, and you’d never want to. But I would surely love to say “Wow! That game flowed so well – I got completely sucked in and didn’t even notice I was playing a game!”. That’s the beauty and power of uncovering the natural versus forcing your preferences and guesses.

So I’ll be keeping this in mind as I move forward. My goal is not to a series of obstacles. My goal is to present an experience. My goal is to unleash fun.

Form Fits Function

I was in the process of designing some cards yesterday when I realized that they were unplayable. They weren’t unplayable because they weren’t balanced, or they weren’t of sufficient quality. No, they were unplayable because they just sucked to use.
With my most recent iteration of cards, I wanted to make the card text larger and make stacking more streamlined. Unfortunately, my “brilliant” solution for this ended up being garbage; the horizontal layout I had hoped to use just didn’t make sense when you held and played the cards. I kept craning my neck to see what the text/symbols were, and half the time my iconography was covered up. Nobody is going to hold cards in their hand horizontally, and we’re so comfortable with placing vertically-oriented sets from our hands that it’s weird to ask people to hold the cards one way and play them another. A game should be fun – not an imposition. I needed to redesign their layout based on how they’d actually be used.
For my particular situation, I thankfully had read Joseph Z Chen’s great article on card design and remembered it during my self-playtest. I won’t rehash it here because it’s excellent and you should go read it. But I will say that it saved me a ton of time and I now have some ideas on how to move forward.
The further point I want to make, however, is how important it is to keep the overall experience in mind when designing a game (or anything for that matter). The title of this article comes from a commonly cited (and frequently unimplemented, based on my experience as a structural engineer) phrase in the architecture community. The form of your game, its mechanics, its components, etc. should fit their intended use. You wouldn’t design a 12-person party game that takes 2 hours to complete, right? Keeping the notion of form fitting function on the top of your mind as you design and test can, as I found out, help save a ton of time and heartache.
More importantly, it can also help save you from a slow, drawn-out project failure.

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.