The FILTH and the FURY!!

The FILTH and the FURY!! abandons the player (as music journalist Jesper Sandovaal) in scenic Narciso Catastrophe, expecting only the finest critical/investigative New Music Journalism. Avoid squares! Satisfy mainstream audiences! And court the trendsetters to get the scoop on the next pop culture phenomenon—and beat your journalistic rivals to press. With David Mershon. Sound by Alvaro Morales and Zac Zinger.

Download the latest beta release!

My first major project and the longest-running. Developed as “Pixel Editor” from the heady days of 2002 onwards. Six major Mac OS revisions and three major product versions later, here it is. Make pixel art without having to continually push Photoshop’s enormous UI out of the way.

Watch the video

Some shots are very, very hard to get right. How many takes must there be of the long studio shot in Magnolia? How many watches had to be synchronized to get the timing right for the pan across the ceiling-less apartment floor in Minority Report? But getting the shot, as tough as it is, is only a fraction of the difficulty: every hard shot is even harder to plan. How quickly is the camera moving? When should each actor hit their marks? Where are their marks, anyway? And what does the set look like? Does a wall have to be torn down? Is it starting to rain? How much are we paying these people, anyway?

To try and avoid these awkward questions—especially that last one—modern moviemakers use a family of techniques called “previsualization”, or “previz” for short. Previz uses tools like storyboarding, Matchbox cars, action figures, and 3D animation software to help a director, a cinematographer, a set designer, and other parties figure out what they want before paying a lot of money for actors and caterers to stand out in the rain. Most complex previz is done in programs like Autodesk Maya, which has a learning curve thatʼs basically vertical. So, the producer hires firms full of previz specialists to work with moviemakers to make representative 3D animations and environments. Unfortunately, if the cinematographer decides that the camera needs to be moved two inches to the left, she canʼt change it herself—it goes form her to the previz folks down the hall (or, in the worst case, over a cell phone), they work on it for a while, and she sees it the next day. By then, her feeling may be different, or she might have been misunderstood, and it takes another day to fix it. But she just wants to see what it would look like two inches to the left!

Crystal is an attempt to solve this problem. Using our most expressive input devices—the human hands—moviemakers can create a set on a tabletop, stage action-figure actors and Matchbox cars, frame shots with their hands, and view the result in a live 3D render. The movements of the camera and of the objects in the scene are recorded faithfully by the G-speak systemʼs motion tracker, they can be modified and played back, several takes can be recorded, and a shot can be planned with the ease of playing in a sandbox. The movements of cameras over time can be displayed to show coverage and set requirements, and the rough, easy-to- change results can be sent off to those professional previz folks for refinement.

As part of my fellowship work, I explored various ways of doing sound on a multitouch table. Initially, I had proposed something loop-based with tactile instruments: a sequencing and synthesis tool. Though fun to play with, this didnʼt match closely enough with what was needed, so I went to the opposite extreme: a visual programming language for audio signal processing. Mixupp (as it was now called) used a LISP-like syntax and allowed a user to nest trees of functions, collapse those trees with a gesture, and reorient those trees as they pleased. I tried several different prototypes of this before deciding that it was approaching a local minimum.

After discovering that the fun of a paper LISP language—dragging functions around, sliding bits of paper on a table—was lost in the translation to a digital prototype, I had to ask “why?” The conclusion I came to was that the looseness of paper was the thing that made it satisfying; the digital prototype I had built had specific slots into which arguments of functions had to go, and each tree would perform an automatic layout operation on its contents to keep everything looking proper. This, I am sure, was the reason it felt so mechanical and false.

For my next project, I wanted to do something looser and freer—something that expressed the essential nature of a signal processing graph or patch bay without enforcing any kind of rigidity. Mixupp-Sweep is an exploration of drawing out “signals” from “tracks”, drawing faders on the table and assigning them values, and using tagged objects to change the filter assigned to a fader. It feels much different, much more expressive, and much better overall.

Usability has been a goal of interface and interaction engineering since the beginnings of human factors research. Games have, for the most part, carried on this banner of ease-of-use via tutorials, in-game instructions, well-labeled interface elements, and standardized controllers. With this project, we contend that usability and fun are (or at least can be) orthogonal.

For prior art, see Tarn Adam’s Dwarf Fortress and Nude Maker’s Steel Battalion. Both present expert interfaces to complex simulations: in the former, the player oversees a community from seven up to a hundred dwarves, deciding on zoning law, public policy, military strategy, and cultural achievement; and in the latter, a player uses three joysticks, three foot pedals, and a bushel of switches, knobs, and buttons (including “Fire Extinguisher” and “Windshield Wiper”) to try and navigate a walking robot (or “Vertical Tank”) through various combat missions. Mastery over these complex interfaces is a significant part of the enjoyment of these games just as mastery over one’s own body is a significant part of the design of any physical sport.

Unfortunately, Steel Battalion’s controller has nothing in the way of haptic feedback: it is a pure input device. Therefore, we wanted to investigate an input/output mechanism that we feel is not just reactive, but reactionary; a controller whose goals are different from the player’s. Initially, this design took the shape of an autonomous lifeform like a steam-powered horse, but in combining the reactionary UI concept with Ryan’s previous work in gesture-based controls, we found a way to further increase the noise and chaos in our system: a second player.

