One Step Forward, Two Steps Back
Game Design Playtesting Prototyping Taking Feedback
This past week, Ding! Games has had a solid step forward, and two good steps back.
So the biggest news that I have since my last post is that we've brought two more people into Ding! Games. The first is Brian McIntosh. He's an awesome 2D Graphic artist and he's already started to produce some great looking art to replace the crap that I've got in there. Second, is Ellen Topitzer, who you may recall as the artist that did our logo. She's an awesome artist and is already hard at work doing concept art for the main character in the game (as well as some other things). The website has been updated, and you can see both of them in the "Meet the Team" section. They should both start blogging about their own journey in making this game as well, so be sure to look out for them and say hi.
That was our one step forward, now what is the two steps back? With new blood comes new ideas, and Brian threw us a curve ball by coming up with a really good one. I'd like to say that I'm simply an amazing game designer and that everything I come up with is gold. That is simply not the case. One day after joining the team, Brian sent the rest of us an email with some varied suggestions. Among them was a recommendation that we make the game a ground runner in addition to a swinging game, thus making the entry level to the game easier, but keeping the rewards higher for going to the heights and trying to swing. The idea had a ton of merit to it.
So this is where I give out some advice to the game designers out there. You have to know when to take input from someone else, even if that input causes your developer (who also happens to be me) to have to go back and redo a large part of what has already been done, especially if that suggestion will make your game better.
Now, does that mean you can always take input from everyone if it's good? No. Eventually you have to draw the line, otherwise you'll fall into the trap of always refining and polishing your game and you'll simply never finish it. However, in the earlier stages of development, making changes like this can prove the difference between a success and a flop (or at least I'd imaging that's true, since I don't actually have either under my belt).
This brings me my next piece of advice. Now this one I can say with certainty. Prototype your game and develop something that's actually playable as soon as possible. While your ideas may sound great on paper, the truth is, until you've done this a thousand times, you won't know if it's really good until you play it. That doesn't mean your prototypes have to be polished, functional or even look good (in fact, if they do, it means you're spending too much time on them). You just need to start getting something together with the core gameplay mechanics and let people play it, even if those people are the rest of your development team. If you're flying solo, then get some friends or family to play it. You'll eventually want a broader audience, but you simply need to get someone to play it as soon as possible.
We had a prototype before Brian joined us. It was after playing that prototype that Brian came back with his game changing suggestion. After we all agreed that it sounded good, I developed another prototype that included his ideas and sent it out to the team. Everyone agreed it was better, so now we're headed down that path. Success for all and score one for prototyping.
So what's next for Ares? While our artists continue making stuff so that the game looks cool, I'll be continuing to build the new prototype. Then our next big step is to have the game played by a group of playtesters. I'm not going to lie, I'm both excited and scared out of my mind. This will be the first time someone outside our immediate development team will play the game. I'll have my fingers crossed that they've got something good to say, otherwise it really will be back to the drawing board.