Prototyping assignment – “Recycle Race”

20131130_001254 cropped

Star Wars: Race to Escape the Garbage Pit!

I imagine this could work as a browser game (using clicks/drags on a mouse or taps/drags on a trackpad), tablet game (using taps/swipes) or a simple console game (using a controller or motion sensor), but I think it would be most engaging as an exhibit—a motion-sensing input device (e.g. Xbox Kinect) hooked up to a large screen display.

The player, a Youngling, or Jedi-in-training, and their friend (an NPC), not a Jedi-in-training, stumble upon the infamous garbage pit races under Coruscant. The villainous Tunnel Master, amused by the children’s intrusion, tells them that they can go free if they can win a race—one where contestants jump down through levels of flying garbage skiffs and grab an item off the back of one of the giant Garbage Worms that inhabit the pit.

Even as a Jedi-in-training, the Youngling knows that they could win this race with one arm tied behind their back. But the two children have to finish the race together, and the player’s friend is a bit of a klutz. The Youngling notices that all the other—grown-up, experienced—contestants just land on and scramble across the garbage piled on top of the skiffs. It’s unlikely, though, that the friend could even make one jump before falling onto the mountains of garbage at the bottom of the pit.

So, the Youngling decides to use what Jedi powers they do know to help them get out of this mess. The player will have to jump down to each skiff first and, before their friend follows, clear all the garbage off the skiff and help cushion the friend’s fall. But the Jedi-in-training can’t just—using their telekinetic Force powers—push or fling all the garbage off the skiff; it could fly into or onto someone else. And even if the Youngling wasn’t concerned about other racers retaliating against the two children, the Jedi Code wouldn’t allow the Youngling to harm others in such a way. What the Youngling can, do, however, is task three Sanitation Droids to help the player collect the garbage. There are three kinds of these droids—one that collects plastic and metal, one that collects paper products, and one that collects all other garbage.

The game, then, consists of the player (or their Youngling avatar) standing on a garbage skiff with three kinds of items piled in front of them—metal/plastic, paper, and garbage. Each round consists of the avatar (via P.O.V. “cinematic,” no interaction) jumping down onto a skiff and then (via the motion-sensing input device) using their telekinetic Force powers to “grab” these items and push or throw them into the appropriate Sanitation Droid, all of which are hovering around/above the skiff.

Each skiff pile will contain ten items—three plastic/metal items, three paper, and four garbage—, randomly arranged. Items will never fall off the skiff/screen. The three droids are positioned at 10:30, 12:00 and 1:30, and the game will simply help guide an inaccurately/indeterminately thrown item into the nearest droid, though more accurate throws will take less time to complete their trajectory than less accurate ones. If an item is thrown at the incorrect droid (e.g. the player throws a metal item at the paper droid), the item will simply bounce back onto the skiff. Items that are thrown at the correct droid register in the droid with a satisfying “*thunk*.” After five successful hurls (i.e. the correct item into the correct droid), the player’s “Force Lightning bar” (located on the right-hand side of the screen) goes up one increment (of three). Once the Force Lightning bar is “full” (i.e. after a total of fifteen successful throws) the player can use their Force Lightning to zap all the garbage remaining in a pile, thus reducing the number items they need to sort/throw by up to 40% (but dissipating the Force Lightning, which must be built up again).

The first round/skiff/jump will last for 30 seconds. Each game lasts five rounds. (In an exhibition environment, this length seems appropriate.) Successive rounds are five seconds shorter—so, by the fifth round players will have just 10 seconds to sort all 10 item successfully. If a player fails to sort all ten items within the allotted time, the player can see, off in the distance, other racers landing on and then jumping from their skiffs, while the Youngling’s friend lands on their skiff tumbling and complaining before the next round/jump begins. Every player can play through all five rounds, getting a score at the end of the game that depends on their overall performance. Players that successfully sort all ten items in every round can retrieve an object (again, via motion-sensor device) from the back of the Garbage Worm, win the race, and escape the pit. Players that fail to sort all ten items in all five rounds lose the race and are goaded by the Tunnel Master to try again some other time.

