Hi everybody! About two weeks ago I started prototyping a custom controller interface for PC using an Arduino, some simple breadboarding, and a little bit of software to back it all up. I'm actually quite happy with where this project is headed, and have decided to pursue it as one of our game company's next projects. As part of that, I thought I'd reach out to the TIGSource community to see what ya'll thought.

The basic concept is somewhat similar to how Twitch Plays Pokemon functions. That is, the controllers change the original intent of how a game is supposed to be played while encouraging a communal experience. What I've got so far are three printed circuit boards (PCBs), each with one button on them, wired into an Arduino Leonardo. The intent is to blow these things out into fully functional controllers with a few interesting twists to them eventually, but more on that later.

First, some pictures:

This is a breadboard prototype that I put together to ensure all of my code and circuits were working before I transitioned to PCBs. Note that at this stage I only had 2 controllers working on one split breadboard. I've since scaled up to 3 controllers.

There was some scotch drinking involved in the prototyping phase as well.

Hacking stuff can be a really messy process. In this picture I've taken over my dining room table to solder together the PCBs for the prototype controllers.

The final product (for now). Three PCBs with one button on them, all wired into an Arduino Leonardo. In the future, I plan on adding more buttons, joysticks, and some lights and knobs for other weird ideas.

What is this & Why am I doing it?

I recently had a conversation with another independent developer friend where I went into this in detail. I'm going to borrow from our conversation because (a) I think this hits it spot on, and (b) it'd be a lot to retype:

Quote

For one, the idea of creating hardware that fundamentally changes the way a game designer intended a game to be consumed appeals to me. So, when designing a game, we all have specific pieces of hardware in mind that dictate our direction. Typically revolving around the basic 3 things that most games take advantage of: a monitor display, a standard console or PC, and some kind of control device that conforms to normative standards.

The controllers I’m building right now actually combine each controller’s inputs into one uniform input (think Twitch Plays Pokemon, kind of), encouraging communal play for better, or even worse!! So for instance, competitive matches of HALO become an exercise in slapstick. It breaks something that many game designers take for granted: the way their media is consumed. Gonzo at its best.

Most importantly for me, though, is the fact that hardware hacking is democratic, meaning it gives players the ability to realize that they don’t have to accept norms presented to them. Emergent play is not something only generated through the software of the game, but the very things we use to interact with it. Games are not media only meant to be consumed, but to be interacted with by the consumer, and this is the best way I can think of doing that right now.

So I guess I look at it kind of as a political and community experiment. The plan is to build these things out into weird controllers that only vaguely resemble the ones we use today. To add dials and other functions to them that are in themselves games, like changing who controls what buttons, or how the inputs are averaged on the software end, or if players want to remove another person’s controller from the game. Basically, to enable people to play games they already may own in really weird ways.

One final thought: when the tools to create games became widely available and either free or cheap, we saw an increase in the diversity of ideas and opinions expressed in games (I’m channeling specifically Rise of the Videogame Zinesters here). Hardware is the next place for that to happen, I think. Microcontrollers, Raspberry Pi, etc have shown that we can make powerful but inexpensive hardware available. Now anybody with $30 and some rudimentary programming knowledge can change the way we interact with games. What interesting things could come out of that?

I'll leave you all with a video of some friends of mine playing Flappy Bird and Canabalt with the controllers this past Saturday. People really dug it, despite the fact that these puppies only have one button right now!

Thanks for tuning in! I hope to update this thread at least once a week with the newest controller build I have, and I may even pepper this with some basic instructions on how to get started with Arduino, mockups of my circuits for everyone to follow along with, etc.

What do you guys think about the idea? Any thoughts on how I can design these things to encourage the best communal play experience possible? Let me know!

Following up on my first post yesterday, I thought I'd give a little more information about the simple circuits I have set up for the controllers. First, here are the basic breadboard and electronic schematics:

