Videos of the replay tool of the second CatchBob! pre-experiment:

- AVI - 2.36MB
- MOV - 7.8MB

CatchBob! Visualizer is built on top of the CatchBob! Server. It visualizes real-time, recorded or simulated activities of the CatchBob! players. Its goal is to provide a base to analyze the wide load of data generated during a game.

Current features:
Real-time:
- Start/Stop a CatchBob! Server
- Store into a .log file the game events (command and refresh)
- Play with virtual players

Replay:
- Load games .log file and replay all the game events
- Forward, rewind, skip

Simulate:
- Base to simulate with agents and have “smart” virtual players

View:
- History
- Commands
- Triangle
- Time
- Logs
- Path length

Future directions could be:
- Visualize what every player experiences (view according to the player’s refreshes)
- Global visualization with the movement done outside of the refreshes (using access points sniffed every 7 seconds on the iPaq)
- Easy access to data for statistics and maps generationof the refreshes, commands, triangles, wi-fi usage, % of the campus covered, number of areas each participant searched in, number of areas all the participant searched, overlap, backtracking
- …

Previous mention to the CatchBob! Visualizer:
Real-time Visualization of a Location-Based Multi-Player Game

Funny to see the people at Placelab stumbling on the same problems as me. From their mailing-list:

Originally, our xp spotter sends the scan command to the NDIS driver, than it immediately queries the driver for the bssid list. However the scanning happens at background and the scan function returns immediately (or asychronously). As a result, the bssids returned is in fact for the second to the last scanning. EX: If we are scanning at 2 second interval, the bssids returned were 2 second old. A quick fix is to simply wait certain time after the scan command. MSDN suggest 6 seconds, but I use 300 ms based on the Linux spotter setting.

Yesterday, we did a real-world testing of CatchBob!. The application (on both clients and server) got pleasantly really stable. Positioning could still be improved. The biggest problem remaining, being the ending condition. Maybe to form a triangle is not the way to go. Nicolas as a short report on it as well.

CatchBobServer output

Our position paper Analysis of a Location-Based Multi-Player Game for the workshop Games and Social Network: analysis of multiplayer games at the British HCI conference has been accepted.

Analysis of a Location-Based Multi-Player Game by Nicolas Nova and Fabien Girardin
The growing number of location-based services fosters the creation of multiplayer games that take place in real settings and leaves open the question of how to analyze data generated along the game. We are interested in ubiquitous computing games in order to use it as a platform to study how people rely on spatial features in terms of collaborative interactions. The crux issue here is how to analyze the wide load of data generated by the game in an ubiquitous computing context. How should it be studied? What kinds of data may be captured and what sort of analysis should be conducted?

Posters for the EPFL I&C Research Day 2004 are available in the CRAFT Research Booklet. CatchBob!, BILL, and ShoutSpace are featured.

First life CatchBob! experiment was performed today. Good feeling even though the physical topology of the EPFL wireless network and the limited access to some building give me worries on wether the joint task can be fulfilled with enough interactions.

Very early version of a tool built on top of the CatchBob server that visualizes real-time activity of the players. The goal of this tool to provide a base to analyze the wide load of data generated during a game (data stored according to an XML formalism). An obvious usage would be to use it to replay a game (for players self-confrontation with their activites), a more delicate would be to visualize a game simulated by agents. Fungus eaters are back! Yes! ;).

The development of CatchBob is moving forward. As real-time data communication is not longer required (the players will pull the data), dealing with TCP got easier. No mneed to keep stateful connection in an uncertain network environment anymore. Basically, the iPAQ connects to the server socket every time the player wants to be located and wants to coordinate with the others and closes the connection at the end of the transaction. The server keeps a thread pool of sockets. Solution for real-time communication would have been to use UDP (which could have been a headaches to deal with on the EPFL campus).

Today’s improvements are:
- The access point sniffer object was moved from a Timer to a Thread.
- A drawable map replaces the semi-structured communication context menu.
- A sound notifies that a scan has been performed
- The best signal strength is displayed

(more…)

CraftStumbler2 my Pocket PC utility for 802.11b based wireless network auditing is running. It is based on CraftDeamon a C++ DLL which calls NDIS functions on the IEEE 802.11 NIC and returns the detected BSSIDs and their attributes stored in the IEEE 802.11 NIC’s database. CraftDeamon’s methods are exported to be invoked by CraftStumbler (C# client) which displays the access points’ MAC addresses and signal strength and if selected redirects the data to a remote server (Java) which logs them on a centralized database.