The “timer” for each round is the action of the Youngling’s friend jumping. It doesn’t actually take the friend 30 seconds to fall from one skiff to the next, but Jedi can perceive time differently, and so things seem to be moving slower for them than for those not trained in the way of the Force. Since the player is just a Jedi-in-training, however, this slowed-down perception of time, and therefore the time the player has to act/react, lessens after each round. The jumping friend—the Youngling’s mental image of which is represented on the left-hand side of the screen—makes some kind of noise (yelling, hollering, whooping, etc.) at five-second intervals, which each of which sounds louder and louder as the image of the friend grows bigger and bigger (as you would expect observing a noise-making object falling towards you).


If I were to prototype this game in class, I would ask for six volunteers—one to serve as the player/Youngling/Jedi-in-training, on as the friend/NPC/timer, three as Sanitation Droids, and one to operate the Force Lightning bar. I would ask the player to sit on their heels, with the three Sanitation Droids sitting on their heels approximately three feet away from—but facing—the player, their hands forming a big “C” on the floor, at 10:30, 12:00 and 1:30. On the floor, in front of the player, I would place 10 golf balls that represent the ten items to be sorted on the skiff. Three would be of one color (for metal/plastic items, three another (for paper items), and four (for “all other garbage” items) of a third color. The Sanitation Droids would be instructed to catch the golf balls rolled at them, reaching out to scoop in balls that are not necessarily on-target but closer to them than to the droid next to them. If a droid was rolled an incorrect ball (e.g. the volunteer representing the garbage droid was rolled a paper ball), they would simply roll it back to the player—or, rather, the player’s pile/group of items.

The friend/NPC/timer would stand to the player’s left, five paces away but within the player’s view. The Force Lightning bar operator would sit on their heels to the player’s right, about two feet away and similarly within the player’s view. After I start the round, the timer would start a stopwatch they had in their hand and, after five seconds, would take one step closer to the player, uttering some exclamation at each interval—and a bit louder for each step closer. The volunteer operating Force Lightning bar would be responsible for counting the number of correct throws. Once (or if) the player reached five, the bar operator would place one wooden block on the floor (within the player’s view). Once (or if) the bar was filled, the operator would say “Full!” The player would then have the choice when to use their Force Lightning—shouting “Zap!” when they do, at which point the timer would pause their stopwatch (and paces), while the operator cleared away all the existing garbage balls left in the pile (and the three accumulated Force Lightning blocks). After this process was completed, the operator would say “Ready? Go!”, and play would resume.


Warfel, Prototyping Chapters 1 & 4

In Chapter 1 Warfel makes the case for–as the chapter title indicates–”The Value of Prototyping”–primarily in terms of project and client management. His argument is direct, declarative, practical, and concise. The chapter sections’ titles themselves outline his case:

  • Prototyping Is Generative
  • Prototyping—The Power of Show, Tell, and Experience
  • Prototyping Reduces Misinterpretation
  • Prototyping Saves Time, Effort, and Money
  • Prototyping Reduces Waste
  • Prototyping Provides Real-World Value

The argument of the only chapter section with a non-declarative title, “The Power  of Show, Tell, and Experience,” is that “Prototypes go beyond the power of show and tell–they let you experience the design” (p. 3).

Within the “Reduces Waste” section, Warfel makes a compelling (enumerated argument) not just in favor of prototyping, but points out a number of the shortcomings of the “traditional requirements-driven design and development process.” Having produced, in a professional setting, a number of long, collaborative–or semi-collaborative–documents (i.e. grant proposals and reports), a number of these criticisms  hit home.

In Chapter 4 Warfel offers “Eight Guiding Principles” for prototyping. Like the first one, this chapter is absolutely packed with concise, direct, compelling critiques, practical advice. Reading a book like this in an academic environment is a very interesting experience for me. In no other discipline (or DMDL class, for that matter,” have I come across descriptions/prescriptions for things like the “psychological technique known as priming” (p. 46) or “Principle 6: If You Can’t Make It, Fake It” (p. 51)

Saffer, Chapter 8, “Prototyping, Testing, and Development”

I found Saffer’s definition of interface design–as (it) is distinct from interaction design–quite helpful: “the experienced representation of the interaction design, not the interaction design itself. The interface is what people see, hear, or feel, and while it is immensely important, it is only a part of interaction design” (p. 170).

Once again, Saffer provides a guide–this time though the prototyping, testing, and development process(es)–that is at once concise and thorough.  His point about the great importance of prototyping is also well taken, and something I hadn’t really known/thought about before. (I guess that’s why I’m in school for this stuff….) It was also good and interesting to read a point I’ve encountered variations of in a number of other classes/reading–that “the ‘end’ of the design process is seldom the end” (p. 191).