Thanks everyone who participated in the game jam, and thanks Chaim for suggesting it.
I wanted to get down some thoughts while the event is still fresh in our minds.
Games
Ten games were built and presented:
spaceship and asteroids game (above library bookshelf) — Glen, Nagle
connect the dots (on library whiteboard) — Matthias
stand off (on whiteboard near Chaim) — Chaim
laser socks (on ground near entrance) — Glen
tomagatchi island (on wall near kitchen) — Emily and Paula
laser trains (on ground near island) — Nagle
pong (all over) — Andrea
mole tank (all over) — Paula
we'll get through this together (flower game, all over) — Bret
joust clone (anywhere) — Glen
Social
In stark contrast to a normal screen-based game jam, every game here was multiplayer. Every single one! Even games that could ostensibly be played alone, such as the island or the trains, were inherently social simply by virtue of being out in the world, where anybody could walk by and join in. And games intended for two players, such as connect the dots and laser socks, somehow found themselves with four or six players at once.
And unlike typical "social games" which consist of sitting and poking at your phone, seven (!) of the ten games were about body movement and physically interacting with other players in the same space.
Distributed
A few of the games were designed around interacting with many objects distributed around the room. The way the players were expected to interact was different in each case:
pong — stand at a good vantage point and laser across the room
mole tank — run around the room
flower game — distribute a group of people around the room and work together
I think that all three of these interaction modes will have their place when doing "serious" work in a spatial workspace.
Non-virtual
A few of the games used a whiteboard or wall as a big screen, and virtually generated the nouns that players interacted with. (e.g. stand off, connect the dots.)
In other games, the nouns that players interacted with were physical objects in the world. (e.g. laser socks, laser trains, flower game.) In the flower game, the computer provided "adjectives", by projecting a decoration onto the physical nouns that indicated their state. In the train game, the computer's role was to "notice" what was being done with the physical objects.
Laser socks had elements of both. It was perhaps the purest example of what I had in mind with "Hypercard in the World". The nouns in the game -- the player zones, the score bars, the start button / countdown timer -- were physically-existent things-in-the-world which were individually blessed and illuminated. People interacted with the objects, and the objects communicated with each other. "Gently magicalized reality".
I like the phrase "the world draws itself", and laser socks is a good example of that. The computer is mostly just coloring objects in, not generating illusory objects from pixels. (It's similar to the research gallery, etc.)
Not only does the world draw itself, it also simulates itself, and laser trains made excellent use of that. (Compare to the experience of programming a similar train game inside a screen.)
---------------------------------------------------------------
Equipment
8 projectors, 8 cameras
a dozen or so laser pointers (gradually disappearing)
laptops
1 toy train set
3 additional projectors+cameras were installed during the game jam
1 additional Mac Mini was installed
The research gallery was taken down and replaced with a whiteboard. A whiteboard was moved in front of the library bookshelf. The serengeti diorama was taken down and replaced with an island.
System
64 new objects were blessed
48 new processes (illuminations or daemons) were created
I upped the max lasers per camera to 5, to accommodate the stand off game. For the spaceship game and especially connect the dots, when many people were lasering continuously for an extended period of time, the system would bog down and lag.
At one point, I turned off "illuminate collections", because the big board was getting overloaded with stuff and lagging.
At one point, the computer illuminating big board spontaneously restarted. A few times, a web browser had to be restarted because someone had written code that went into an infinite loop. A couple times, I had to do a bit of surgery on the database because someone had accidentally put something weird in there. (Changing the type of an attachment, or "db.set"ing an array.)
But the system proper (seatbelt + daemons) never crashed or locked up. And it generally didn't seem to lag very much unless many people were lasering at once.
I had changed the inspector so people could inspect objects without interfering with each other, so the remaining source of interference was when blessing objects. (This is a problem with the inspector, and was a minor annoyance but not too obtrusive.) The system itself gracefully handled many people doing many things in parallel, even installing new machines, projectors, and cameras, without interference. This was maybe an order of magnitude more simultaneous activity than the system had ever experienced.
Programming
It seemed like the "sample code" objects ("play a sound", "animate a picture", etc) were useful. Most of the projects I saw had obviously expanded out from the sample code.
I handed out cheat sheets at the beginning for canvas, db, and the inspector. I don't know whether those were useful or not.
I was pretty impressed that people were able to build things and complete all their projects, despite the ugliness (variables, blessing and locations) or unfamiliarity (attachments, responders) of some of the programming constructs. The game jam was helpful for me in thinking about what a good language might look like.
Some time ago, I brought a few of the VPRI people (Yoshiki, Alex, Dan A) up here for a few days to talk about designing a programming language for the system. Most of the time was spent trying to get their heads around what the system is for and how it works, and I'm not sure they ever really got it. I'm realizing now that if we had just spent the three days doing a game jam or similar, the meeting might have been a lot more successful, as far as planting seeds for future collaboration. Live and learn.
Distributed Programming
In all three of the distributed games -- pong, mole tank, flower game -- a pattern emerged of creating a "controller" object which would orchestrate the behavior of the distributed objects. Because the controller object took up physical space and was illuminated, it was natural for it to display diagnostic information. (e.g. pong's controller indicated which board the ball was on.)
Near the last minute of working on the flower game, I decided I wanted to have the system play the music. I couldn't put audio playing into my controller object because I wanted to use the big speakers near the theater. So I simply blessed a new object near the theater, and had it play the audio. I didn't need to change any of the other objects, because all the information I needed for knowing when to play the sounds was already "exposed" through variables on the controller object. The music player object could just listen in.
There's nothing new about object systems or distributed objects, of course. But there is something possibly new and definitely interesting about spatially-located communicating objects, where you can point to the controller object "here", and the music player "there", and flowers "there there and there", and they all have a patch of reality to display their state.