Category: Game Design

This is from a series of posts I wrote about Fantastic Contraption when I originally released it. They were originally published on our travelogue but I have back dated them and moved them over here where they fit in more.

More in the series of articles about writing the physics puzzle game Fantastic Contraption.

Today: usability. Or specifically: teaching people how to play your game.

Some of is going to make specific references to the game so you should go try out the game first. Be cool, it’s free, you can be your own little user-study.

Fantastic Contraption launched with a fairly simple tutorial system (as of the time of this writing is still has it). I basically just came up with it out of thin air. I guessed what people would need to know, what they would be confused by, and what they would figure out on their own. So I tried the make-it-up-as-you-go-along school of thought.

I took a usability class in university from one of my favorite profs Dr. Tzanetakis. And his mantra was ‘user testing’. The idea was that all the theory in the world falls down and you won’t know what is working and what isn’t without putting a user in front of your UI.

So I finally did some belated user testing (this is after the StumbleUpon traffic bomb). And I made some interesting discoveries.

For people who think like me the existing tutorial is great. Gamers tend to get it. It takes a little time to figure out the draw when stopped, hit go and you can’t touch it thing. And they try to drag and drop instead of draw. But mostly they clip through the tutorials and rock straight on through to Up The Stairs.

But I have left non-gamers in the dust. In the dust, choking on it, wondering why I hate them so much.

Just some of the things non-gamers are not taught well enough by the existing tutorial:

-draw not drag and drop (this is universal)
-have to draw inside the blue square
-you have to get the pink thing to the pink goal to win (despite pounding them over the head with it)
-you can’t draw when the simulation is running (the red reminder arrow goes completely unnoticed)
-your contraption can’t overlap terrain
-the basic principles of construction

I’m going to write a bit more on that last one: The basic principles of construction.

There is one tower of UI failure that towers mightily over all others. It may be the only thing that you need to truly understand in order to play Fantastic Contraption:

You must attach the rod to the centre of the wheel to make it spin. That little bit that is equidistant from all the other bits. The focus, the key, that of overriding importance. The Middle.

And I am a total fail on that front. I have one concession to teaching this truism in the current tutorial. There is an example contraption in the 2nd level that is a clockwise and a non clockwise wheel connected with a stick between their centers. But people don’t even get that this is an example contraption. And sometimes they do but then they start trying to replace the goal wheel with a non-spinning wheel.

Most often people put a rod between the two closest points of the wheels. Unfortunately this pretty much ends their gaming experience. They have now totally broken the contraption. They will have to find the delete tool if they are ever going to finish the level. So the thing non-gamers do most often also ensures that they will never play the game again. That is what UI experts call “bad”.

And oddly enough I never even considered it. It wasn’t before I did some good old fashioned user testing that I discovered I was turning away a huge percentage of my traffic angry and sullen, probably feeling stupid.

So now it’s time for quest redesign-the-tutorial. The tutorial is going to get very constraining and guided. It’s going to be alot of work, and it’s going to annoy the gamers (hopefully skip buttons will keep them happy). But something needs to change pretty drastically.

So there you go. More evidence that Dr. Tzanetakis’ mantra is completely correct.

Do User Testing. You don’t know what’s going on until you Do Some User Testing.

real quick: The user testing methodolgy I’m using is getting a co-worker, friend, neighbor, or friend of a friend to play the game. Then I reasure them that they aren’t an idiot and any failure is a failure on my part not theirs (this is important so they don’t get all nervous and freak out when things start going wrong). Then I just watch them, and don’t answer any questions. Let them fail and recover on their own. You won’t be there every time someone tries to play your game. I very occasionally prod them about what they are thinking. I’d do voiced-thought style studies but already have trouble getting people to participate.

This is from a series of posts I wrote about Fantastic Contraption when I originally released it. They were originally published on our travelogue but I have back dated them and moved them over here where they fit in more.

Just a quick post to keep everyone who’s interested in the game updated on what’s goin on.

Crazyness is going on.

StumbledUpon.com stumbled upon the game on friday to the tune of 3000 hits. Which got me some more blog links. Then, sometime while I was out of the house sturday, StumbleUpon came back with a vengence and funneled 20,000 people into the game. Which was a shock. The last three days have all seen an order of magnitude increase in traffic. That’s three orders of magnitude in three days and five orders of magnitude in the six days since we went up.

