Many new developers are met with advice that their idea doesn't really matter, but how valuable are they really?
Around 6 years ago or so, 2004 or something, I started looking around for advice directed at budding game developers. At the time I was mostly looking around to see where and how I should start in on my big game idea that I had rolling around in my head for enough time that I decided to try my hand at making it.
It wasn't long until I found the famous Sloperama post on ideas. But I didn't believe it, and I don't think a lot of new developers do either. But it is true. Sort of...
While Tom has good reason to write something like this intended for game dev tenderfoots, I think this nugget of advice can have a decent negative effect on what more experienced developers decide to work on, or even prototype.
So my post is directed towards developers with a few polished games under their belt. To stay with the Boy Scout ranking system, these developers would be First Class or Star. Not necessarily Eagle Scouts [Miyamoto?], but know how to tie a square-knot no problem. They're comfortable with the execution of the game idea, working on usability, play-testing and have a general understanding of good and bad design. I'm not saying there's some sort of ceiling on any of these, but I think there's a point you reach where you feel like you're "in your cockpit" [Stolen from Mike] when you're making whatever it is that you're making.
I think the reason Tom Sloper wrote that article, and so many other veterans follow with the same advice for designers starting out, is due to the fact that many a first timer looking to promote their game solely based on the idea of it is often touting an idea that doesn't excite people experienced in game development. That's not all that surprising, though if you've made a few games. Or even one.
I'm not excited by my Big Ideas that started me off on this path in the first place. In fact, a friend asked about "my first love" just last night and he seemed disappointed that I wasn't excited anymore by the idea, like I had lost something along the way. But I'd argue the opposite, I've actually gained something and that's the ability to understand my limits [temporary] as a developer at this point in time and what that means for the games I want to make.
In the beginning I would let ideas run wild with features, story and content. They were sprawling epics of games that would take decades to create with even a medium sized team, but I didn't care. I was a teenager in love. Now though, an idea of that scope can't even get me off the couch because it's too big to understand really quickly. Not that a large idea can't be great, but it certainly is much harder to test against and I have less experience with that. That's just me, though.
As I grow as a developer I temper my taste for the game ideas that we come up with and I think more developers should take notice and give ourselves a little more credit as designers. Our latest game, due out in a week or so, is a product of really hashing out ideas based on an abstract concept and trusting our gut for that Eureka moment. I'm not saying it will be typical but the first time we tried doing the brainstorm-room thing, as more experienced developers, it worked. Though it seemed that throughout the process, the important thing was not to settle on good-enough. We had plenty of decent ideas that could have been decent games, but we weren't excited about those.
For this session we settled on a word or phrase [parallax scrolling] and used it as a starting point to drive the brainstorm. Just about all of our games are centered around one mechanic that seeds teh rest of the game. If we hold true to that mechanic we feel like the mechanic itself will form into something cool and interesting. Anyway, "parallax" went to "speed", into a discussion about speed and the feeling of going fast and how awesome that is, into talking about propulsion types and eventually into the final solution which was the Eureka moment. It was incredibly obvious to us both simultaneously that we realized it had to be prototyped immediately. I went into my room and created a mockup while Mike made a control-scheme prototype. And we had it.
A lot of my views on ideas now are driven by the experience, and while it may never happen again and I could be totally wrong, I feel like we need to trust ourselves as developers more often and put a little more faith into our ideas, even if they have burned us in the past with those terribly overblown growing-pain game projects that we all embarked on when wide eyed and green. Find a project that excites you in all areas that need exciting! Scope. Style. Gameplay. Innovation? You can have 'em all, just hold out for the right one and bounce ideas off each other. It's not like we have a checklist of things that make for a good or bad game project, it's just what our tastes have become so we don't need to check them against some sort of rote list or anything, we just kind of know.
I feel like that's also one really important facet of settling in on an idea [as opposed to rapid prototyping multiple ideas]. Most often, those early game projects that I spent years translating into worthless design documents were solely from my brain, and that's a problem! Our brains like to give themselves credit when they come up with something "new" so that colors the idea in a favorable light. If you have another brain around that can't help but give you "big ups" for an idea it didn't completely have, then you probably know you're onto something.
Anyway, just wanted to ramble on that for a bit, something I've been thinking about while on some downtime. Also, you should know that there are many ways to generate ideas and prototypes. This is just what worked for us last time and we'll probably try it again for the next game. I'm all for people coming up with personal ideas as a means of expression [I do that also] or shotgun prototypes or picking random ideas off a dartboard. Whatever works!