The Serious Art of Designing Fun
October 20th, 2008
Welcome to Monday, everybody! Ugh…
In other news, my friend and former collegue, Chris Khoo, has just started a blog on game design. Chris has worked in the games industry for over 11 years and wants to start sharing some of his thoughts on the processes of designing and creating games. Check out his blog if you get a chance:
- The Serious Art of Designing Fun (khoolworks.homedns.org) – A development blog by Chris Khoo
In prototype news, I’m making progress. Last week I put in some new interface elements that should help new players get into the game faster by showing them, up-front, what the effect of their move is. My wife and I had some friends over for dinner on Saturday night and I showed them my prototype. I could see that the UI changes I made were helping them get into the game faster, but something about it still seemed to be inhibiting them at the start. Maybe it was just me watching them? Or maybe I need to think more about how I can help players learn faster.
Right now I have a hint system in the game. After 10 seconds, if you haven’t made a move, the game will show you a tile that will make a valid move. However, right now the animation is not at all obvious and new players usually don’t see it. This is fair, since I mainly put the hint into the prototype so that I could verify that there were indeed valid moves left even though I might not have been able to see one. I’m thinking I need to do two things:
- On the first few levels, make the hints appear sooner
- Make the hint animation persistent and obvious once it shows up
I’ll probably work on that early this week.
The other thing I did late last week was to start adding support for special items. I got one special item entirely implemented, and it definitely helps the game feel more fun. I think it should also help with the difficulty at later levels. However, in putting the special item in, I introduced a rather serious bug into my searching algorithm. The search algorithm is used at the heart of all the gameplay. It’s what’s used to determine: when the player has made a valid move; where to show a hint to the player; and whether or not there are any valid moves left to the player. Something I changed broke this, which is bad.
Herein lies the real problem: my prototype’s code is getting extremely messy. That’s to be expected, as the whole goal of prototyping is to implement quickly without worrying too much about code structure and reusability. However, at this point, it’s making things really difficult to change. I’m quickly approaching the point where making major functionality changes is going to be more difficult in the prototype than just re-implenting things properly.
At this point I’m pretty sure I’ve nailed down what the technical requirements are going to be. For example, I know what I need from my animation system, I know how I want to separate my logic from my visual representation. So I’m not sure how much I’m benefiting from continuing to work within the confines of the prototype code-base.
My plan is now this: fix the bug I introduced on Friday, implement the 2nd special item I wanted to try, archive the prototype code in my repo, start building the game properly.
Owen