The Making of Searchlight

24 September 2012 | 0 comments

Searchlight at the HIde&Seek Weekender 2012 from Hide&Seek on Vimeo.

Searchlight came out of one goal: to design an interesting game for Kinect.

Working on The Building Is… in Paris left us with a lot of knowledge and ideas about how to integrate technology into real-world physical games, and we wanted to test them out. The Kinect is versatile, powerful, and jam-packed with sensors, so it seemed like a good tool to experiment with.

The motivation

When dealing with new tech – especially when creating a game based around a new piece of technology – it’s tempting to design the game based on the technology’s affordances.

We wanted to stay away from doing this: YouTube has a lot of videos of Kinect-driven hand-waving operated helicopters, people magically holding swords and light sabres, and even quadrocopters playing tennis. I can watch those videos for hours because they look really cool, but cool doesn’t necessarily translate to fun.

Kinect is often specifically thought of as a gesture control device, to the exclusion of characteristics: the ability to track human skeletons in general, and its combination of a RGB camera, an infrared depth camera, and a microphone array. In these contexts, unlike gesture-based interaction, the Kinect isn’t necessarily waiting for people to do a specific series of movements or behaviors. One of the really magical things about the Kinect device is that unlike so many bits of technology, you don’t have to be near it, or touch it, or even be looking at it in order to interact with it. You don’t even have to know it’s there.

Our goals were based around this concept – that interacting with the Kinect doesn’t have to be about the Kinect. So we set some ground rules for our game: first and foremost, people were going to interact with real-world objects. To this end, it couldn’t involve any screens, and players shouldn’t need to understand the technology in order to do well and have a good time.

Our other goal was non-technical, and related to the context of the Hide&Seek Weekender where it was to be played: we wanted something that adults and children could enjoy equally, and that they could play together.

The rules

When creating The Building Is… , we came to understand that learning to interact with a new type of system takes a lot of focus. We forget this because most people have already learned to interact with computers and video game consoles in virtual spaces, and learned to play with other people in physical spaces as children.

However, learning to play with technology in physical spaces is less familiar to many, and especially in games that will only last a few minutes, we have to take into account this – for lack of a better phrase – difficulty multiplier. Creating something that is easy to watch and immediately understand really helps.

Part of an understandable interface involves what people can see: when players are surrounded by the interface and have to turn their head to look at things, they actually have to remember to turn their head. Something that looks like a two-dimensional playing space is easier to navigate and understand than a three-dimensional space, so we wanted to keep this playspace fairly two-dimensional to be easy for people to take in. We also wanted any digital aspects to be somewhat consistent and predictable.

It’s much easier for people to behave correctly when all of the rules, and the consequences of their actions, are transparent from the outset. Technology can be pretty obscure, and we didn’t want people to need an accurate mental model of what was happening in the technology to understand what the best strategies were. So we opted for a tried-and-true interaction mechanic – detecting movement and position.

The original design for the game was basically Grandmother’s Footsteps where Grandmother is the Kinect and projector, and, rather than having to freeze whenever Grandmother is facing the players, they freeze whenever the projector was shining light at them.

Before we even started play testing, we ran into a space limitation: Kinect’s depth sensors can only see a certain distance (8 meters, at the very extreme), which isn’t all that far when the sensor is suspended from a technical rig 3 or 4 meters high. It meant that it was going to be a pretty short game of Grandmother’s Footsteps unless players had to stay still for almost all the time. Compounding the problem, we realized that in in this game, Kinect would essentially be stealing a role that people like to play – catching out people who move.

So we changed the layout to a game where players run back and forth in front of the projector and Kinect, rather than towards it. This meant we needed a new goal, since being the first player to the front wasn’t going to work. We decided that players had to compete to carry props from one side to another.

The technology

As soon as we knew that the basic game mechanic would be detecting movement, I started programming the Kinect. Because it’s a technology I hadn’t used before in this way, I wanted to get a big head start making sure that it could do what we wanted, with all the constraints that we were throwing at it.

The program was made to be flexible, so that it could handle changes in the game design, but I decided early on not to use Kinect’s skeletal tracking to do the motion sensing. This decision was made for two reasons: I wanted to be able to detect motion of props as well as players; and I didn’t want to run into problems with the Kinect losing track of skeletons because people were crossing paths, and possibly hiding behind each other or being obscured. (That would have been one of those terrible situations where players who don’t understand the technology don’t understand why the game isn’t working.)

