One of the biggest challenges in appropriative game design, is computational quantification of action. How do you prove something happened, and to a lesser extent, how can you objectively inform a computational structure that something happened?
It all comes down to the tag problem. Observe any game of tag, at some point there will be a disagreement about whether or not a tag was made. When I teach on this topic, my student’s first assignment is to develop a method to quantify a tag and then inform a computational shell of the tag. Their second assignment is to then have the shell inform all players that the tag has been made.
Typically I see different riffs on the same methods, but I’m always looking for more. I’ve also been trying to abstract those methods into general approaches. Now I’m biased towards pervasive gaming and utilizing mid to high-end consumer mobile devices so this list is influenced by that. …this is also a very raw, and incomplete, draft.
Approaches to Collision Detection in the Real World
Network Proximity: Essentially if while scanning for connections over an ad-hoc network, if Device A can “see” Device B for X amount of time, a tag is made.
I’ve nicknamed this method “missile lock.” While using mobile devices and Bluetooth, I’ve found that the tag radius is ~30 yards and a time period of ~30 seconds of continued presence to establish the tag works fairly well.
Optical Recognition- Scan: If Player A is able to optically scan a barcode/glyph on Player B with his/her mobile device, a tag is made.
I’ve played with this one a lot, and have observed some interesting emergent behaviors. Before I get ahead of myself, I generally use Shotcodes linking to Php/AJAX websites to make the mechanic work.
The interesting emergent behaviors I mentioned generally are all a reaction to the Shotcode client’s effective range on mobile devices. First of all, the client doesn’t support zoom. A colleague of mine hacked the client and enabled zoom, but doing so greatly degraded scanning performance. Regardless, the effective scanning range of a Shotcode-enabled device is ~2 feet or less for a Shotcode with a 1-2 inch radius. As you would imagine, range increases as the size of the Shotcode increases. I haven’t worked out a specific size to range relational table yet, but how big are you going to make a Shotcode if you are planning to stick it on a player?
So in an interesting reaction to the limited effective scan range of the majority of Shotcode-enabled devices, innovative players actually used digitial SLR cameras to take snap photos of targeted shotcodes from long range and then scanned them off of the SLR’s LCD screen. Rather than outlaw this mechanic, I’ve decided to embrace it in my games.
Optical Recognition- Photo Recognition: I’m including this because it inevitable gets brought up in conversations. The base mechanic is that if Player A is able to take a recognizable picture of Player B, a tag is made.
I’m not a fan of this method because simply because it is in-exact. I’ve yet to work with affordable and/or reliable facial recognition software with which to automate this task. You can leave it to a human referee, and that is a legitimate low-tech approach, but I just haven’t found it to be a very interesting mechanic in practice. Granted after a few mundane tests I’ve pretty much shelved the idea, but I haven’t seen anyone else do it in an interesting fashion.
Physical Tag- “The Button”: A few times we had the idea of attaching a button of sorts to players. The idea was a tag would be made if some chased them down and pushed the button. After this resulted in a gang tackle or two, we moved one.
Physical Tag w/ Consensual Reporting: Saving the best for last (in this post at least), this tagging mechanic has worked the best in the most situations I’ve tried it in. Under this model, players tag each other in the same way they’ve been tagging each other since they started playing tag…physically, with their hands.
So Player A chases down Player B and tags him/her. Player A sends an SMS to the game server that reads, “Tagged B.” The game software then moves both players into a ‘purgatory’ queue until the tagged is resolved. If Player B agrees that a tag was made, he/she would SMS the server “Tagged By A.” If Player B disagreed with the tag, both players remain in purgatory until Player B consents to the tag or Player A withdraws the tag by texting “Untag B” to the server.
…so that’s my short list, does anyone have any other interesting mechanics they are experimenting with?
I’ve been jumping back into Google Maps as game engine mode, and was made a aware last night that a fun little bug/easter egg still exists in the API. Around 8 months ago, it was a pretty big deal for a day or two when it was discovered that 
I’d be remiss if I didn’t point out that 
World of Warcraft’s latest content patch provided players with Guild Banks, a feature long sought after by players. Interestingly enough this new common space has already been appropriated for new forms of emergent play.
I know I am way late to the party on this book, but I’ve been busy and it is clear that 
As I’m finally getting down to reviewing the Google’s mobile 
This is everywhere this morning. If you aren’t familiar with 
In about a week and a half,