It started as a joke the other day. I posted a tweet that read, “A game with no input whatsoever. It cannot be controlled.” At the time, I was thinking something that was openly hostile to the player. The more they tried to “play,” the more it would stop the player from doing things. It would seem as if it would take keyboard input, as one example I thought of, but actually cut the input at different, random times. More dickish than difficult, as it were.

But, as the conversation on Twitter turned out, we began to think about the game interacting with the player. About the ‘input’ coming from things we normally take for granted like the system time or what might be installed along with the game. And things like save files and what else might be running in memory too, as two more things that might be ‘read’ as input. (See Shareacart1000 as an amazing execution of the save file idea.)

It was an interesting conversation and one that has stayed with me for the last week or so. The more I have thought about what it might mean to have button pressing (or none at all), the more, in my mind at least, the normalization of the body has entered into the equation. It’s something I have been thinking about a great deal lately, about how much the body is erased or “drown” even during what we might think of as immersion.

This morning, though, as part of some research I’m been doing into motion control and detection, I came across Headtrackr. It’s a JavaScript library that uses the getUserMedia hook (available only in the latest versions of browsers and on limited systems, unfortunately) and some detection algorithms to pick out a ‘head’ and then track it within a window. By creating events, listener functions can be called when the detected head moves and where it is within the greater window.

It’s what enabled me to create Head Breaker earlier today. It’s a mash-up of Breakout (from the Phaser.io example collection) and Headtrackr. By moving your head left or right, you move the paddle. Your direct neck movements become how the game is ‘played.’  Except for the initial click or touch, there is no other ‘input’ — well, discounting the camera itself.

After playing with the camera for a few hours this morning, and seeing how the more you involve a ‘body,’ the messier the input gets, it’s what I settled on as an interesting demo for other people to see what is possible. A cleaned up example of some of the other things I’d like to create and release next. In fact, since I’m going on a “No Input” kick for a little while, I thought I would invite others along for the ride.

So, here’s the challenge: create a game that has little to no direct input in a traditional sense. Motion detection and controls are all in, but not controllers or keyboards. Camera-based input is even better. Anything that would have been facing the player like a camera or microphone, or is part of the computing environment like system time or variables, are all recommended.

I’m going to post my projects on Google+ and Twitter (as I usually do). So, if you take this up, please let me know. I’d be more than happy to promote work on this challenge.