In play testing, we experimented with different patterns of searchlights – we originally had the rotating beam (like a lighthouse light) that became the final searchlight; a roving circle of light; a bar of light that moved vertically ‘down’ the space; and – my personal favorite – a circle of light that started small in the center of the space and quickly expanded to fill the entire space.

The expanding circle of light was fun to watch people play, because everyone had an “Oh no, what is happening!” moment of panic – but players panicked and had difficulty quickly responding. We settled on the rotating beam, because it feels like a searchlight, and it’s easy to predict without being easy to avoid.

I spent a lot of time tweaking the motion detection’s sensitivity. This is what would make or break the game: if players didn’t trust that the technology was correctly catching them when they moved, every time they moved, they would get frustrated and the game wouldn’t hold together. It went through many iterations – some too sensitive, some not sensitive enough, and some where it was almost always good but every once in a while would be slightly too sensitive. In the end, we erred on the side of being a bit forgiving, because getting away with something is much less frustrating than being caught undeservingly.

What the computer thinks it’s projecting

How it looks in the real world – upside-down and backwards, with only the colors showing up

The design

As the programming and technology side of the game progressed, we set aside time to playtest, but we hadn’t worked out what the props should be. We originally used books, chairs, umbrellas, and other objects from the office cupboard. In my head, I wanted there to be houseplants (imagine trying to freeze in place while carrying a long grass or fern). But as so often happens in game design, serendipity came to the rescue.

We had no house plants to hand, so we pulled out a box of Kubb blocks (the game of ‘Viking chess’) from the cupboard as stand-in props, and it turned out that they were the perfect size and heft to make holding one easy but two slightly awkward. Balancing them on top of each other added an element of risk – would the searchlight catch them if they went toppling to the ground?

At that point, we got some extra wooden balls to add to the shapes, and painted everything white. With these props it became a cooperative game, where each person had the same number of props to take off, and some props where they had to take turns removing them.

We tinkered with the exact rules right up until the game was played – this is an advantage of having players interact with physical objects. When the entire game is run by a computer, most of these decisions must be made far in advance, and some decisions (like competitive or cooperative play, and how many players there will be) are very difficult to change later. In this game, the computer didn’t care about any of those aspects, so we had a lot of freedom to change the rules to fit how the game evolved.

Emergent characteristics

There were some interesting play styles that came out of the game. The continual push to make the mechanic simple and transparent meant the game was easily grasped by all ages, but careful placement of the blocks created an opportunity for strategy. While some players struggled to not get caught – especially when they were standing in the middle of the play space, and the light was approaching them from behind – most quickly caught on and were able to decide whether to freeze or risk jumping or running to avoid being caught.

Players originally focus on avoiding the light – and many children remain at this level and enjoyed repeat play. However, more advanced players develop strategies about how many blocks to collect at one time, when to move, which blocks to collect first, and how to coordinate movement with their partner.

Because players are only allowed to touch their own blocks (the blue player collects blue-striped blocks and similarly the yellow player collects yellow-striped blocks), when one player is faster than the other there is a continual urge to cheat; very few players are able to watch as time runs up and their partner is being slow.

And when one player makes a mistake, both players suffer, which often leads to a moment of laughing accusation. Often times when players lose, it’s because one of the players see the searchlight coming from behind them and doesn’t notice when it catches them; but their partner does notice, and really gets upset about it. The culprit will look up when they lose and say, “what happened?” and their partner will say, “You. You set it off!”

Some players came back again and again to try and set the highest time; learning along the way that jumping never works, and getting increasingly frustrated watching other players get caught, or – even worse – freeze when they didn’t have to, giving them an unnecessarily longer time.

The future of Searchlight

In the end, the biggest problem with the game is resetting the blocks at the end of the game. It takes about as long to reset as it does to play, which slows down the flow of the game substantially.

There are other little questions to answer – should we make the searchlight catch rolling blocks and balls? Should it be slightly more fine-tuned to catch the runners who push their luck? Should we allow children to have extra chances, or a more forgiving searchlight?

I have no idea! But the enthusiasm of everyone who played it at the Weekender means we’ll hopefully have some chances to play Searchlight again, and to answer all these questions.

0 comments on this post.

Comments on this post are now closed.

Related Projects

Latest blogposts from Linden