This is a breadboard schematic. In this image I'm testing out two buttons (one for each of two controllers), by running 5v of power to the button, connecting the other side into ground, then connecting the pin parallel of ground into pins 8 and 9, respectively. More on how this works with the code in a second.

This is a more technical schematic of my initial setup.

When a button is pressed, it completes a circuit and sends a signal to the Arduino. So, if it's pin 8, on the Arduino side I have a conditional statement saying, essentially, "if pin 8 is pressed, log the time that it was pressed." In this way, I can match up the timing of button presses against each other to see if they've been pressed within a certain range of time (my current tolerance is 250 milliseconds). What this does is simulate concurrent button presses, without actually requiring players to press the button in synch every single press.

I'm going to be adding additional functionality to the controllers tomorrow (another button and a knob), so stay tuned! I expect to run into technical limitations soon with the pins I have available, at which point I'll have to switch over to making the controllers wireless either through bluetooth or wireless transmitters (using XBee).

If you have any ideas about how to make these "communal controllers" better (geared toward how a custom controller like this could create fun experiences for the largest amount of games they're used for), please let me know, and thanks for reading!

I've added another button to the PCBs and prototyped a second set of 3 controllers. I'm running into some expected scalability issues, which is forcing me to piggyback two Arduino Unos onto my Arduino Leonardo using SoftwareSerial. Not a big problem, but another added step in the process.

What's the goal of all of this? Well, with two sets of controllers, we can now play 2 player games! Expect to see some Pong and Divekick prototyping videos soon, but in the meantime, here are some new dev pictures.

The second set of controllers, breadboarded out for now.

Here are the PCB'ed controllers with two buttons. Ready to play Divekick!

More updates! Some of us got together today over at Lunar Giant's co-working/hackerspace SpaceLab 1 and put joysticks onto these things. The software side of everything still needs to be polished up, but they're almost to the point where we've realized an MVP. I have some interesting doodads that I'd still like to put on these guys, but the next step is really to make them wireless (as you can see, there are tons of wires on these guys right now). After that, we're going to make custom circuit boards, then wooden cases for the controllers.

Expect upcoming videos with us using these things to play games like Super Meat Boy, Divekick, and Mario.

Check it out!:

Tons and tons of wires! This is why these things are going to need to be wireless soon.

sOOOOO.... this is an interesting project (BUT) ... I am unclear on why you are building custom control pads. The core thing that you want to experiment with (communal controls), can be done with standard input devices, unless I am misunderstanding something. That said, I fully understand the fun of building custom control inputs, and I have done it myself. In fact I am going to build one this afternoon. But it is something that I wouldn't be able to accomplish with anything on the market already (multiple endless optical encoders and a fire detection thing).

This is a question I had to answer early on. The main problem is that decoding and re-encoding the inputs from standard control devices didn't seem to be a feasible first step in testing out whether the core concept worked or not. Hacking custom controllers, believe it or not, was a much faster and dirtier way to test the idea, especially since the end goal is to make this a hardware solution for flexibility's sake. However! The final form (or, one of the final forms) of this will absolutely to build a kind of "black box" that you can plug standard inputs into to play together for any console or PC.

That said, now that I've been working at these things for a couple weeks, I also see other benefits to hacking them. This'll be evident once I start attaching non-standard inputs and output displays to the controllers. These things are really going to get whacky!

This week has been spent cleaning up the stray little bits that I've been letting go in order to get these controllers up to prototyping strength as fast as possible. Very unsexy stuff, but necessary nonetheless.

To begin, up to this point I'd been painstakingly plugging each wire into the Arduino each time I wanted to demo it. That means every time I traveled to show the controllers off, I had to spend about 10-15 minutes rewiring everything and making sure it was all set up properly. Invariably, something wouldn't work right, and I'd have to re-check my wiring/code. So I decided to create my own Arduino shield.

To do this, I grabbed a stray protoboard that I had laying around and soldered the wires into their corresponding pins. I then soldered breakaway pins in on the opposite end, allowing me to essentially just "plug in" my shield to the Leonardo every time I wanted it to work. The soldering work was pretty sloppy on this because I was trying to explain the process to someone as I was going along. Apparently, I can't solder and talk at the same time! Check it out:

Next up, I purchased some radio frequency transmitters and receivers to play with the wireless component that I'll inevitably want to include on the controllers. This will (hopefully soon) remove the need for wires tethered to an Arduino at all, though I fear it'll up the cost of the form factor due to the need for additional Arduinos (I'm currently looking at Mini Pros), transmitters, receivers, and battery packs. Here's a picture (the receivers are the larger pieces):

I want to say thanks for the mention we got in the TIGSource Devlog, and to Andrea Portale for writing it up. This project has quickly become an obsession with many different branching ideas coming off of it, which is the whole reason I love to create and hack in the first place! I'll be posting new gameplay videos this weekend! Thanks for reading.

Newer Arduinos (Leonardo, Due, and Micro I believe?) have access to write to keyboard and mouse. That's where I began when I started this project, and where I'm still at, frankly, as I work on balancing these controllers. This is not ideal, as joystick input cannot be mapped properly for a game, but for now I'm using a joystick as a D-Pad (WASD).

After everything's balanced out, I'm going to jump over to a library called Unojoy, and hope to hell it's what this project is looking for: https://code.google.com/p/unojoy/

I also have a friend who's been focusing on interpreting inputs from standard controllers for about the past year who I may rope in later on with this project.

RE: additional devices, yes, I foresee a time in the very near future of this project where multiple Arduinos are going to be needed to handle the additional controllers this project is going to necessitate. I don't think even a Due would be able to handle all of the inputs.

Have been planning on open sourcing the code for this project, but was hesitant to do it until it was all cleaned up. Would you find it helpful if I just put it out into the wild now and you guys could all pick it apart?

Oy vey! After spending a good day fixing the controllers (which led to the discovery of an open circuit on one, and some broken code that was affecting them all), we're back on track! Check out this bad soldering job:

And this clever MacGyvered LED that I used to track down the open circuit that was causing the problem:

----------

After fixing various problems, I spent a good part of the first half of the week refactoring the joysticks and buttons on the controllers to create more interesting experiences for the players. Namely:

* Joysticks: instead of requiring players to move in synch, I have incorporated probability into movement. i.e. if 2 players are moving north, and one is moving east, the probability that the player-avatar will move north is higher than it moving east. This creates all sorts of funny jittery movement as players try to move together.

* Buttons: Inspired by the joysticks, buttons now function similarly. If 3 players (there are 3 controllers at the moment) all press a button within 250 milliseconds of each other, the button has a 100% chance of firing. 2 players? 20% chance of firing, and 20% chance of sustaining a button hold. 1 player? 10% chance of firing, and 10% chance of sustaining a button hold.

This still requires some fine-tuning, but so far, it's made the play experience much more interesting.

Next up for the controllers: bi-directional movement, an additional set of 3 controllers for multiplayer, and wireless connectivity.

of some of us attempting to play Super Meat Boy with the controllers. You'll hear me complaining about the lack of bi-directional movement, but actually, I think the controllers just needed more tuning at the time. Oh, and

For those of you interested in the newest circuit and breadboard schematics for the controllers, which now include joystick connectivity, check it out!:

The joysticks return vector output, which I've incorporated into the controller software by listening for ranges on the horizontal and vertical axes. Right now the joysticks function as simple D-Pads, but I'm hoping to soon incorporate a library which allows them to function as true joysticks. If you look closely at the breakout board that the joystick is attached to, you'll see that aside from having a vertical and horizontal output, there's also a button output. While we're currently not utilizing this, I'm leaving the door open for future iterations of the controllers.

There's been some interesting breakthroughs with Libity that I'd like to announce early next week/this weekend. Needless to say, your support on this forum has been a great boost to keep driving the progress of these controllers forward. So, thank you.