Braindonut

My latest game development project was actually completed nearly 6 months ago, but I hadn’t posted anything about it at the time. The game is named Guardian of Dreams and you can…

Play it here!

I had been working with a special team at the Art Institute of Pittsburgh to create a Flash game to submit to the 2010 Independent Game Festival.
I was the sole developer for the game and also did quite a bit of the design for the gameplay. I’m very happy with how it turned out. We all learned quite a few lessons from the project, but I’d like to call out a few of my key lessons learned:

Don’t wait to start

When we first started working, I didn’t spend a lot of time figuring out Flash development before making our first prototype. Instead, I started developing a prototype in TorqueX in C#, since I was far more familiar with C#. I thought it was important to get a sense for our core gameplay concept and control mechanism – which is something I’ve picked up in my experiences as a User Experience Designer. What sounds fine on paper and what feels fine in implementation are very often 2 different things. This prototype ended up taking a few days of work, at which point we thought the core concept was solid enough to start working in Flash.

PushButton Components are teh Hawtness

PushButton Engine enabled us to rapidly create our game in iterations, through a very intelligent pattern of abstraction between the entities of the game and the logic applied to them. Ben Garney has this post on the advantages of their component system, so I won’t go into all the details. However, I will say that the component system allowed me to rapidly re-use and refactor logic without affecting large amounts of the code base. I was able to create new entity types through the combination of various components… And overall I was able to rapidly prototype and then iterate the game because of this pattern. It kinda reminds me of MVVM + Attached Behaviors in the WPF/Silverlight world…

Don’t Underestimate the Power of Pixie Dust

When the fairy in the game just flew about, without any particle effects, people were moderately amused, but generally bored.

Then I put in some fairy dust and everyone LOVED it.

This is just further proof that details count, a LOT. The little polishes and the extraneous, fun flair are not so little and not even remotely extraneous.

This is perhaps one of the biggest lessons learned. Details matter – they can be the tipping point between acceptable and delightful.

Test it early and often

Ok, I drink that kool-aid constantly because I do UX design in an agile environment. But it’s true. Prototype something, test it on real people, observe and iterate. Don’t design your perfect game idea completely, ahead of time…

If anything, we wasted too much time coming up with ideas and didn’t spend enough time making them.

I wish there had been unit tests

I have no idea how to do TDD in Flash, but if I could have done it all over again, I would have tried to do that. There were bugs and the bugs were hard to find… TDD would have probably ended up saving me time, in the long run.

Math is hard

Hey, I’m a UX Designer. I love making cool things, though. So I’ll learn what I need to in order to do it. But damn… Some of that math pwnd me. You programmer types are wizards. I really need to flex my math muscles more regularly.

“Specialization is for insects”

As the great Heinlein quote from “Time Enough for Love” goes… The only thing keeping you from doing something is yourself. I didn’t know anything about ActionScript 3, going into this. I knew general C based scripting, so I supposed I had a bit of a head start there. But I learned a LOT making this game and had a blast while doing it. I strongly recommend trying to program a game to any designer out there. The process helped me in my work, in that now I am even better at creating rich, interactive prototypes of software.