In our current design, two players cooperate to control a flying vessel. One player (the pilot) sits at a laptop wearing two special gloves. The left glove selects the type of weapon to be used, and the right glove fires that weapon. The right glove is also used to move and dodge enemy shots. Bright LEDs on the back and the palm of the glove can be observed by the laptop’s camera, and the ship tries to move towards the corresponding point on the screen. The ship will continue to move towards the last seen point if the light becomes invisible.

The pilot isn’t in this alone. In fact, she is dependent in nearly every way on the second player: the engineer. The engineer manages the power output levels for the pilot’s weapons, restoring power after shots are fired; he also monitors and controls the color mix and positions of the ship’s shields which must match incoming shots in order to block them. If the pilot wishes to fire the ship’s ultimate weapon, he also needs the engineer’s cooperation to arm and then discharge this mighty attack.

The engineer cannot see what’s on the pilot’s screen, and the pilot cannot see a weapon’s status before deciding to fire that weapon. If the shield mix is incorrect, incoming shots will penetrate and damage the ship. If the charge level of a weapon is low, it will fire only feebly. Worst of all, incoming shots disrupt the shield mix and fired weapons lose power, requiring the engineer to recharge them. It is vitally important therefore that the pilot communicate to the engineer about incoming threats and that the engineer make it clear to the pilot what attacks are available.

We hope that this game forces players to reevaluate their relationship with their games, their controllers, and each other. Specifically, we hope that the conception of a “game” moves away from a piece of media plugged into a player and towards a sense of social contract in a space arbitrated by rules. The design of this game, its controllers, its installation context, and its social context are tightly coupled, and by using these bespoke interfaces games can provide much more nuanced and special input. Games should let players aspire to be good at them, and reward practice with increased subtlety and grace.

Most multiplayer games try very hard to put all players on equal footing. “After all,” some would say, “it wonʼt be fun if a player has a clear advantage.” This perspective can only be from a person who has not played Dungeoneering.

Dungeoneering is a game wherein the player holds a controller with a directional pad and at least one button. This player is the Hero; he moves his avatar around the on-screen dungeon, fighting goblins by hitting them with a sword and wooing princesses by hitting them with a flower. Sometimes passages open to him; sometimes they close. Sometimes the princesses and goblins are very small; sometimes they are very large. If he kills (or woos) enough goblins (or princesses), he will gain a level. Lucky him! The Hero seeks the Ultimate Reward buried deep within the cavern.

Dungeoneering is a game wherein the player holds a tablet digitizer. This player is the Dungeoneer. The Dungeoneer can carve out regions of an on-screen dungeon, fill them in with rock, or make goblins and princesses (by moving the pen in a circle). She can also draw in various inks which have no mechanical effect. The Dungeoneer is responsible for making sure the Hero has a rewarding experience.

Together, the two will communicate and create an interesting story replete with personal growth, overcoming adversity, rising and falling tension, and an Ultimate Reward (decided by the Dungeoneer based on the Heroʼs performance).

Dungeoneering was developed in Fall of 2009, and explored the concept of socially constructed play quite apart from more recent games like Sleep is Death (Geisterfahrer) or Everybody Play & Edit.

Hold the button to spin the sky from day to night and shine your life-giving moonlight on the helpful tree sprites. Moonlight also causes the powerful cannon-flowers to blossom and fight the tree munchers.

Download version 0.1!

“As long as weʼre growing, we’re always out of our comfort zone.”

In other words:

TRY YOUR BEST FOR MAXIMUM BEST!!

Cyclyc is a game about the challenges that help us grow, and the challenges that we in turn set to others. Cyclyc is a two-player game using XBox 360 controllers. The first player inhabits, on the top half of the screen, a game set in an illustrated outer space, taking on the role of (Space-)Ship Girl, Captain of the Ship. The second player lives on the screenʼs lower half, running along the ground as the pixelated Rocket Pack Girl. Ship Girl (Captain of the Ship) must “skim” close to enemies to charge up her laser with which she can defeat enemies; but if she brushes into an enemy, she perishes instantly. Rocket Pack Girl must use her spinning Wrenchblade to attack enemies on the ground and in the air; but the Wrenchblade has a very short range, and it attacks in the front and then the back, leaving her vulnerable on each opposite side in turn.

Each player also has a soundtrack. Ship Girl (Captain of the Ship) listens to acoustic/ electric rock, whereas Rocket Pack Girl prefers NES-style chiptunes. As each Girl fights better without perishing, her respective music will upgrade and become more complex. The background images on her half of the screen will also increase in complexity and saturation.

Cyclycʼs most distinctive feature is its difficulty, which exhibits a positive feedback loop. As enemies are defeated by one player, those enemies are sent to the other playerʼs screen. This augments the enemies that are introduced regularly through the duration of the song, leading to truly ludicrous numbers of foes. If only one player is playing well, the other will be swamped and killed repeatedly, effectively capping that first playerʼs high score potential. For the highest aggregate and individual scores, both players must do their best.

Cyclyc won second place overall, runner-up in sound, and “Best XNA Game”.

PLAY the GAME!!

“God-Bear” comes from the Old Norse etymology of the surname Osborn. Equal parts ás for “God” and bjǫrn for “Bear”, the name conjures, for me, a noble yet comical image. God-Bear Productions allows me to stamp my name on my works without feeling self-aggrandizing.