It’s been up for only 6 days! So here’s something interesting. The path to 20,000 hits:

Day 1&2:

First Andy put a post up on his blog, v-log, magazine.
Our first piece of non-friend press was a mostly plagerized post on a small Puzzle Blog

At this point I was getting 10s of visitors a day.

Day 3&4

Then a flash games site, Coin Castle, put up a link with a screen-shot.

This jumped the traffic up to 300 hits a day.

Day 5

Flash Game Blogs, another flash games site, posted a short review. It was positive but lamented the 10$ price for getting the full game. Which jumped the traffic up again. This also led to a brief StumbleUpon burst of 3000 hits.

Day 6

I left the house and all was well, we were on pace to break the 3000 barrier. Mostly with the flash games site traffic (a few more sites have linked us).

When I got home around 10pm I found that StumbleUpon had come back and packed the server to the brim. Which was great. But it also kind of destroyed the server. People were still playing but server requests, like saving and loading levels, were slow and spotty.

Something like 400% of the bandwidth is Jame’s great music. So I had to take out the 7meg main-loop and replace it with the short 600k menu-loop. Which was an order of magnitued decrease in bandwidth usage. And allayed the responsivness problems.

Amazon runs a sort of data-warehouse. Their calculator recons the music was going to cost 500$ a month to host. They aren’t the cheapest around but if anyone knows a cheap place to store a few terrabyres of upstream traffic a month let me know (note that those ‘unlimited bandwidth’ plans are bs).

So I have no idea what’s next. I mean we’re on day seven of the ‘soft launch’ and have 6 thousand hits by 10am. Mostly from StumbleUpon. I don’t know if the StumbleUpon traffic is going to peter out or ramp up again. God help us if we get dugg or something.

I will say that we are far from making a fortune off of this traffic. We couldn’t pay any significant hosting bills with the money comming in (although there have been a few purchases).

So, my ass is strapped to this roller-coaster. I guess we’ll see what happens.

This is from a series of posts I wrote about Fantastic Contraption when I originally released it. They were originally published on our travelogue but I have back dated them and moved them over here where they fit in more.

Here is the next in my series of articles about Fantastic Contraption, the physics puzzle game I wrote.

Today I’ll digress from the ranting and wander back into design.

I want to talk about Technic Lego vs. Star Wars Lego.

Specifically, why Fantastic Contraption is Technics and The Incredible Machine is Star Wars.

See Star Wars Lego has all these pieces that are specific things.
Like one piece might be the front nose-panel of an Y-Wing. It’s a
weird shape that couldn’t really be made out of other lego pieces.
And when you pick it up you pretty much have to make a Y-Wing like
thing out of it.

Thats like The Incredible Machine. And some other games in the
build-a-thing-to-do-something genre. The conveyor belts convey.
That’s pretty much all they do. After you master conveying you’ve
pretty much got them sorted out. So the fun mostly comes from
learning to use new things. Every couple of levels you get a new toy:
springs, rockets, hamsters, whatever. And the fun comes in figuring
out what this new thing does. How it hooks up to the conveyor belts
you already have, finding what hole in functionality it fills. And
that is a fun thing to do. So the The Incredible Machine, and other
Star Wars Lego games are very fun.

Technic Lego is a little different. There are no windsheilds or guns
or landing-gears or what have you. It is all basic building blocks.
So making a Y-Wing is much harder and it isn’t going to look anywhere
near as good. And you aren’t presented with a Y-Wing nose panel and
challenged to make something out of it. But technics has a different
kind of raw appeal to it. That of pure contruction. Because you
aren’t guided to certain solutions by your tools you make crazy
imaginative things. The feeling of creation is more raw because you
started with less.

Fantastic Contraption is like that. After the first few tutorial
levels you have to progress beyond the material’s obvious functions.
Like while wheels are still for rolling you discover that wheels are
also for building catapults out
of. Or while sticks are still for carrying you can use them as legs
to make a walker.
So each level can be solved any number of ways and players come up
with radically different solutions to the same problem.

I obviously played with Technic Lego alot more when I was a
kid/undergrad than I did with Star Wars Lego (or the space set or
whatever it is we had back before lego did cross-over marketing).
Fantastic Contraption is a direct result of that. It is the
tinker-toy simplicity that allows the player to generate complexity.
It is the blank canvas that challenges you to create.

