I’ve been running the play test of SPUDZOOKA for several days now, and I’ve learned some really useful things. Special thanks to everybody who has given the game a run for its money. It’s going to end up a lot better because of it. (If you haven’t tried it out yet, you can play here.)

The feedback has been positive overall, but being my own harshest critic, I feel like the game still leaves quite a lot to be desired. I think the concept is a decent one — a little light-hearted destruction goes a long way — but there are some tweaks to the user interface that will make the player experience better. Thus begins the second part of my brief series on user interfaces.

The graphical user interface
There are two main elements to SPUDZOOKA’s GUI, and probably most games with a play-level-then-upgrade structure (that’s a technical term — you like it?): the HUD (heads up display) and the upgrade interface.

I wanted SPUDZOOKA’s HUD (the graphical interface elements that appear on the screen while you’re playing a level) to be as simple as possible. In the top left corner of the screen, there’s a score display and a timer. These elements simply let you know how you’re doing. The timer is most important while playing, so I think it needs to be much more prominent, maybe even moved to the top-center and given a more graphical treatment.

In the lower left there are two elements, a squarish graphic with a number in it, and, next to that, a smaller squarish graphic with some potatoes in it. These are both really important, but I don’t think they work very well.

• The button-looking graphic with the number is there to denote which cannon you are currently using. You only start the game with one cannon, and there’s no indication what this number means until you edit your cannon for the first time. Even then, you need to build and save a second cannon before the number means anything. Right now there aren’t enough levels for that to be necessary. I’m thinking about cutting out the ability to build multiple cannons — we’ll see.
• The small graphic showing the potatoes is there to denote your current ammunition. Again, you won’t know what it means until you edit your cannon for the first time (I think that’s ok), but a lot of people who played couldn’t figure out how to change ammo. The trick is that you can’t always change ammo — it depends on which kind of barrel is attached to your cannon. I think the meaning of the ammo icons didn’t translate well from the editor, and people didn’t remember whether they had access to multiple ammo types or not. Probably I need to add an icon for each type of available ammo in the HUD and give some indication of the currently selected ammo.

That’s it for the HUD. I wanted to include enough elements to keep players informed during, levels but I think I need to go a little further to explain things.

Now onto the cannon upgrade interface. The idea here is that players can mix and match cannon components to create up to three cannons that not only look cool, but have different strengths and weaknesses.

To make this mix-and-match feature work, I needed several elements:

• A way to select components of various types,
• A way to buy components that can later be mixed or matched,
• A place to display the current cannon configuration and its stats,
• Some indication of which cannon (of the three available slots) was currently being edited,
• A way to save a new configuration or return to the previously saved cannon in that slot.

The three component selection areas work pretty well and are fairly intuitive. The result of cycling between components is immediately apparent. The data display for the current configuration seems to make sense as well (except maybe the list of available ammo).

Things start to get tricky, though, when players try to figure out the function of the buy and save buttons. The problem is that upgrading your cannon is a two-step process. First you have to buy the new component, at which point it goes into storage, and then you have to save that component to your cannon, at which point it moves from “in storage” to “in use.” The previously saved component on that cannon moves back into storage and becomes available for use at a later time.

It’s the inventory concept that makes things too complicated. There are (small) text elements displaying the number of each component in storage and in use, and it’s clear that buying a component adds one to storage. Nevertheless, the intuitive behavior, I think, is for the “buy” button to save that new component immediately to the cannon. This seems to be what most people expected.

My attempts to hint at the desired behavior probably weren’t enough. The background on the component selectors turns red when you don’t have enough in storage to use that component in a cannon (meaning you have to buy one). The background of the full cannon display on the right turns red when you haven’t saved that configuration, and you can’t save it until you have enough of each component in storage (which would cause the background color of the components to be blue). In other words, once everything is blue, you’re good to continue on to the next level. If anything is red, you’ve got a problem.

If I’m going to keep this two-step system, I think I need to create some additional cues in the interface to let people know what to do. I could make the “buy” button flash when an additional component is required and/or make the “save” button flash when the cannon is ready to be saved. Those two things would probably help a lot.

You can probably tell I’ve put a lot of time into the cannon editor and the GUI for SPUDZOOKA. I think my first go was passable — players could figure it out after a few tries — but I need it to be obvious on the first try. And that will take some more work.

I’m happy to announce today that my first play test of SPUDZOOKA is ready for your perusal and feedback, constructive or otherwise.

Please take a few minutes to play through the game and then write comments on this post about your experience. Feel free to comment on any part of the game, including:

• Overall fun factor
• Graphics/visuals
• User interface
• Cannon upgrade system (could you figure it out?)
• Sound/music
• Any bugs, funky stuff with playing the game in your browser

Since this is just a test version, I feel obligated to include a small disclaimer: While the gameplay is relatively complete, you will certainly encounter bugs, and there are probably some considerable balance issues with the various cannon components. In fact, there are several cannon combinations that don’t even look physically possible. One final note — the paint job portion of the cannon editor doesn’t work yet.

Ok, without further ado, you can play SPUDZOOKA here!

