Pre-Columbian Internet Geography

This photograph is my second “Truman Show” moment, near the end of day four of walking the Inca Trail, with this bit of exposed infrastructure along the seam where mountain meets trail. An abrupt reminder that the trail is maintained in the contemporary sense, pretty much exclusively for visitors using it as I was — to have a nice if a bit grueling four day trek through the Andes. (Likely this bit of electrical plumbing ran power and communications between a restaurant/lodge a few kilometers from the final “Sun Gate” milestone.)

The trail was presumed built by order of an Inca back in the day to allow for a proper system of communicating messages as well as goods. It connected all of the villages throughout the Empire, which extended throughout what is now Peru, as well as today’s Bolivia, Ecuador, Chile and Argentina.

It’s often described as a road system, but the Near Future Laboratory can only grok it as a larger system of communication very much like today’s Internet, mostly because of the mechanics of its formal protocols. It was not just something for one to walk along to get from point A to point B. It’s possible to speculate that it was built as a way of adhering social / power relations, creating an assemblage that included royal (the Inca King) control through messaging, maintaining control over borders, dispersing warriors and their power, transporting food, routing vital water along its intricate right-of-way. The protocol allowed for a system of runners operating in relay moving impossibly fast along the trail.

Every four years a race is held, running the trail from kilometer 82 to Machu Picchu, about 45 kilometers total. The current record time? 3 hours and 12 minutes. Today, it’s traveled by at most 500 people a day so that, for the typical 4 day trek, you’re on the trail with 2000 other people. (Only near the beginning at kilometer 82 did it appear to be bustling. Along the way, it was only occasionally that we ran into other people.)

A Google Earth KML file of the trek, recorded along the way with a GPS device.

Continue reading Pre-Columbian Internet Geography

Battleship:GoogleEarth (a 1st Life/2nd Life mashup)

I’ve started working on a bit of summer laboratory experiment to see how Google Earth could become a platform for realtime mobile gaming. (Follow the link on the Flickr photo page to the URL you can load in your Google Earth client to see the game board in its current state.)

With Google Earth open enough to place objects dynamically using the tag, a bit of SketchUp modeling and borrowing an enormous battleship model that construction dude uploaded to the SketchUp/Google 3D Warehouse, I started plugging away at a simple game mechanic based on the old Milton Bradley Battleship game.

Battleship, for those of you who never played, has a simple mechanic — two players set up their navy ships on a peg board, hidden from the other guy. You take turns plugging a peg into your side of the board, with each peg hole designated by a letter/number coordinate grid. When you plug a peg in, you say where you put it — E4! If your opponent has a ship in that coordinate (or part of one, actually), they say, sorrowfully, “Hit!” and you register that peg hole with a color to indicate a hit. If not, you just put in a neutral peg to remind you that you already tried that spot. The game continues into one player has sunk all the other guys ships.

The mechanic I’m experimenting with is simpler. One person places their ships using Google Earth and the other person goes out in the normal world with a mobile phone, a GPS connected to the mobile phone. The phone has a small Python script on it that reads the GPS and sends the data to the game engine, which then updates the Google Earth KML model showing the current state of the game grid. When the player who’s trying to sink the ships wants to try for a hit, they call into the game engine and say “drop”. The game reads back the coordinates at which the “peg” was dropped and shortly thereafter, the other player will see the peg appear at the coordinate it was dropped. If the peg hits one of the ships, it’s a Hit, otherwise it’s a miss.


Next Steps
As I continue developing the engine, I’ll probably have the game engine let you know when you call in to do the “drop” whether it was a hit or not, or the opposing player can text or call to indicate the same.I want to put in a “ping” command for the call-in battleship control center to help whoever’s wandering around in the world navigate a bit. (Although the game is only really practical if you limit the boundaries over which it can be played.)

I need a lighter weight battleship — the current SketchUp model is too large, in data size terms and takes too long to initially load (although, it only needs to be loaded once.)

* Experiment with “1st Life” action reflected in “2nd Life” worlds (verso of the folly Ender suffered in Orson Scott Card’s simply fascinating Ender’s Game
* Learn KML
* Learn SketchUp
* Learn Python for S60
* Make a mobile/pervasive game in which one has to move around in order to play Equipment
* Google Earth client
* Apache+Tomcat+MySQL (Java and JSP on the server-side computer)
* Nokia N70 and a little Python app to connect to the Bluetooth GPS and upload the data to the server
* Voice Application (for the battleship control center to drop/ping)
* SketchUp Time Committed
* About 2 days learning stuff, and 1/2 a day programming the computer to make it do things.Why do I blog this?To keep track of and share the near future laboratory experiments I’m doing this summer.

Technorati Tags: , , , ,

Sightseeing Oprah Winfrey Crop Circles with Google Satellite Maps

Stumbled across this Google Maps..thing. It’s not quite collaborative mapping, but it has a draw.

Sightseeing with Google Satellite Maps

I’ve added it to my Google Maps Mash-Up Bibliography. (I know, I know, other sites catalog Google Maps Map Things. I’m not playing the “been-here-first” game — I just want something that I can taxonomize and hierarchicize and annotate as befits my own brain.)

Why do I blog this? This Sightseeing Google Satellite Maps thing isn’t a “mash-up” in the same way that these others are, which gets me thinking that the mash-up is about instrumentalizing social practices and doing the GIS map-making thing. Take crime (a socially embedded practice), instrumentalize it if it isn’t already (Seattle provides public access to its 911 calls data in a machine-friendly structure), and cobble it together with Google Maps open API.

The Sightseeing Google Satellite Maps project takes a social practice, doesn’t bother to instrumentalize it except to find out where a particular “sight” in the world is, and uses a God’s eye POV to show you that sight. Why is this at all interesting? It adds a bit more precision to what the mash-up idiom means, in the context of Google Maps. It’s always been all about [w:AJAX] or whatever, and there’s a social AJAX going on with these Sightseeing projects.

Once the fascination with figuring out the Google Maps API wears off, what’ll be left? I’m speculating that collaborative mapping will be the compelling upside, perhaps. Creating maps with lots of people, with a utility that goes beyond just saying where you grew up. And that has a specific point-of-entry for a specific task that makes the practice more legible for a self-identifying audience (people who need to know which powerlines are down or what tree needs to be trimmed back, or where the dumping violation is occuring.)

By the way, Mark Bolas and I are teaching the 1st year MFA students in the “mobile module” of their introductory course, how to work with the Google Maps API. They’re supposed to learn about “mobile” and we extended that to location and mapping. They’re also supposed to learn some prototyping skills. Google Maps’ API provides a unique kind of prototyping environment — I think – for locative media projects.

Technorati Tags: , , ,