Back in June/July, before sHMUP bLUFF, I worked on Button Quest, a game using Flowlab with Sandra Danilovic. Part of the challenge was to learn the web-based game maker well enough to review for Graphite.
One thing that was immediately interesting about Flowlab was the way it uses a flowchart-like drag-n-drop metaphor for programming behaviors for objects. It’s a neat idea, and I could see how it would be useful for novices starting out with programming to sort of force them to think logically about cause and effect. It was almost immediately constraining, though, in that very simple one-line statements in a programming language became convoluted flows that often became pretty confusing. Multiple boxes for various input events linked to another box that manipulated variables linked to another that took variables to display a pop-up text or whatever, etc. The screen quickly became cluttered with boxes that was relatively difficult to keep track of. And our game is pretty simple!
The game itself was inspired by an early comment (I think March or April) in our Game a Week challenge made by Melissa Peterson. She tweeted that she was spending way too much time in search of the perfect button for her game. I replied that Button Quest should be one of our games, to which she replied that there’d be bonus points for clothing buttons rather than software buttons.
So when Sandra and I decided to work together, we shared a bunch of different game ideas, one of them being “Button Quest” without any description beyond that, really. I was also asked recently to review Flowlab and Sploder, so I decided to spend some time with each platform and see if anything emerged.
Springboarding off the idea of different types of buttons, somehow Sandra and I decided it made sense to make a one-screen platformer about a button in search of a new less-lame button skin to become. That sort of turned into ideas about different buttons allowing for different sorts of movements or abilities. The round clothing button, for example, allows the character to roll around really quickly, but the OK software button allows entry past a gate that only opens when OK is clicked. That type of thing.
And then this sort of turned into a metaphor about personal identity and acceptance. The last few buttons allowed for greater freedom, the last one allowing for flight in any direction and when acquired a new opening out of the one-room cage appears. The room isn’t meant to appear like a cage at first, just a regular one-screen game bounding box, but then it becomes apparent that it is actually a cage once the hole appears, in a like, “wait, I can leave this room?” kind of way.
When we knew we wanted the button to be able to change shape and that we wanted different things to trigger on object collisions or whatnot, I started looking for ways in either Flowlab or Sploder to make these happen. Though both web-based tools are pretty constraining and certainly wouldn’t be my preferred tool to use, it seemed like Flowlab would be easier to work with. Still, I sort of figured out how to do the sprite switching by having the game switch between animation states (idle vs. walking vs. running, but with custom names). For some reason this took me forever to figure out how to do. I was initially caught up in trying to have the actual sprite art switch in and out (instead of having everything in the same sprite set).
Still, having come from Construct 2 and GameMaker Studio, working in Flowlab is pretty painful. While Flowlab has a cool real-time debugging feature, highlighting different boxes in its flowchart when you hit play, it sort of impedes its usefulness by not letting you actually see the game window at the same time as the flowchart window. This is probably because it’s an embedded app in a webpage. You end up sort of having to imagine where your various sprites are while you’re hitting buttons, etc., and inferring what’s going on based on which flow boxes get lit up. It reminds me of playing Limbo blindfolded…
Working with Sandra was initially my attempt to be productive and get back on track to doing a game a week. It turns out that I invited her to join me right as she was off to a month-long vacation, though, and we weren’t able to hammer out the sprites in time before she left. The artwork in the current version of Button Quest is just placeholder, using the built-in art library…
Imagine if you would, the button starts out as a “Cancel” button like you would see in a Win98 dialog box. It moves really slowly since it is depressed. It can’t jump very high, and it takes forever to climb up to the feature on the right. This slow ramp was deliberately designed to make it feel like a struggle. I think of Do Androids Dream of Electric Sheep’s Mercerism when I play this initial part of the game.
But then it’s clear that you don’t have to stay a depressed cancel button forever! You can try different identities, and this is quite liberating, allowing for much faster movement and jump height. A gate that requires a particular kind of button is the next obstacle, followed by a gate that requires a very fast button (i.e., a clothing button that can roll) to pass through. The next buttons are meant to be a button mushroom that allows flight and then (Sandra’s pierced) belly button, ending on as surreal a note as possible.
It’s taken forever to write this up since I was thinking we’d finally finish up the artwork, but I’ve decided to write it up now and fill in the art later… so here you go. 
The post #GameAWeek Challenge: Button Quest appeared first on Mark Danger Chen.