(To play, you will need to install the Unity Web player, which can be downloaded free for Mac and Windows here.)

As a professional “web guy,” I have more than a passing interest in user interfaces. The most brilliant concept or the most beautiful design means nothing if people can’t accomplish their desired tasks on the web. The same is true, of course, for any kind of application, serious or silly.

For SPUDZOOKA to appeal a wide audience, its play controls and graphical interface must be simple, intuitive, and easy to master. Frustration is the opposite of fun. I don’t know yet if I’ve succeeded in delivering the fun, but here’s a look (in two parts) at the basic process I used to design the game’s various interface elements.

Play controls
SPUDZOOKA is primarily a target-shooting game, but it borrows a lot of its play controls from first-person shooters. The challenge is to keep the controls as streamlined as possible. Here’s what the player needs to be able to do, and the reasoning behind the control scheme I chose for each task:

• Aim and fire the cannon — The goal of each level is to destroy as many targets as possible within a set time limit, so aiming and firing is kind of important. Thankfully, as anyone who ever played a first-person shooter will know, the mouse provides a perfect interface for this: move the mouse to aim; click to shoot. Easy enough.
• Switch weapons — Lots of target-shooting games stop there, but SPUDZOOKA lets you carry more than one potato cannon at a time, so there has to be a way to switch between them. Another first-person shooter convention fits well here: using the number keys to switch weapons.
• Switch ammo — Yes, more switching. Clearly everyone knows that different spud cannons shoot different kinds of ammunition, so I had to work that into the game. The number keys are out for this one (even the higher numbers), since they are being used to switch weapons. I could map several letter keys to various ammo types, but that still seemed redundant and possibly confusing. Instead I decided to use a single button (tab) to cycle through all the available ammo types for the active cannon. The disadvantage here is that it could take a bit longer to select the desired ammo. However, because each cannon will only be able to shoot a few types of ammo, a cycling control seemed to work well enough (let me know if you disagree).

That’s it. Seasoned FPS gamers (who made it this far) may have noticed that one important control is missing: the ability to walk around. Seems like a big omission, I know, but I have decided for the time being that the player will be stationary. I’m sure it seems limiting, but there are a couple of reasons for it.

1. The levels are small and potato cannons shoot a long way. If you can run around and shoot things, it might be too easy. Enabling really slow movement would probably irritate people. Better not to risk it.
2. I don’t want to complicate things. A lot of the skill in FPS games comes from the player’s ability to move and aim at the same time. I know this because I am quite inept at jumping while shooting in Halo, which seems to be necessary for survival in multiplayer mode. While plenty of people certainly possess these skills (they have all killed me in Halo), I don’t want those skills to be a requirement for my game. I want to focus the player’s attention on choosing the right cannon and ammunition for clearing obstacles and hitting targets, not on maneuvering quickly and dexterously through space.

Once you play through a few levels, you can tell me whether you’re completely bored standing in place. In part 2, a look at the graphical user interface.

SPUDZOOKA is coming along pretty nicely now. I’ve got the backbone of the game working, which means that it’s possible to play through several levels and edit your potato cannon in between. You can also change cannons and ammunition on the fly. Everything fits together, and I don’t get any code errors when I play through it. All things considered, that’s pretty good.

The bulk of the work now is in two places:

• The graphical interface. I need to make it prettier and, I hope, completely intuitive. The goal is for people to be able to play with minimal instructions. I figure a casual game like this can’t survive more than a few seconds of, “What am I supposed to do?”
• Level design. I’ve got a couple test levels built, just to get the flow of the game set up, but they will need to be completely redone. Thankfully I set things up so building new levels shouldn’t be too hard.
• Ok, three places. I also need to polish up the sound effects and come up with some music. Naturally I plan to compose and record it myself (I’ve gotten this far, why bring in anyone else now?) That could take a while, but it’ll be fun.
• Well…maybe four (nobody expects the Spanish Inquisition). The whole point of building this thing is for people to play. So I have to put the game out there. At the moment the plan is to publish it on a web site, which I have to build. I don’t envision anything too complicated, but it’ll take a little time.

My goal is to have the game itself finished by the end of March. I doubt I can get the web site done by then as well, but who knows. I’m hoping to have something for you all to play test in another week.

It’s easy to get discouraged as a solo game developer. There’s just so much to do and so many skills to learn. Indeed, I accept that I will ever be more than a hack at most of the skills involved in game development.

But this post over at Tales of the Rampant Coyote (a blog from indie developer Rampant Games) is proof that indie developers can create expansive, immersive role-playing games.

No, I’ve never played any of the games listed in that post. Most probably won’t even run on my Mac. What gives me hope is that the list is so long. It means someone is actually publishing completed games.

SPUDZOOKA isn’t an RPG, but it will be my first full game. And I will finish it. I have modest hopes for it. I hope some of you will play it. I hope some of you who play it will enjoy it. Everything else is just gravy.

What I really want to do is make games that tell stories. I have to start somewhere, but it’s nice to think that maybe one day I’ll publish a game that makes somebody’s list.