Design vs. Development: My Bane

Design vs. Development: My Bane

In the last two years, I have completed 91 products for Post World Games, not to mention two for souljar (plus work on two more), six for Pinnacle, one for Floating Vagabond, and some graphic design projects here in there. And while it sounds like I’m bragging, I assure you I am not.

Everyone has a designer niche. At least, anyone whose made more than three things has a designer niche. Reiner Knizia is very good at puzzles with one dynamic quirk that turns it all into a game. Robin Laws is a genius at taking simple concepts and making them noteworthy. John Harper continually astounds me with his world ideas, though I wish he’d step away from AW for a moment.

If I have a niche, it’s the speed at which I write and design. But that didn’t happen overnight.

(Actually, it did. My first book in the gaming industry, I once did 10,000 words in a day.)

But that doesn’t mean all those words were good and I’ve certainly learned to write more concisely now. The Protocol Series is proof of that.

Of late, I’ve been inventing more and more ideas for myself. I have 20 different projects in development.

20.

Plus 11 Toolcard decks.

And that’s not a good thing. I’m the bottleneck of a system I’ve created where the design AND development have to go through me. Ask anyone in gaming, no one should develop their own work. But Post World Games isn’t profitable enough to hire someone and I’m not slowing down on what I design, so I’m reaching a point where I will eventually just curl into a ball and never come out again.

Hyperbole aside, the role of the designer and developer are very different. I’ll give you an example.

I wrote a game called The Last 12 Hours.

The concept works. The subculture of films it draws from is narrow (so it’s hard to market the concept). And after three playtests, it is clear that the mechanics are solid.

BUT.

Because of the nature of this game, it needs A LOT of advice, navigating people through the exact kind of game it is. Which is fine, I have no problem making some games anemic (the furnace is 1 page), while making some other games fatter (this is already 40 pages and needs about 20 more pages of advice).

But all of that takes time to do.

I’ve already spent 20 hours writing and another 15 hours playing and developing it. I suspect more graphics, writing and editing, will be another 20 hours of work.

And this is just one game of about 10 I expect to have out in the next three to four months!

All of this back end work is development time, not design time. Which brings me to my point: Designing games is easy. I think I’ve proved that with over 100 products in the last two years, but development is the tough skill. Development means taking a design idea, cutting out the fat, exposing the weaknesses, adding the soft edges and graphics that make the game easier to use, and polishing it all up so it doesn’t look like someone’s dog chewed on it.

I can come up with a new dice mechanic for an RPG in about 10-15 minutes. But it would take two hours to write it up effectively and then a week for a developer to make it useable. The developer’s skill set cannot be underscored enough.

And because I’m just one guy, it slows me down a lot.

In the past two years, I’ve had over a dozen people approach me to be interns, helpers, designers, or to just be involved in game design in some capacity. And I always do the same thing. I had them an unfinished game document (of late, the same one), and I ask them to finish it. Not to edit it. To finish it. Show me what you would do with this product. Don’t change the rules, fix the presentation, organization, and flow. Show me what YOU would do with this game.

You want to be a writer? Learn to be an editor first.

You want to be a designer? Learn to a developer first.

The world doesn’t need anymore proofreaders.

If you don’t understand how your work affects the project, you’ll never be effective as a designer, writer, artist, graphic designer, and so on. The best lesson I can teach anyone is how to effectively deconstruct something and build it back again. That’s what a good developer does.

To date, none of the people who tried out as ‘interns’ for me, succeeded at fixing the document. No one was able to turn a concept into a finished product. Presently, that document is in yet another pair of hands and has been for almost a month. We’ll see what comes of it.