So that’s why Fantastic Contraption doesn’t have rockets or springs or
hamsters. And you can’t resize the wheels or turn gravity side-ways.
Those would be distractions from the task at hand.

Although I would like to breifly mention Armadillo Run as a game that
has its cake and eats it too. It is all about raw imaginative
Technics energy but it still doles out access to a few Star Wars
pieces as the game progresses. And in doing so becomes one of the
best games ever made.

This is from a series of posts I wrote about Fantastic Contraption when I originally released it. They were originally published on our travelogue but I have back dated them and moved them over here where they fit in more.

Alright, this is the second article in my series of articles about writing Fantastic Contraption.

This one is about menu development. And how much work it is. And how much work it continues to be.

Fantastic Contraption took me about four months to write. And fully half of that was spent on the menus. I think I spent more time on my mouse-pointer code than most flash authors spend on their games.

I have written a fair number of games before. But none of them have ever been fit for human consumption. And I think in general what makes a game fit or unfit for release to the public is the menu system and the interface. I guess this is trivially true, since you can have a game with no menu but not a menu with no game.

The problem for me is that the importance I put in the menu is way out of whack with the importance the user puts in it. I don’t care at all about it and wish the issue would just go away. The user sees it as an integral part. They first use it to judge the quality and theme of your game. And then they require it to smoothly and painlessly allow them to go where they want to go and do what they want to do.

At the heart of the matter is that every user starts out as a novice and has to learn to use your game. While, as the author, you are a power-user from day one. You think people should just use the command-line interface like you do.

But they don’t. So you have to spend an incredible amount of time exposing your features to the user in an intuitive, appleaing way.

Let me give you an example of how much work this is. Lets take the Main Menu as an example. The Main Menu lets you you select what level you want to play. What is required to make the Main Menu? (you can check out the menu here)

Well first off you need graphics. God help you if you aren’t artistic or don’t have a brilliantly artisitc fiancée. If your graphics are suck noone is even going to try your briliant game.

The Main Menu has a list of levels. Which is (currently) retrieved from the server when the game loads. So if a user jumps to the main menu they will breifly (or not so breifly depending on the server-load) see an empty field with no level-buttons. To hide this we need a fancy animation that covers the loading time. In Fantastic Contraption this is a screen of bubbles. But then there are all sorts of timing issues you have to coordinate. When menus get hidden, shown and when the bubbles are comming, going, or holding solid.

Now you need buttons. The life-blood of the menu. This requires more graphics. But it also requires a system. Fantastic Contraption has something like 100 buttons. You aren’t going to manage this many buttons without your own event types and a solid system to manage the events they throw. Plus you need to handle both the buttons and the mouse changing when the user mouses-over the buttons. Adobe makes this akward with their mostly-but-but-quite-working tools for including vector graphics in command-line projects.

On the main menu most of the buttons trigger either a new menu to appear or a level to load. But these new menus will open new menus of their own, and will have buttons that go back to the previous menu. So now you need a menu management system with a stack that new menus get added to and removed from as users go back and forth.

Currently there are two pages of levels. So you have to add paging buttons that route a request back to the server. Which has to be written to page the data properly.

And there are menus that don’t take you away from the page but pop-up over the existing menu. Like the log-in menu. Most menus don’t have to talk to eachother but the log-in menu has to tell the main menu when a user logs in. So that the main menu can put their name in the corner. So your menu system has to have a way to relay information between menus but not break if the user is logging in somewhere that isn’t the main menu (like the save game menu).

And just a ton of other look and feel problems. Like getting the font right and the text to fit in the space provided and the hitmaps for the buttons to cover the right amount of space and other buttons that appear when a level is finished and the mute button and fitting the “buy this game, please!” button in but making everything look natural when it’s gone and trying to make everything responsive and why won’t the mouse pointer change when it’s over the buy button!?

And that’s the simplest menu in the game.

When you start out authoring a game you’re thinking “this is going to be the coolest game ever!” not “this is going to have an intuitive, trouble-free menu system!”. But find the will people. Because menus are a must.

I’d also like to quickly thank Dan Ukryn for giving me some advice in my foray into menu writing.