Several things have happened recently that have gotten me thinking about the best methods for helping other game designers with their projects:
- First, Game Chef 2010 is almost over.
- Second, the Forge has moved into its “Winter Phase” which includes creating a new Game Development forum that requires those seeking help to have some kind of working document in hand.
- Finally, Joe Mcdaldno has started a new game project inspired by old school platforming video games.
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:
- encouragement (“This sounds awesome! I can’t wait to see more!”); and
- 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.