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.

Getting closer and closer to being like a real game:
http://www.braindonut.com/GamePrototype/Default.html

Since last week,I’ve added scoring, some limited graphics, updated the controls, threw in a start screen, added a little mp3 that’s playing in the background (which is a great track, created by THERUNNER )… I’ve been messing with tooltips a lot, to see if I could use them to expose a bit of info about the parts. I don’t want to go overboard with the info display. I have some planned changes to make it a bit clearer, though. It’s still all quite rough, while I’m getting things working.

In other news, getting tooltips to work in Silverlight, with their datacontext set to their parents, was a gigantic pain in the butt. I ended up using the solution here:
http://www.wiredprairie.us/blog/index.php/archives/568

I needed to use the DataBindingTooltip class from this post (Thanks so much Aaron!) in order to have the tooltips accessing the datacontext of their parent. (So that the sliders could populate with the data of the part attributes)

But I had to rewrite it a tiny bit to use the new ToolTipService stuff here:
http://tooltipservice.codeplex.com/

Needed to do this in order to control the display delay and display duration of the tooltips, which are added attributes in this library.

I have to admit, I’ve gotten lazy now that my class deadline is getting closer and closer. I ran into some issues getting commands working in Silverlight, since DelegateCommand doesn’t exist. So I just cheated and broke my MVVM pattern somewhat. At this point, I’m starting to realize that I’ve made far more than what was required, anyway. But, it’s a great learning experience.

Makes me really want to play with TorqueX once I’m done with school. I could totally see making simple little games replacing the time that I spend on school, currently.

This post is probably full of typos and errors… I apologize. At the moment, I’m too lazy to proof-read…

First, yes, I still am in school. It’s been slow going, on the account of being part time. However, this is my final year! As such, I have some exciting classes going on. Just found out that I’ve been accepted into a “Special Projects” team, which means I’ll likely be working on a game for the IGF, for my school. That should be a lot of fun.

Right now, I have this game prototyping class, however, which is taking quite a bit of my time. So far, I absolutely love it. It gives me a chance to do the stuff that I do all day long, but do it with little games. For my first game project, I decided to play around with Silverlight. I’ve been making a lot of things in WPF/Blend/C# lately, but I haven’t had a good excuse to really get my hands dirty with Silverlight. I also could use an excuse to get even more familiar with the MVVM parttern , since that’s all the rage at work. (And for good reason, it’s really freaking awesome. Separating the UI from the logic as much as possible makes a whole lot of sense on many levels…)

The assignment was to make a game that centered around “building” something. The examples given were like toy cars and the like – base + wheels = car. This immediately reminded me of the old Mech-style games, where you could swap out parts on your mech to design the exact type of hardware that you want. I decided to make a game that will be a simple spin on that.

Basically, the game will be about a mech engineer (you) who gets orders and assembles mechs to meet the orders requirements. So, for instance, someone may need a fast, nimble mech, someone else may need a slow behemoth with massive firepower. The player’s job is to build the mech in the time alloted, ship it, make some money and then move on to the next job.

I’m not too worried about making the game extremely amazing. I have more game prototypes to make after this one. Chances are, I made this one more complicated than I should have, being that I probably could have gotten away with the toy car scenario. However, this was a really good opportunity to exercise some techniques I’ve been learning…

Right now, the thing can hardly be called a game. I just have the model/viewmodel working to a point that the fundamentals are there. The view, on the other hand, is a POS. But I’m not worried about that. I can make it pretty later. First, it’s gotta work.

So, here it is:
http://www.braindonut.com/GamePrototype/Default.html

Right now, you can just navigate through a junky UI on the right hand side in order to select parts for your mech, which will show up on the left. A view showing the requirements and your current stats will update as you make your selections and ultimately notify you once your mech is ready to go. Then you can click ship it, if you want, but that doesn’t do anything yet.

If anyone is wondering, I used the accordion control from the Silverlight Toolkit for the current UI on the right. It’s just a stand in until I hook up something nicer. Eventually, you’ll be able to see the stats of each part that you are selecting, to make the process a bit easier.

Anyway, it’s pretty simple, but it’s only a start.