Something I’ve heard for a while now, maybe it was from Chaim Gingold, or from Will Wright, and probably a bunch of other people is this: you should make the toy first, and the game later. Basically, you prototype the core interaction. Not as a game, but more as just a sensual experience.
For example, the moment that my Meggy Roguelike started coming together was when I had a dot moving around a scrolling map. It was not a game, but that core interaction of moving around the map was so sensually delightful I knew that the game would be fun on some core level.
Similarly, the MeggySynth, in addition to being its own project, is also a kind of proof of concept for a rhythm game idea I have. The point of this prototype? To determine whether pressing buttons to make beepy melodies and flashing lights is fun. Answer: yes.
So I’m finding that this whole notion of prototyping the toy first is proving to be a really good idea. This is not to say that it’s trivial to make the toy into a game, but it gives me the confidence as a creator to move ahead.
{ 4 comments }
You had to try it out to see if beeping and flashing lights were fun? Sheesh, I’d think that would be obvious!
Irony detection FAIL!!
There are a lot of great examples of this from development. Katamari Damacy and Halo’s Warthog being two that immediately spring to mind.
I’ve actually had mixed results with building the toys first — it was definitely our mantra on Experimental Gameplay, but sometimes it would lead to fun toys without any suggestion of goals.
It can also be hard as a developer to separate the “great, it works” endorphins from the “this is fun to play” endorphins. Thus testing your toy in its pure state can lead to false positives of fun. (The need for detachment is true of all stages of development, but I’ve found it particularly hard to get when making software toys.)
Comments on this entry are closed.