Last month I promised you I would make a game with an Arduino and Pulse Sensor. This was a promise made with the happy arrogance of a man who has never even tried to broadcast his pulse over the internet. I speak to you now from the other side of that experiential gulf. Here’s what happened.

It was maybe five years ago now that I heard about ‘Journey to the Wild Divine’, the $400+ meditation tool which comes bundled with a heart rate and skin conductivity sensor. I thought this was utterly remarkable stuff, and the idea of plugging myself into a computer and making a feather float using only the unmistakable power of my own calm was narcotic to me.

Imagine my delight then when, while browsing Boing Boing’s 2012 christmas gift list for ways to appease my family for another year, I came across this lovely little open source Pulse Sensor. A week or so later I was looking at some exciting boxes:

Of course I didn’t have any sort of idea how to use it, we’ll get to that. For those that don’t know, an Arduino is an open source microcontroller. If you remember playing with circuit boards and solder in school then this may feel familiar - the Arduino provides a current and allows the user to control the provision and manipulation of that current with code which can be loaded onto the board itself, or run on a computer while taking regular readings from the board.

How does it work?

The Pulse Sensor I am using is called a photoplethysmograph. This is a device which illuminates an organ (the skin in this case) and measures changes in light absorption. In this instance, that change is caused by the pulse wave which travels along arteries and capillary tissue when your heart beats. The analog signal which we read from the board is a fluctuation of voltage caused by the pulse wave itself. It looks a bit like this:

The physical setup was pleasingly simple. The Sensor itself needed treating with a little hot glue to keep the circuitry protected from grease and moisture and connects to the Arduino through it’s analog input pin. Once it’s all set up it looks like this:

At this stage it’s worth mentioning that pulling raw data from an Arduino and into the browser where I was working with it isn’t entirely trivial, and I wouldn’t have been able to do it so easily were it not for the fantastic Paul King’s Arduino Workshop held at Google Campus just down the road from our offices. Paul had us all loading our boards with Firmata and running a server to expose the data in the browser. Firmata provides a very usable set of calls to communicate with the board and it makes programming for Arduino in Javascript a cinch. For our purposes though, it isn’t practical, and the biggest headache of this project was absolutely figuring out how to get useful and usable data into our chosen environment - browser rendered html/css/javascript.

Getting the data

Using Firmata presents some other issues. The ability to derive an accurate pulse from the raw data relies on a high resolution image of the raw data. I need to be able to ask the sensor what it’s seeing very fast and very frequently, or the data I get back will be difficult to analyse well. The code which comes with the sensor polls the data every 2 milliseconds through the use of an 8 bit hardware timer on the board itself. If I use Firmata on the board then that timer isn’t running, and I haven’t been able to find a way to keep up that polling pace in Javascript, while also running any kind of other logic. Even when drawing a simple graph I would find 7-14 ms gaps in between samples and this just didn’t provide me with the data I need.

It quickly became apparent that running the pulse detection code on the board itself was crucial. The next stage of development was concerned with finding a reliable method to bring the resulting data in over the serial port, and into the browser - where our ultimate goal of course is to build a game. I decided to use Impact as the engine for this project because it’s a great tool for rapid prototyping. Nonetheless, choosing to work in the browser now had other consequences - your web browser can’t usually interface with your computers hardware like this, for security reasons.

Enter Node.js, a slick javascript platform for building network applications. With the excellent Serialport library, this separate tutorial and some last minute coaching on IRC  I was able to pass the BPM variable from the board, through the serial port to a node server which was being sent calls by the apache server running impact. Perfect! Now I can look at this:

Building a game

Now we have the data in the right place, we can start building a game around it. One of the advantages of Impact is that it’s shockingly fast to move from nothing at all to a populated 2d context. Within about 20 minutes I had moved from an integer for bpm to a simple side scrolling race game. You play against an AI opponent and try to beat him to the finish line by raising your heart rate.

The AI you’re racing against is a bit of a trick - every five seconds it looks at your BPM and adjusts the ‘virtual bpm’ of your opponent to be a small percentage above or below yours for the next interval. At the moment your opponent has a 33% chance of ending up faster than you at any given point so you could say it’s an easy game. We ran a number of trials, it’s pretty fun!

Clearly this is a long way from being a polished experience, but it opens the doors to a number of exciting possibilities. In the playlab offices we’ve been throwing ideas around for anything from a canabalt clone (with a special jump pad peripheral!) to a meditation trainer. I’d love to hear from you! We have another pulse sensor coming soon and with a little hackery we’ll have two running with nice long cables on the same machine.

