• File->New->Menu.as

    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.

  • Form vs. Function

    I’m thinking about writing regularly about my experiences writing Amazing Contraption. This may start out as the first of a series of articles about the game, it’s design, the writing, and the release of it. Or it may just be one very boring self-indulgence. We’ll see.

    Anyway the topic of today: Prioritizing functionality over design

    Sometimes it’s hard to make things work they way you want them to. Sometimes you cave and do it the easy way. Sometimes you stick it out. I have always believed that this is a major difference between things that are really good and things that kind of suck. Things that are good are made be people who though it out.

    So I want to talk about an example of when I didn’t tough it out in Fantastic Contraption and why I think I got away with it.

    This is about wheels and sticks. If you want to understand what I’m talking about then go play Fantastic Contraption for a minute. It’s free, suck it up.

    So now that you are familiar with wheels and sticks you know that wheels spin when you attach a stick to them. But they don’t, really. The wheel and the stick both turn in relation to each other. The wheel turns the stick just as much as the stick turns the wheel. So you could use the wheel to turn the stick! Bet you didn’t think about that.

    And it’s a good thing you didn’t think about that because when you try to use wheels to spin sticks the whole house of cards comes tumbling down.

    See you could connect two, three, or three hundred sticks to one wheel. And not all of them can spin. Only one of them can. If more than one did then crazyness would ensue. Trust me it would, no they would not all just synchronously spin in happyness, what if you attached one stick to an anchor? Then the other ones would spin twice as fast! Not a good thing.

    But what’s the alternative? Pick a random stick and make that spin? What a suck solution.

    It’s also the solution I went with. When you attach more than one rod to a wheel only one of them torques against the wheel. The others just limply swing in the breeze. It took me forever to even try this solution because I thought it would be counter-intuitive and would drive people nuts. I naturally assumed that any break from real-world physics would be jarring. But I was completely wrong. No one notices. You didn’t notice (yes, I know _you_ noticed, how clever you are, but did it hurt your gameplay experience?).

    And I think noone notices because in our world wheels spin. Mabey there’s a country out there where cars are chunks of metals wildly spinning around stationary rubber wheels. But in the rest of the world we expect the wheel to start spinning. We don’t scrutinize the forces behind it. We just take for granted that wheels spin. So it doesn’t matter what stick the wheel is attached to. The sticks are just supporting characters.

    The lesson here is: think like a human. They take mental shortcuts and sometimes you can get away with taking the same shortcuts in your code.

  • Form vs. Function

    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.

    I’m thinking about writing regularly about my experiences writing Amazing Contraption. This may start out as the first of a series of articles about the game, it’s design, the writing, and the release of it. Or it may just be one very boring self-indulgence. We’ll see.

    Anyway the topic of today: Prioritizing functionality over design

    Sometimes it’s hard to make things work they way you want them to. Sometimes you cave and do it the easy way. Sometimes you stick it out. I have always believed that this is a major difference between things that are really good and things that kind of suck. Things that are good are made be people who tough it out.

    So I want to talk about an example of when I didn’t tough it out in Fantastic Contraption and why I think I got away with it.

    This is about wheels and sticks. If you want to understand what I’m talking about then go play Fantastic Contraption for a minute. It’s free, suck it up.

    So now that you are familiar with wheels and sticks you know that wheels spin when you attach a stick to them. But they don’t, really. The wheel and the stick both turn in relation to each other. The wheel turns the stick just as much as the stick turns the wheel. So you could use the wheel to turn the stick! Bet you didn’t think about that.

    And it’s a good thing you didn’t think about that because when you try to use wheels to spin sticks the whole house of cards comes tumbling down.

    See you could connect two, three, or three hundred sticks to one wheel. And not all of them can spin. Only one of them can. If more than one did then crazyness would ensue. Trust me it would, no they would not all just synchronously spin in happyness, what if you attached one stick to an anchor? Then the other ones would spin twice as fast! Not a good thing.

    But what’s the alternative? Pick a random stick and make that spin? What a suck solution.

    It’s also the solution I went with. When you attach more than one rod to a wheel only one of them torques against the wheel. The others just limply swing in the breeze. It took me forever to even try this solution because I thought it would be counter-intuitive and would drive people nuts. I naturally assumed that any break from real-world physics would be jarring. But I was completely wrong. No one notices. You didn’t notice (yes, I know _you_ noticed, how clever you are, but did it hurt your gameplay experience?).

    And I think noone notices because in our world wheels spin. Mabey there’s a country out there where cars are chunks of metals wildly spinning around stationary rubber wheels. But in the rest of the world we expect the wheel to start spinning. We don’t scrutinize the forces behind it. We just take for granted that wheels spin. So it doesn’t matter what stick the wheel is attached to. The sticks are just supporting characters.

    The lesson here is: think like a human. They take mental shortcuts and sometimes you can get away with taking the same shortcuts in your code.

  • Fantastic Contraption

    It is out!

    For the last four months I’ve been working on a physics puzzle game called Fantastic Contraption.

    I released it to the world yesterday.

    It is a building game. You build a machine out of rods and wheels to try to put a ball into the goal. Each level confronts you with a different puzzle and you have to make a suitable contraption to solve it. It borrows alot from existing buliding games but there are a few differences.

    Most building games are about building up an environment to accomplish a goal. Like building a bridge or a Rube Goldberg contraption. In Fantastic Contraption the goal is to make a machine that goes off into the environment and accomplishes some goal.

    So instead of building a bridge for a basketball to roll across you make a catapult that flings the basketball over the divide. Or make a crawler that carries the ball down into the ravine and then up the other side.

    It worked out really well. It’s pretty easy to make insteresting contraptions to accomplish all sorts of things.

    From the simplest wheeled cart, to walkers, to ingenious solutions, to imaginative wonders, there’s alot of room for creativity.

    If other people like playing it 1/2 as much as I do I think it’s going to be a real winner.

    And of course I have to give a quick thanks to the team:

    James Mark for the music
    Sarah Collins for the art
    And Andy Moore for testing and pushing and prodding

  • San Francisco Pride



    Photo by Kanaka’s Paradise Life.
    (we haven’t been taking many!)

    This city loves a party. Since May there has pretty much been one celebration or another every weekend. Bay to Breakers, a footrace across town started out relatively professional, with many of the runners in inventive costumes or in the buff, but a few hours down the line the race came nearly to a standstill and became a 12k long drunken, naked street party. It entered the park two blocks from our house and was probably the most drunkenness I’ve ever seen before noon.

    Then there was Carnaval, the Haight Street Fair, and last weekend the Pride Parade. I found the parade particularly touching because of the number of newlyweds (same-sex marriage once again became legal in San Francisco last month; hopefully it will stick this time).

    But we haven’t had all that much time for parties, as we’ve been working hard on Fantastic Contraption, which I’ll let Colin tell you about.

    Oh, and I almost forgot – Pete and Leah came to visit which was rad. Yes – rad. We did a tour of The Rock, finally, and enjoyed many a fine alcoholic beverage with them. We’ll be seeing them again soon when we come through Seattle to the Isle of Van at the end of the month for James Mark’s wedding.