Do you like solo?

Testing a solo variant of Masterwork

While Masterwork was originally conceived as a game for 2-4 players, I’m now testing a version that will allow players to go it alone. [Setting aside the argument that a ‘solo game’ is not actually a game at all, but a puzzle.]

There seems to be an increased interest in solo gaming, and the benefits are obvious: your gaming needs might not be met by the availability of people to play with, or perhaps you like to rapidly try different play strategies. Solo gaming is obviously a different experience, so I’m wondering: what do you get from it? Does ‘winning’ feel the same as when playing with other players? Are you rewarded with a different type of satisfaction?

So, do you play board games solo? If so, which ones? And what are the best and worst parts of solo play? Please message me (or comment below) and share your experiences!

/RonJohn

Box art reveal!

A hero image is worth a thousand words

Masterwork is design complete*! Woot! I’m excited to share with you this hero image of the box art for Masterwork. Getting to this milestone has been a long time coming and we’re getting very close to ‘Kickstarter ready’ (and print ready, for that matter). Hurray!

A huge thank you to everyone who has offered help, support, and positive words. Your well-wishes and positive vibes kept fuel in the tank to get all this graphic design done.

What I learned:
Don’t settle for your first pass at anything. While the older (temporary) box (see below) art was elegant, I was concerned that it didn’t offer enough shelf appeal and communicated very little about the game. ‘Apple-like’ – looked nice but a bit boring.

Older box art – clean but generic and a bit boring

The new art features the most famous painting of all time and shows some of the wood theme that is shared throughout all the game elements. On the final print packaging, it will look particularly good with a ‘Spot UV’ treatment, a transparent coating that makes the colors (especially the Gold ink) really vibrant and shiny and standout from the matte wood texture.

Soon I’ll be able to share actual photographs of the box art. Stay tuned!

/RonJohn

*Except for the rules, which will be validated by game testing at PDXAge this coming weekend. 🙂

The fast train out of Shitsville

99.9% of the time, the first version of anything is usually shit. Did da Vinci’s ‘Mona Lisa’ spring complete from his brush in one breezy afternoon? Umm, yeah, no. Success comes from trying something, assessing what you’ve done, measuring the distance between what you have and what you want, and making the right choices to move you closer to your goal. The challenge is that this process can take a while. Depending on what you’re making, it can take a really long time. So much so, it’s easy to give up before you’re done. Seth Godin calls this “The Dip”. Creating something great takes tenacity more than brilliance. It’s just a lot of work.

Coming from a tech development background, one tool I’ve found that translates well to other arenas of life is Iterative Development. Iterative development states that it’s critical to get your product to a workable state, and from that state, start progressively improving it over time. This is particularly helpful when it’s difficult to know how your product functions without user input. People have a hard time giving feedback on an idea instead of a thing.

This working method is incredibly useful in game development. It’s hard to know if mechanics work, if emotional engagement is there, if the game is even fun… if you can’t actually play it. The key here is to find the minimal viable product (MVP) – how little effort can you expend before you can start testing your ideas? The less you build before you test saves time; you’re not building things that will eventually go in the trash. It’s been said many times before, but I’ll repeat it here: the key to success is failing quickly. Get all the bad ideas out of the way. Or as I like to call it, getting on the fast train outta Shitsville.

Get all the bad ideas out of the way. Or as I like to call it, getting on the fast train outta Shitsville.

You can increase your chances of success by failing faster. By lowering the investment to get bad ideas out of the way, it’s easier to surface the good ones. You’re less likely to waste time following tangents and pursuing useless features. You’ll more quickly learn which bits are actually important and which don’t make the game better. Or even worse, which bits make the game unnecessarily long, more complicated, or less accessible.

Back in the early days of my career I frequently said the phrase “Don’t kill my babies!” By this I meant, don’t judge an initial design as a final product; recognize that it is the foundation upon which the final product will be built and give feedback accordingly. Now I realize that I shouldn’t have shared products before they were minimally viable; once they were, the feedback I received would be useful. It’s important to share your project as soon as they’re viable, and protect them until then.

Ok, what’s minimally viable?

Different creative ventures have different standards upon what is deemed minimally viable. And you should keep in mind the specific questions you’re trying to answer. A certain stage of development can viable to answer one type of question but unsuitable for another. For example, while making Masterwork, a very early prototype was sufficient to validate that the game mechanics would work. But that same prototype was unable to answer questions like, “Does the pacing feel right? Is the turn length sufficiently short that I don’t have to give non-active player something to do? Is the deck size balanced for the correct card probability?” Those questions got answered in later versions… when the game got to the MVP state necessary to answer those questions.

The process is to playtest, take in feedback, make changes, and produce another prototype as quickly as possible and test again. Masterwork had eight versions before final. That’s seven structural and visual prototypes that were produced, tested, and ultimately discarded. Certainly a lot, but probably not as many as there could have been if I hadn’t iterated quickly and early.

In a future post, I’ll describe some of the tricks I learned to help makes prototypes quickly. I am by no means an expert at this but I’m getting better and I feel these are important tools for every game maker to learn. You can’t just create it whole in your brain – you have to put it in front of players as much as possible and measure feedback and iterate. That’s how you take the fast train out of Shitsville.