Here’s my question if you’re still reading: There’s something very intimate about your pulse, it’s almost romantic. Especially if there are two people involved! How would you design a game which used this data to make people feel closer to each other? What kind of experience brings people closer together? I’d love to hear your thoughts, ping me on simon@playlablondon.co.uk. Oh and let’s get all the sex jokes out early because I know you’re thinking of some.

Incredibly, we’ve already rolled over into the second month of the year. At Playlab London we’ve been trying to turn 2013 into a year of Really Interesting Things, and part of that commitment involves getting stuck in to a whole bunch of experiments! - Simon’s going to talk us through the work he’s been putting in to a prototype called Socialite.

Socialite is being made in response to the V&A’s Britain 1700-1900 galleries. Spectacularly, the V&A is looking for a games design resident for the second half of 2013, and the application process called for proposals. I let my enthusiasm get away with me and built and prototyped an idea from scratch. Socialite intends to turn the way in which people interact with each other into something joyfully competitive and performative, while guiding them through the context and history of the V&A’s collection. The game is intended to be played on four networked mobile devices, but the prototype is delivered on one screen to allow for a faster turnaround in between iterations. 

When designing Socialite I wanted to create a lively game which would thrive on performative dispute - the idea put forward by Douglas Wilson of the brilliantly eclectic Copenhagen Game Collective. In his essay “Designing for the pleasures of disputation” which revolves around the notion that competition can be something which is playful and effectively pro-social in a group.

I wanted to turn a conversation into something like the fantastic Spaceteam, recently released on iOS by Henry Smith. It needed to be frantic, silly and fun, and in being that perhaps it could also make something joyful out of an activity that can be stressful for many.

The game picks up on the fascinating content of the V&A gallery, full of items exploring fashion, style and culture in the 18th century and explores the context of those artifacts. What would it be like to be at a party during that time? What items possessions might you gossip about? 

A round of play consisted of 3 minutes in which players are presented with the goal of emerging from a conversation having completed the most goals. Goals are commands like ‘Outrage Mr Garrick!’ or ‘Befriend Lady Pomp!’.

Over the course of two weeks spending what time I could spare developing this game I managed to squeeze in four playtests mostly thanks to my patient and understanding friends. The game really evolved, and I had the opportunity to apply a lot of learning in a short period of time. 

The first playtest looked a bit like this:

Our testers were really overwhelmed with the interface which was trying to convey an awful lot of information in a game strictly limited by time pressures. 

I found that there was a dissonance between the social and competitive aesthetics of the game-play. On one hand there was thought time being demanded by the notion of ‘winning’ a conversation, and having to figure out the best way to do so within a fairly complex system. On the other hand, the genuine social pressure of engaging in conversation with three other people requires a great deal of attention.

It became apparent almost immediately that the major challenge would be designing a game which could effectively balance the cognitive load generated by these two tasks. 

I experimented with a number of different options in order to make this work. The game changed from a rapid time pressured twitch response game into a turn and rounds based experience aiming to give people plenty of time to think.

‘Responses’ were added to give the conversation a chance to flow. The data model governing the players reactions to each other was simplified and the interface was completely reworked to give everyone less to focus on. 

The second and third playtests explored all of these different options. Here’s a video from playtest number three:

Things started to flow a little better. We found that the turns and rounds were too slow, but it became apparent that there was such a thing as an optimum number of players engaged in a task at once. Two people trying to talk out of four at any given moment seemed to be the sweet spot, and the code was re-factored to make changing that number a trivial thing to do.

During playtest 3 we started to talk about social proof scoring, procedural narrative and the feature which became ‘secret missions’. By the time playtest 4 rolled around I had cleaned up the interface even further, and it looked like this:  

Other new features included the chance to knock someone out of the conversation for up to 10 seconds by ‘outraging’ them and ‘secret missions’ which meant every player always had an immediate task to follow up on, like lowering their status or outraging another player. Here’s a video:

Things flowed well by this point, and my testers seemed to really be enjoying themselves. The game could diverge from this point in a whole glut of different and equally valid directions and that is an exciting point to inhabit with a design. 

In February we will be playing with an Arduino and Heart Rate Monitor to make games which make your pulse into a mechanic. I’m seriously looking forward to it.

After 3 months of design, testing and iteration we’re officially emerging from the code-face, soot-faced and sweaty, but proud to be clutching our newly beta’d run-around-n-talk-to-people em up ‘Keep Me Company Company’. 

There’s plenty still to do, but we’ll be sharing with you some of the lessons we have learned on the road to this place in this series of short articles.

“It’s something you can’t really understand unless you’ve been there”, said Dr. David Carraher… Dr Kathryn Krogh…was more blunt: “I was afraid I was going to throw up.” … “My head sank between my knees… I actually felt as if I were going to perish.” 
 
