Backseat Designer: Laying down the ground rules.

For those who don't know my background: Rather than trying to land a career in one of the relevant industries, I just to dedicate my spare time to 'honing my craft' as a game designer, pushing myself to regularly tackle new challenges (with a pragmatic focus on tabletop games). No plan beyond that, I didn't even have any idea whether the skillset this would produce would carry over to video games (turns out it does, as my experiences with the Global Game Jam have verified). Just "become a better game designer."

One of the not-so-surprising results of this approach is that I now automatically analyze any game I see in action, especially when I'm playing it myself. This isn't about critiquing the game (or at least, passing judgment on it)- I'm getting two things out of the process. First, it helps me learn from other designer's work; I'll notice that the experience is (or fails to be) fun/compelling in a way I can't adequately explain, and start working out just how the game pulled that off. The second reason I do this is to give my mental game design muscles a workout- spotting areas of the game that could be improved on (be it from bad to passable or good to great) and then working out precisely how one could carry those improvements out.

Of course, anyone can say "Gosh, it should would be nice if this game was even cooler." Playing the backseat game designer (or as Tom Francis calls it, amateur hour) calls for a higher standard- one that involves several self-imposed rules.

-I will be mindful that my ideas are untested. Game mechanics never work quite like you envision them. Sure, you can get better at anticipating how they'll play out (one recent example for me was the playtests for Court d'Capitate last christmas, which astonishingly revealed that the rules worked almost exactly as I'd planned). But that's still a long ways from knowing what the experience will be like for the player, i.e. whether it will be *fun*.
-My ideas cannot require additional development resources. The only alternative to changes which would cost a pittance (at least as far as I can see) in terms of time and effort is ideas which could have saved resources, assuming the dev team had used them in place of the existing approach. In cases where my ideas are intended for future sequels, I must at least stop short of advocating something the dev team would need to go out of their way to fit into their development process.
-I must be able to clearly explain how my proposal will benefit the game. If I can't explain my reasons to both fellow game designers and laymen in a clear and concise manner, I'm not going to be an effective part of any team game development effort.
-I will not let the benefit of hindsight go to my head. Even if it turns out that I have managed to come up with a better approach than someone who worked on a game full-time, that still doesn't mean I would have done a better job in their situation. (But [companyname] should totally give me an unpaid internship so we can find out.)

Any other pitfalls I'm neglecting to consider?

Image drawn by Tim Kreider. Hope no one minds the profanity.