The new Socialbomb boards have been prototyped, printed, and soldered up — and they work perfectly! Adam, Scott and I are working on some backend changes now, but the guts are happy and working at last.

User testing to follow shortly!

So I’m not sure I’ve mentioned this here in any detail, but Adam, Scott and I are taking a revised version of our way-fun Socialbomb game pieces to O’Reilly E-Tech this year (err, in two weeks).  We’re absolutely thrilled and honored to be part of such an amazing conference, and stoked to get to head out and see what some of the brightest minds in emerging technology are doing (ours not included).

Of course, this has lead to board redesigns, code updates, and a chance to try things we didn’t get right the first time.  This has meant 12-hour days of writing, testing and part-ordering, and will soon lead to 16-hour days of soldering, cursing and whimpering, but we’re all really excited to have a second chance to do the designs how we wanted and get to show them to such a fantastic audience.

More to follow as soon, um, well as soon as we do it!

So soldering this lil’ guy up wasn’t nearly as hard as it looked, and it actually works!

…because that’s how I roll.

In case anybody cares, this is our official “what the f#&$ do we do?” statement:

Social Bomb is a game about social circles and quantified reputation scores. The current version is designed to accommodate 15-20 players. Each player is awarded points for being near players with higher reputations, and penalized for being near players with lower reputations. Bonuses and penalties are applied according to overall social promiscuity and status. The player with the worst reputation score is the ‘Social Bomb.’ Their score will have the most negative impact on a social circle.

Social Bomb is designed to be played in real-world social environments. Players are given small devices that house a microcontroller, a radio transceiver, and a numeric display. When two players come within conversation distance, their scores are slowly averaged. This is reflected on the numeric displays, which serve as a constant reminder of who outranks who and what effect players will have on each others’ score. The algorithms that determine the score are not simple, however – interactions involving multiple players are reflective of the group average. Longer conversations are worth bonus points, and superior social networking skills can reap exponential rewards down the line by increasing a player’s social momentum. Conversely, if a player is anti-social and aloof, they will soon begin losing points. If they’re not careful, they can become the ‘Social Bomb,’ and will have great difficulty finding receptive companionship in the game.

In addition to the score displayed on the players’ device – recent scores, bonuses, and penalties are visible on a public leader board. This hub provides a public record of interaction data. Players can check their overall game standing and strategize to improve their social rank by seeking out the most popular players in the game.

Social Bomb was created by Michael Dory, Adam Simon, and Scott Varland at NYU’s Interactive Telecommunication Program (ITP).

(phew part II!)

Oh, and since I’m not sure I ever posted pictures of the final products, here’s that:

Seriously. Just go to the site.

Neat, huh?

Adam and I have been working on the site as well (while Scott has bravely tackled a pile of code bugs). It’s nice. You should go see it.

This has been the excuse I’ve been waiting for to (A) try out Coda (it rules), (B) make a website that doesn’t suck, and (C) show off our neato project more. CSS is fun!

The good news so far is that it looks like powering our devices off AA or AAA batteries won’t be too far of a stretch (for a day or two at most). Here’s a fully-programmed board with screen, Atmega8 chip, XBee and LED (with 10k) resistor:

initally, it seemed like it was drawing about 160mA at 2.9v or so, but I messed around with things and finally found that taking the two status LED’s on the XBee off and putting a resistor on the general status LED brought it way down, fortunately, only drawing 100mA at 3.0v:

I looked at a lot of rechargables (NiCad and NiMH), which start at about 1000mA and 700mA (in the AA and AAA format, respectively). However, alkalines have something like 2850mAh to offer — so in theory, at that rate, we could get (maybe) 16-18 hours of usable power? Maybe? Testing must follow. The suggestion at the moment is that when we get a base station up and running and have a pretty good idea of code we want, we can set up a board with batteries, leave them with the base, and then use a Maxim 8212 voltage trigger to watch the voltage — and when it drops below the threshold (say 2.4v or so), have it trigger another XBee to wake up and quickly send a death knell to base.

In other good news, we now have the XBees talking happily, sending scores back and forth. Few things are more fun after hours of coding and moving wires around than flooding someone else’s screen with your own name:

The proximity code is buggy, but it works. Sorta. That should be fixed in the next day or so.

And I’m not sure I’d shown the actual clock yet. This is how the clock looks in use:

The screens are WEIRD — they have the strangest power issues, and will go completely nuts if plugged into one side of the board (while acting completely fine if on the other). NO idea why.

Much more to do — I’ll keep posting as things get checked off the To-Do list.

They talk!, by doryexmachina.

Adam, Scott and I have been bashing away at getting our XBee friends talking. They do! Sometimes. Occasionally. When they feel like it. It’s like dealing with an ADHD-addled teenager. I’m sure that’s mostly my fault.

Anyhoo — good news to follow, once they’re working a bit better.

My pong paddle (and housing), by doryexmachina.

Right, so I should have written this up EONS ago, but I got caught up in doing everything else, then going to SXSW, then all that “work” stuff I hear so much about. I’ll do a really nice writeup of the technical details shortly, but for now, here’s a litte about it.

A few weeks back we had ourselves a real nice Pong game in Networked Objects — however, as with all things in NetObjects, there was a pretty sizable catch: all communication with the Pong server had to be over internet cable and done through an XPort module. This was fiendishly hard to set up initially (at least for me, as I don’t have all that much experience working with things that don’t tell you if they’re working properly or not) (grr!), but it worked out pretty nicely. Got my Arduino talking to the XPort, which allowed me to send data over the hard line to any other wired computer running the pong server code. In class, that meant connecting to Tom’s computer.

Here’s what the board looked like before I covered all the mess with the fibercore housing:

Left to right on the image, that’s the old-school Atari paddle (obviously), then a bunch of LED’s, a reset switch, the mini arduino, the Xport, a 3.3v regulatr, and the USB-Serial device.

So then, the game (nicely featured in MAKE as well)!

This was my controller:

Up close, left side:

Up close, right side:

From the front (thats the XPort sticking out):

And in action during class:

Technical details to follow!

I’m working with Adam and Scott on creating a game based on social interactions. This game would likely involve 15-20 players (as it requires physical devices and we can only make so many), where players are awarded points for being around other players with higher point values and penalized for being around players with lower point scores — essentially, a study of “being cool” in social situations (in game format).

The devices we’re creating are essentially small pendants that house a microcontroller setup, a wireless communication device and a numerical readout display (probably four digits). Players would be given the devices, and then told to go talk to other players, with the only hard rule being that the player with the highest score at the end of the game wins. The game will really get going when players start to become less conscious of their interactions with people and go about their usual business.We’re still working out the math and rules of what exactly happens when an interaction occurs, but the most basic idea is that when two players come within what we’d consider “talking distance” (about three feet apart or less), each player would receive points, and their displays would reflect this. Interactions involving multiple players at once are weighted as exponentially more valuable. The deeper rules would involve all scores going up or down around a bell curve, but that’s a bit deeper than we may have time to do before semester’s end. The interaction data is then going to be collected by a base station each time the unit passes within range, and graphed out on a screen in the lounge, likely featuring top players, their scores, and possibly a bit about who they’ve been connecting to (though that opens a whole other door of issues which we may do well to avoid).

For the Designing for Constraints side of things, there’s a LOT to work with here. I think to start out, I’m looking to make a Flash mockup for the physical interaction side of our game (so that we can see if people actually understand and can make use of the devices and the data), and in our case this is probably going to work best if I can create objects that can be dragged around the screen. My plan at the moment is to create both a fake physical mockup of the device (that probably won’t actually work, but will look the part) and a Flash mockup of the gameplay so that we can test both on users and make the necessary adjustments to our devices and to the game ruleset. As with any game, people are probably only going to play this game if it’s easy to understand and generally fun to play, and the latter is going to require a lot of testing to get right, I’m sure.

So far, the early mockup looks like this (outside, and then with hidden walls):

This was all inspired heavily by some of the passively multiplayer games we’d seen online (like this and this and then this one here), as well as a lot that Adam and I had gleaned from SXSW. Part of that included that games need to be enjoyable to play, or people won’t do so. I realize that should be a “well, duh” kind of statement, but it wasn’t until that was discussed, at length, by Dennis Crowley and Kevin Slavin at a SXSW panel that it really sunk in all the way. Also, inspired by that same panel, was the value of statistics and how good data can often inspire competition — as Dennis was saying at one point, just having data collected from a pedometer leads to a friendly competition, as you see if you can go a bit further than your friends, take the stairs to get a few extra steps, etc. I feel the same way about Last*FM, as I find myself often listening to just one more song by a certain artist or two to boost the count one way or the other — I just can’t help it!

Anyhoo, so there’s a TON of work still to do, but we’re working away madly. More updates to follow shortly.