These people are responding to a traumatic situation, but it probably isn’t what you think. All three quotes are taken from reports by participants in a breaching experiment, a test which examines peoples responses to the violation of established social norms. All three of these quotes are taken from people who have been told to ask for a seat in a New York City subway car despite being able to stand.

It seems like an extraordinary response, but anxiety or even anger were the most regularly observed results of a contravention of expected social behaviours. Breaching experiments were first proposed by Harold Garfinkel in response to what in the 1940’s the burgeoning field of social sciences considered the mystery of social order, or in other words; why do we stand in line?

“it is a social rule that ordinary citizens should not pick up garbage from the street, or mend street signs, or otherwise fix problems.” - Earl Babbie

Even actions we might view as positive are not exempt from the anxiety prompted by a breach; in ‘the inexplicable do-gooder’ Earl Babbie found that people respond negatively to others taking on a repair job not considered within their purview. Seemingly positive acts such as this were even viewed as personal intrusions.
 
We found ourselves brushing up against this breaching wall in the course of our experiences testing KMCC. Many found themselves having trouble with the idea of instigating unusually prosocial behaviour. Some players reported feeling as though it was disingenuous to be uncommonly nice, others felt as though the idea of ‘keeping people company’ for the sake of it was in some way not covalent with their self image, or simply made them uncomfortable.
 
These responses were far from being in the majority, but a sense of discomfort or anxiety at being asked to behave in an unusually nice way for an unusually nice reason was replicated enough times to be significant.
 
We’re concluding that the fault lies with our game design, and not fundamentally with the premise of encouraging positive outcomes with gameplay. Extraordinary behaviours require extraordinary contexts and many games achieve prosocial outcomes in more nuanced ways. Running games which tasked players with seeking out others to perform symbolically violent acts often produced powerfully positive behaviours, even between adversaries. Marrying together applied psychological and sociological concepts with game design principles was always going to be a challenge and it seems like, in pursuing theory we have lost sight of the principle of a fluid and fun game design. It’s something we absolutely plan to learn from for upcoming iterations, and in the mean-time it is an utterly fascinating area to be investigating.

We’re back, after a fortnight skipping between UK music festivals and running our newly beta’d run-around-n-talk-to-people em up ‘Keep Me Company Company’.

KMCC casts players as executives in company which profits from the social feats performed by it’s employees. Those playing collect points (‘bucks’) which accumulate in a central pool to bolster the companies share in a fictional market, against competitors such as UnSociable inc. The game ends when the company has gathered 100% dominance of the market place.

KMCC was conceived as an engine for visualising, raising and sustaining an area’s Jen ratio, a measure of the social well being of an environment proposed by positive psychologist Dacher Keltner. The index was named for the Confucian concept of Jen;

“A person of jen, Confucius observes, “wishing to establish his own character, also establishes the character of others,” and “brings the good things of others to completion and does not bring the bad things of others to completion.”

We’ve learned a lot from iterating this game with the public and we’re keen to put that knowledge into practice. Expect a more detailed dissection of our experience very soon.

“One way or another, if human evolution is to go on, we shall have to learn to enjoy life more thoroughly” _{- Mihaly Csikszentmihalyi}

At playlab we are big fans of the idea that a game framework is a potent tool for affecting our behaviour. We also have a firm belief in the idea that if you are going to step forward into the field of applied sociology, then it ought to be done with a grasp of some theory. 

We developed +sum this year in order to produce an engine for visualising, raising and sustaining an area’s Jen ratio, a measure of the social well being of an environment designed by positive psychologist Dacher Keltner to quantify the ratio of positive and negative micro-interactions between strangers. In the process we also created the technical framework which supports it - a framework for the delivery of missions to players, and the ability for players to receive points, give points, share messages and collaborate on completing those missions.

HOW IT WORKS

+sum players are all on the same team and competing to fulfill the same global goal. The global goal is designed to visualise an area’s Jen ratio. Points are the currency by which positive ‘Jen’ is transferred, and in asking players to award each other points for positive actions completed we put them in the position of researcher, giving us a fairly live and fluid measurement of the positive interactions in a space. 

Players are given a visual icon to alert other players to their engagement in the game, and delivered missions by the web-app sitting doing the counting behind the scenes. These missions require the completion of a quick social task, informed in it’s design by the fulfiment of some point along Maslow’s hierarchy of needs. We designed a quick probability schema, ensuring that tasks which were simple to acheive were delivered more consistently than tasks which were complex. 

DOES IT WORK

Well we certainly learned a lot from installing this game into a social space. We’ll be leveraging all of that data into the next version of the software, which will come complete with an all new lick of paint, and narrative iconography - just in time for some music festivals this summer. More on that very soon. 

If you’re interested in learning more, or in having us install +sum in your bar, club or social space - let us know at hello@playlablondon.co.uk.