How to (Not) Help Other Designers

December 10, 2010

Several things have happened recently that have gotten me thinking about the best methods for helping other game designers with their projects:

In the latter case, I found myself thinking: “Oh man, I have all these clever ideas about how to make a platforming card game; I should totally tell Joe so he can incorporate them!” But then I thought: “Wait, is that going to actually be helpful to Joe, or would I just be dumping stuff on him that’s not helpful to realizing his vision?”

So, upon reflection, here are the design stages I’ve seen and my thoughts on how best to be of help to other designers:

Initial Brainstorming and Drafting

There’s actually a lot that you can do at this point to help people out; it’s just that would-be helpers typically do the wrong thing. In my experience, what people really need during this stage is:

  1. encouragement (“This sounds awesome! I can’t wait to see more!”); and
  2. support for talking out their own ideas (mostly by you saying: “Tell me more about that”).

When the designer is just beginning to flesh things out and create some structure for their game, what they generally DON’T need is other people providing feedback on specific aspects of what they are doing — which are already tentative — and attempting (intentionally or not) to influence the direction the game is taking. Feedback at early stages mostly serves to dilute the original clarity of purpose and vision, creating more uncertainty or (in some cases) splitting the designer’s excitement in a number of different conflicting directions that won’t easily be combined in a single, workable draft.

To put it more directly: getting specific feedback before the game itself has really taken definite shape can scuttle the entire project. Even without outside feedback, the designer can sometimes scuttle themselves by overthinking things or “overdesigning” in the beginning, questioning each part of the design before things have really come together. Without a firm grasp of what the game is going to be like, there’s no way of knowing if a specific mechanic is good or bad. Better to leave things as placeholders and continue on, coming back and fixing them — if necessary — later.

The problems with “feedback on brainstorming” is really, as far as I can tell, largely what’s led to the restructuring of how design support happens on The Forge. The Indie Game Design forum there was traditionally the place where a lot of people sought and received feedback way too early, scuttling many a worthy (and unworthy) project. Basically, it was a lot of jabber that didn’t necessarily lead to designers being supported and games being developed.

However, I think we DO still need places in which to provide quality support for people in the initial stages. But we need to build a culture around early feedback that is really about providing enthusiasm and asking “Tell me more about that”; one in which efforts to provide specific feedback at early stages is discouraged (though maybe not ruthlessly crushed). It’s not clear that Praxis is the place for that, but perhaps.

Once You Have a Working Draft

This is when you need feedback, ideally from other people who are actually interested in playing your game; or, really, playing the game that you claim your game will be, when it is polished up.

What you DON’T need is people giving you feedback on your initial design when they have no interest or intention of ever playing your game. They are not sympathetic and supportive readers who have the interests of you and your game in mind; though they may think that have only the best interests, what they really want to do (and they may not even be conscious of this) is convince you to turn your game into something else, some other game that they actually want it to be (and presumably, that they are actually interested in playing). And that kind of feedback is something we definitely have to resist all the way though to the end.

That said, distinguishing between supportive and unsupportive feedback is much more difficult in practice, since the designer may not be especially clear — either explicitly or even just in their own mind — about what they want their game to be. But we should get better at asking that FIRST before jumping in and telling people which directions they should explore in attempting to polish up working drafts.

7 Responses to “How to (Not) Help Other Designers”

  1. I partially disagree.

    If you do not have a clear premise and a focused concept, then early feedback is sure to dilute your work and confuse you.

    But sometimes you simply have no idea about how to solve something. You know where you want to go, you don’t know which one is the best path to go there. And sometimes some specific feedback can help a lot. Even if the ideas are not to your liking, or not toward the direction you want to go. (Many times one goes “no, no, that’s not what I want; I’d rather do this… wait a minute…”)

    Being very specific about what sort of feedback you want (and not trying to please everyone or include everything) helps, of course.

    But all of that can work a lot, even before you have a complete working draft.

    So, in other words: a firm concept, YES. A complete draft, not necessarily.

  2. buriedwithoutceremony Says:

    Hey Jonathan,

    This is how you support someone in the tentative stages of anything: ask them what support looks like. Don’t lead that question with the expectation that you’ll have a role to jump in and fill, necessarily.

    Incidentally, if you were to ask me what kind of support I’m looking for, I’d share this story:

    One thing I’m really liking in Jump Land is starting to tell people how the game is structured, and then having them jump in and offer up card ideas. “oooh, you could have a card that let’s you pick up a dude and throw him at another dude! It could be called Chuck-a-Schmuck!”

    …that was just an invented example, but Chuck-a-Schmuck is the best idea for a card ever.

    On topic again:
    A good sentence is: “Hey, I know this is super early in the project, but your game sounds neat. Are you looking for any sort of support, right now? I’d love to lend a hand.”

    non-intrusive, non-demanding, casual, open-ended.

    You’re absolutely right that it’s best not to barrage someone with hard critique, early on. But I think offering support in the form of a question… that can’t happen too early.

  3. Matthijs Says:

    Great post, Jonathan. I’ve been trying to put this into words in different ways, but you sum it up very nicely.

  4. Steve Says:

    This is really useful. I’ve had some recent experiences that support what you’re saying in the ‘Initial Brainstorming’ stages. And I noticed it can be quite hard to tell someone to back off in a way that’s both polite and encourages them to stay interested in the game once it’s been more developed.

    Ron said something on the Forge recently that also struck me as similarly true, about the early stages of playtesting being for colour and fun only, and then only taking a serious look at the mechanics of your game later in the process.

    McDaldno: I like your approach.

  5. Damian: I see your point. I don’t think you necessarily need a full draft of the entire game in order to get feedback, but you definitely need a relatively solid draft of whatever you want to get feedback on. Does that make sense? So, if you want to talk about your resolution mechanics, you need a draft of your resolution mechanics.

    Joe: I think you’re right, but I also think that a lot of designers (both those with and without a lot of design experience) don’t really know what they want from other people. A lot of people think they want criticism and feedback when that’s not really going to be helpful to them in the early stages. I do worry a bit about being patronizing and assuming that we know what someone needs more than they do, but I’ve just seem early feedback scuttle way too many games to think that it’s not a common problem.

    Matthijs: Thanks!

    Steve: Yeah, telling people to back off is hard. I think that’s why a lot of folks like having a draft before asking for attention, because then you don’t have to hold them back.

    Playtesting is a step I didn’t really get to here, but Ron’s comment is interesting. I’ll have to think about that.

  6. Heya Johnathan,

    Great post. This is something I think could come in really handy at Praxis. Thanks for bringing up this topic for discussion.



  7. I thought I commented on this, but it looks like I didn’t. That comment: This is a great post, well timed, right when I needed it. I’m always struggling with when to share something that’s mid-development; weighing the advantages of actual play versus the potential to let the wind out of the jar can be nerve-wracking for me. This was some much-needed big-picture perspective right when I needed it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: