Paper-based video games

"my son has limited screen time so he plays @PlantsvsZombies on paper" says Boian Tzonev in an insightful tweet.

"my son has limited screen time so he plays @PlantsvsZombies on paper" says Boian Tzonev in an insightful tweet.

At some point, I'll have to investigate this. A phenomenon that always fascinates me: how players use paper as a (brick-and-mortar?) substitute to video games when devices are not available, or as a complement (for taking notes, drawings maps, etc.).

Another example of paper video game found on boing boing

Another example of paper video game found on boing boing

Why do I blog this? This is definitely fascinating. Not just because you see kids' fantasies and ways to change mediums. It's intriguing because it reveals how a game mechanic, or a graphic pattern, circulates and mutates to create a curious experience. I've seen once kids playing together on paper and I enjoyed observing how they "filled the gap", how the absence of the mighty computer was turned into creative engine.

Plus, I find this interesting because it obviously leads to curious game design propositions, and bc it makes me think of how to take this into consideration in video game design itself: how would you enable the other persons around a player to use paper to improve the game? Can one create a game in which the person holding the controller needs a friend to use a hand-drawn map to help her?

Besides, no one here thought of booklets with video game grids, Zelda open world maps in B&W versions, Super Mario Sunshine levels... with weird paper game mechanics so that players can "interact" with them? I'm pretty sure this exist. The Star Wars starfighter battle book series is a good start but still...

Update: another curious example found here, it looks like UX prototyping.

Update: another curious example found here, it looks like UX prototyping.

Mindloop by One Life Remains: This game is controlled by a…

Mindloop by One Life Remains:

This game is controlled by a mental brain wave thingy. Each color is associated with a brain activity type (Focus, relax, …). You need to be in that state to make the cube come back on the road. The road is the inside of a cylinder so the track is never-ending. The tricky part here is that if you manage to go through the first time doesn’t mean you can do it again easily. And it’s brain tiring

Why do I blog this? Next month I’m going to give a speech in Boston at the AAAS conference about the design issues related to brain-computer interfaces. This game is a good example to introduce some of the concepts I want to address there.

“Asymmetric gaming” as described here: providing…

“Asymmetric gaming” as described here:

providing players different control schemes and specialized objectives in the same game scenario. This is a departure from traditional console game mechanics. Most current games involve a discrete set of roles and strategies, and these are enabled and governed by a single (symmetrical) set of controllers. By introducing a new kind of controller and screen into this mix, Wii U opens up the possibilities for new roles and perspectives, and therefore new kinds of gameplay – asymmetric in nature

Why do I blog this? Writing a chapter about the evolution of game controllers, and the resurgence of displays, this notion is interesting to be addressed in conjunction with technical means and players’ reactions.

“Biotic video-game” or more thoroughly described in…

Biotic video-game” or more thoroughly described in Design, engineering and utility of biotic games by Ingmar H. Riedel-Kruse , Alice M. Chung , Burak Dura , Andrea L. Hamilton and Byung C. Lee (2011):

Games are a significant and defining part of human culture, and their utility beyond pure entertainment has been demonstrated with so-called ‘serious games’. Biotechnology – despite its recent advancements – has had no impact on gaming yet. Here we propose the concept of ‘biotic games’, i.e., games that operate on biological processes. Utilizing a variety of biological processes we designed and tested a collection of games: ‘Enlightenment’, ‘Ciliaball’, ‘PAC-mecium’, ‘Microbash’, ‘Biotic Pinball’, ‘POND PONG’, ‘PolymerRace’, and ‘The Prisoner’s Smellemma’. We found that biotic games exhibit unique features compared to existing game modalities, such as utilizing biological noise, providing a real-life experience rather than virtual reality, and integrating the chemical senses into play. Analogous to video games, biotic games could have significant conceptual and cost-reducing effects on biotechnology and eventually healthcare; enable volunteers to participate in crowd-sourcing to support medical research; and educate society at large to support personal medical decisions and the public discourse on bio-related issues.

Companion Species Training Game

Wednesday July 15, 14.35.42

The new-to-me Nintendo DS “Personal Trainer Walking” (heck of a name..) alongside of the Japanese language game whose name I forget and cannot read.

I found out about this Nintendo DS game from Kevin who found out about it from Russell. I literally just got it yesterday, but it’s pretty exciting to see. I can only imagine in my head out the play dynamics unfold, but I’ll be playing with it and have some more thoughts before long.

So far I enjoy the “blind” design of the pedometer part of the concept — not too much display other than this blinking light which changes color when you’ve reached your goal. Simple, direct and not a nagging taunt from a fancy LCD that shows more than you need. You focus on your activities or just being a normal human being without poking and prodding at the device all the time, checking your status in detail, etc. When you’re in the world, be in the world, I say.

Wednesday July 15, 15.47.20

Wednesday July 15, 15.14.44

This one aspect of the design is quite curious — there is an extra pedometer device for your dog! I mean, I get the idea — people walk their dogs and so this is perfect for you and your dog to get some training together. The language in the users manual / guidebook is very funny, and I’m not sure if this is deliberate or perhaps the sensibilities of a Japanese game design company? I know none of the facts and that does not matter so much to me, but maybe it’s my sensitivities to things that fold together different species into what my advisor calls “transpecies” or “companion species” — species that need each other, or play and interact together in curious ways. (cf The Companion Species Manifesto) Thus, I cracked up when I read these items in the guide:

Wednesday July 15, 15.12.07

The meter should only be used by a person or dog. It will not work properly with any other type of animal.

The meter should only be used on a dog when supervised by a person. It should be attached in a location where it is not at risk of being chewed or swallowed.

Great stuff. I’m looking forward to seeing how the DS experience works.

Downside: I’m pre-disappointed that walking is the only physical activity it seems to work with. I ride a bike and want this to count. And there are so many other sorts of physical things that won’t count, I assume.


Russell points out the simplicity of the synchronization ritual, which is fantastic. Point. Press. Watch your pedometer pebble appear from a pipe on the screen and become “alive” on your screen. If you’ve ever tried to synchronize ANYTHING you’ll laugh out loud, as I did. If you’ve ever designed ANYTHING that requires synchronization, take close note of the interaction ritual here. It’s fantastically playful and simple and sensical.

Some related topics: this perpetual Laboratory project, Flavonoid.

Playstation 2 Logic Analysis

Back for a bit to the world of prototyping peculiar Near Future kinds of things. I’m still working through this anti-game controller, game controller to do some experiments in alternative sorts of mobile interfaces for traditional game devices.

First, there are two other posts on the Logicport and related stuff, and I’ll just flag them here:

Logicport and I2C
Logicport Overview

I did some quick experiments with the Logicport to get my head around its operating features. (My previous brief analysis is here.) I was mostly motivated to work with a logic analyzer because many of the prototyping sketches I do require some sort of communication between devices using protocols like I2C/TWI, SPI or standard serial communication. If you can get these protocols to work right the first time, then you’re golden. Sometimes though, something goes wrong and debugging can be a pain. I’m the kind of guy who likes to see what’s going on rather than guess, and tools like a digital scope and logic analyzer are indispensable for me. It’s just a preference I have to invest in some pro gear, within a reasonable budget. Seeing as I was trying to get this PSX project done and had trouble debugging it, I figured this was as good a reason as any to go ahead and get it and figure out how to use it.

The Logicport is pretty reasonable for a 34 channel (plus 2 dedicated clock channels) logic analyzer because it offloads a lot of the heavy lifting to your PC — $389 with everything you need except the computer. I told myself I’d get one when I had some trouble debugging what should’ve been a fairly straightforward interface — hooking up a microcontroller to a Playstation 2 to make the PS2 think the microcontroller was the normal Playstation controller. This got a bit tricky to debug with just a digital scope that had only two channels with which to analyze essentially a protocol that was using five channels.


The Playstation 2 interfaces to its controllers using a protocol that is basically SPI (Serial Peripheral Interface). The protocol for SPI is fairly straightforward. There’s a clock (SCK) to synchronize bits of data across two channels: Master Out, Slave In (MOSI); Master In, Slave Out (MISO). MOSI bits are data moving from the master device to a slave device. MISO bits are data moving from the slave out to the master. It’s like a two lane highway of data, with each data bit synchronized by the clock. Additionally, there’s a “slave select” (SS) channel — one per slave device — that tells the slave whether or not it is “active” and should listen to data bits coming across the MOSI channel, or send data bits across the MISO channel. (Reasonably, only one slave device should be active at a time.)

So, that’s four channels. The Playstation 2 actually uses this plus an additional line that is not specifically part of the SPI protocol — an “Acknowledge” (ACK) line. This is used to “acknowledge” to the Playstation 2 console each “frame” of data. That’s just the way it works, and the one feature that is a bit outside of the SPI protocol. (I fabbed-up a simple splice along the Playstation 2 controller cable to watch the protocol and try and figure it out. The splice has a simple IDC-style connector that I can use to plug into to either read the channels or, eventually, connect to a microcontroller.)

There are a few pages online describing the specifics of how a Playstation 2 controller works, including ways to interface the controller itself (the joystick) to microcontrollers.

What I’m trying to do is that, but a bit more, which is to interface a microcontroller that behaves like a Playstation 2 controller to the Playstation 2 console. To do this, the microcontroller needs to respond as a (kinda) SPI slave device, just as the Playstation 2 controller does.

To start this whole business, I tried first writing code “blind” — just looking at descriptions people had put up of how they did this, especially Marcus Post’s work, which has some PIC code to look through. I ported this as best as I could to the Atmel platform (running on a 16MHz Atmega168 on an Arduino), but was having some “hiccups” where quite often the Atmega168 seemed to loosethe protocol. Why? It was hard for me to figure out.

So, two things going on here. One — verify the console-to-controller protocol that the Playstation 2 uses. Two — figure out how to use the Logicport. I’m going to leave two for later, and first show the analyzer crunching on the PS2 console-to-controller communication.

Okay, first thing I did was connect up six of the Logicport’s 34 channels as if we’re analyzing a SPI protocol which, basically, we’re doing. We need MOSI, MISO, SCK (clock), SS (slave select), plus the ACK channel. We also need a ground line to have a common electrical reference. These signals are analogous to the one’s the PS2 uses, only with somewhat different names — they are CMD (MOSI), DATA (MISO), CLOCK (SCK), ATT (SS) and ACK in PS2 speak.

The Logicport breaks up its 34 channels into 4 groups of 9 channels (that’s 36, but two of them are dedicated clock channels), with each group color coded by a bit of heat shrink tubing on the end of a colored wire. This makes it easy to figure out which channel is being represented in the software display. (Here’s a plug module that pops into the Logicport. These are convenient cause you can have one semi-permanently connected to individual projects so you’re not always re-wiring. Just save the Logicport file for each project with the same channels and pop the plug module into the main Logicport box.)

So, I just took the “white” group and connected the MOSI, MISO, SCK, SS and ACK channels from the Playstation 2 “splice” cable. I used yellow for MOSI/CMD, black for SCK/CLOCK, red for SS/ATT, brown for ACK, and green for MISO/DATA. With these signals connected from my “splice” cable to the Logicport, I should be able to start seeing the acquisition. (I’ll go over setting up Triggers and Interpreters in a later post. For now, let’s just see what a little fussing gets us.)

The Playstation 2 protocol is pretty straightforward. It starts out with the console activating the SS/slave-select line (channel D2, red/white) to indicate to the controller to start paying attention. SS is active low, so the channel drops from high to low to indicate “pay attention now.” Following this is a 0x01h byte of data along MOSI/CMD — channel D4, yellow/white. You can also see how the Interpreter can represent the data across a specific channel by aggregating bits and turning them into something useful, like a hex number. (You can also fold up these groups of channels if you don’t want to stare at individual bits.)

So, this is the basic preamble for communicating between the console and the controller. After the 0x01 the console sends the command 0x42, which basically means — send all your data. Simultaneously, the controller sends back a specific ID to indicate which type of controller it is. In this case, the controller ID is 0x79. Following this the controller sends a 0x5A to sort of say — data is coming.

The data that follows is basically the state of all the controller’s buttons and the analog controls’ positioning. For this controller, there are six subsequent bytes of data. For this particular controller, they’re like this (Here’s a more complete table for other kinds of controllers.):

Analogue Controller in Red Mode
01     0x01   idle
02     0x42   0x79
03     idle    0x5A    Bit0 Bit1 Bit2 Bit3 Bit4 Bit5 Bit6 Bit7
04     idle    data    SLCT JOYR JOYL STRT UP   RGHT DOWN LEFT
05     idle    data    L2   R2   L1   R1   /   O    X    |_|
06     idle    data    Right Joy 0x00 = Left  0xFF = Right
07     idle    data    Right Joy 0x00 = Up    0xFF = Down
08     idle    data    Left Joy  0x00 = Left  0xFF = Right
09     idle    data    Left Joy  0x00 = Up    0xFF = Down

All Buttons active low.

For example, the acquisition image at top shows the “LEFT” arrow button being pushed down on the controller. Huh? Yeah, see — the right most bit in the white trace? It’s actually low — a little hard to tell cause of the angle, but it is. The PS2 spits out data least significant bit first, which means that bit 0 comes before (in time) bit 7, so the 0 at the end is bit 7, and bit 7 in byte 4 indicates whether the LEFT arrow is pressed, and everything is active low here, so a 0 means — pressed. (As I understand it the SPI protocol normally is the other way around, but luckily with the Logicport you can specific the bit ordering.)

Byte 5 is for the other buttons. This image shows bit 4 activated (low) indicating that the triangle button has been pressed. The bytes that follow are the the joysticks to indicate their positioning along their two (left/right, up/down) axes, running between 0x00 and 0xFF, with their “nominal” (centered) value being about 0x8C-ish, depending on how sticky they are and other things — they’re analog potentiometers which have a little bit of tolerance for variation for mechanical reasons and such.

Here’s an overall view of the entire transaction — the three bytes of preamble, followed by six bytes of controller state data starting around the 100uS. (Those bytes are near the bottom, staggered, in green. Next time I’ll explain how I set that view up.)

(Note that the acquisition shows that the console actually holds the SS/ATT signal for the equivalent of another six bytes of data. I’m not 100% sure why, but perhaps there could be additional data bytes for this sort of controller that I’m not getting. In any case, both the console and the controller send nothing back and forth. It’s just clocked nulls for another six bytes. So, off to the right of this image is lots of clock signals, and ACKS, but no meaningful data, until the SS pulls back high. Also notice the ACKS in the fifth channel (green) — these are acknowledge signals sent from the controller back to the console to verify that it’s alive and so forth. Evidently, these are necessary for the communication to work, but not strictly part of the SPI protocol. (Also, I am calling this SPI because it’s close enough, and provides a bit of a context for describing the communication and taking advantage of the Logicport’s SPI Interpreter. Technically I suppose it isn’t SPI.)

What’s next? Well, a brief overview of how I configured the Logicport to acquire the protocol data. And, now that I can actually see what’s happening and have a better understanding of the SPI-like console-to-controller communication, I should be all set to make a microcontroller behave like a Playstation 2 controller so I can spoof the PS2 and control it from other kinds of things.