Ascii Dreams draws attention to a comment thread discussion following coverage of the Experimental Gameplay Workshop at this year’s GDC. One of the games featured at the workshop, Lost in the Static, was based on an idea explicitly borrowed from a list of 300 game concepts released by indie developer writer Squidi as a creative exercise.

In the discussion, Squidi expresses frustration that a game based on his concept got attention at the GDC, while his proposal to discuss the 300 games list he created was rejected.

So, for example, by virtue of spending two days hacking together a generic platforming game, Lost in the Static is elevated above the original inspiration that spawned it? Is that why it is up there on the stage? Because of the code or because of the gimmick? It’s up there on behalf of sweat, not talent. What message does that send?

Two of the EGW organizers as well as Sean Barrett, the creator of Lost in the Static, respond to Squidi’s complaint. Sean gives very explicit credit to Squidi, as he did at the EGW, but he makes a good case against dismissing his contribution to the game’s design as trivial.

Despite the slightly flamewar-ish nature of the end of the thread, there’s a very foundational lesson to be learned here about game design. Squidi doesn’t seem to get it, but the other (very experienced) developers in discussion with him do their best to bring it to light. The way I’ve tried to explain it over the last few years goes something like this:

Ideas are cheap.

Now, I think I’ve probably undersold the creative process (including my own) by phrasing it that way; I’ve run short on brilliant design ideas in the past and it can take deliberate effort to push oneself creatively when working on a project. So sometimes ideas can be hard despite their cheapness.

But an idea is not a design. I’ve seen this misconception in game design, engineering, and I’m starting to see it in visual design as well. Someone (possibly myself) comes up with an idea which, in their mind, will be fantastic and revolutionize things and probably make them bucketloads of money. All they need is to find someone to implement the details, and success!

The problem is that in game design, as well as in almost any endeavor, the design is quite literally in the details. It’s possible to create both a well-designed fun game and a horribly boring game which both stay faithful to the same original concept. (Adding “It must be fun and awesome!” to the concept description is cheating, in the thought experiment as well as real life.) Like probably everyone else who’s ever played a game, I used to think, “Wouldn’t it be great to be the one who comes up with all the cool ideas, and everyone else can do the hard work? Being a game designer would be great!” The problem is, that doesn’t describe a game designer. (Maybe it describes the type of Executive Producer or Studio CEO who likes to drop by and periodically insist that Feature X be added to the game, but trust me, that doesn’t make you a hero.)

Now, many high-level concepts can sound great on paper but completely fall apart when you try to implement them. This is why engineers shake their heads when someone “invents” a revolutionary new energy storage mechanism which falls apart the moment you do any back-of-the-napkin calculations. Now, this does mean that there are “bad ideas”, so ideas aren’t completely without value. But there are two hurdles to overcome. You may not know an idea is bad until you look at the implementation details, or have enough experience to see them coming. Even if an idea isn’t bad at its core, it still requires good design work to take it from “interesting (or marketable) idea” to “great game design”.

Game design is, like any form of design work, about crafting the details into a coherent experience. The game concept or idea is a target, but there are many ways of getting there and not all of them will succeed. Good design work needs to address many different concerns such as complexity, accessibility, aesthetics, technical limitations, and more – and none of these concerns can be fully answered without specific, hard details.