CSC 400 Team Project: Kleptomania

The game works as follows: (preliminary description). Each team (3 at the moment, red, green, blue...) has a physical territory (currently a cubical) containing separated resource and collection areas (currently tables on opposite sides of the room). At the start of the game, each resource area contains some number of "treasure" objects, not necessarily all the same. The goal of the game is for a team to accumulate as many objects as possible in their collection area, either by moving them from their own resource area, or stealing them from other teams' resource or collection areas.

The machine system has both surveillance and strategy roles. The surveillance role is to monitor its team's territory using cameras, (and possibly microphones) and sound an alarm in the case of attempted theft, while allowing its own team to move objects as needed. A team member who triggers an alarm, either by his own, or an opponent's machine, is penalized by being unable to play for the next 2 or more turns (in jail) , with an additional 3-strikes and you're out condition (in hell).

The second machine role is to control the strategy of the game by instructing its own team members on what to do (e.g. "Jon should try to steal an apple from the green team's collection area") Team members may take only actions dictated by the machine. An important issue is defining a reasonable information-collecting strategy that will support this. You need some information about what might be stealable and from who, and what succeeds or fails, and if there are queues for various territories. Trying to obtain this information from observation in addition to detecting intrusion seems too messy (too many cameras looking at too many things). Instead, we have the information entered by human "spies". The difficulty here is defining a reasonable set of rules for information entry/gathering that prevent "coding" strategies that essentially allow the players to direct the action at a fine-grained level. To address this we will define a common language that the players can use for communication back and forth with the machine.

Here's an outline of how this works. Information is supplied to the machine by the players; but it must be in the form of true, simple factual statements such as "the green team has 3 oranges in their collection area". We prohibit deliberate coding schemes (e.g. making the same statement about the green team's clocks 3 times means that Jon should try to take a clock from from the green team. The idea is that the users do not need to know anything other than the surface meaning of a statment in order to interact succesfully with the machine. Following this up, we should imagine that the source of information be a naive participant responding to initiatives by the machine. And questions of the sort "Is the next person coming into my territory an opponent?" (so the machine can ring an alarm) need to be disallowed in the language. Let's assume the queues are hidden, You know if there are other people lurking about the entrance to a territory, but you don't know who they are. Or just no communication from the executive agent to the surveillance/alarm system.

One approach to handling the communication that seems to work relatively well is for one member of each team to be the "dungeon master" who calls out to the team members what the machine has instructed them to do and enters the information requested by the machine. Of course, if anyone wants to do a distributed system with PDAs, that would be cool... All dialogue should be posted to the public display during a game.

The game continues until either all members are permanently out, or a specified time (20 turns) has passed. The winner is the team that has the most objects in its collection area when the game ends.

To make the game work, some rules similar to the following seem needed. There might be others as well.

• To avoid physical conflict, blocking, etc., only one person is allowed in a territory at a given time. A person can spend no more than set time (e.g. 15 seconds) in a territory, and on exiting, must wait in a holding area for a specified short interval (e.g. 15 seconds). This is to allow the monitoring machine a short time for "thinking" about whether to sound an alarm or not. Access to the territories is controlled by a queue. A player is free to leave any position in a queue at any time, and join the end of another. It seems easiest to implement this by using synchronized "play periods" each consisting of an intial registration "blue period" (perhaps 15 seconds) where the next person who wants to enter the room registers with the system. This is is followed by a "green period" (say 15 seconds) during which access to the room is allowed, followed by "yellow period" which is the holding time mentioned above. Finally, there is a pause "red period" that can be extended indefinitely by any team if some corrections to the setup (stuff knocked over, stolen objects replaced etc.) can be made. With this sort of scheme, the registration and keeping track of who is in the pnealty box or out can be carried out by a little infrastructure programming.
  
  
• Players can carry at most one object during a given acess to a territory. If a player is "caught" by the machine monitor in an opponent's territory, any object in his possesion is replaced in its original area, and the opponent team is allowed to send a "reset" signal to their machine monitor if desired during the next pause (red period). The player gets a "strike" penalty. Additionally, if an apprehended opponent has "accidently" moved more than one object (perhaps with the idea of confusing the monitoring system) they can be replaced in their original areas. We might just avoid this issue by saying that a player is allowed to move at most one object in the room, just so that the red period does not need to be annoyingly long. If a player is mistakenly caught by his own machine monitor, any object placed in the collection area or in the player's possession is removed from the game, and the player is penalized the same as an enemy agent. To avoid oddball strategies of having a single "depositor" on the team, We should might require that the person who (successfully) steals an object must be the one to place it in their own territory (i.e. they can't give it to another member outside of the room).
  
  
• The idea of the monitors is to allow "keyless" access to a work area, so the use of physical artifacts as access keys to one's own territory is disallowed. Specifically, "one time key" strategies, where a different secret is required each time. are not allowed. Straight identification of team members through face or full-body recognition is allowed. However, teams are allowed to take photographs of all players on the day of the contest, and no deliberate change in clothing or appearance can be made thereafter.
  
  
• The objects of desire will not be known prior to the day of the game. On the day of the game, the objects will be available for photographing, along with all players, and the teams will then have a prep period (e.g. 1-2 hours) to configure their systems for the game (make spoofing pictures etc.).
  
  

Teams

• Red Team:
  
  
• Green Team:
  
  
• Blue Team:

Preliminary Territory Design

Team territory is an 8x8 foot region containing two tables. The back boundary is a wall. The sides may be walls or dividers extending out at least 6 feet. There are two Cannon pan-tilt-zoom ceiling cams mounted approximately as shown. These are connected to a dual-processor computational sensor, whose terminal is adjacent to, but outside of the territory.

Getting started

Reference Material

• Matthew Turk and Alexander Pentland, "Eigenfaces for Recognition", Journal of Neuroscience, 1991, volume 3, number 1, pages 71-86.
  The famous eigenface paper. Check out sequelae (later papers that reference it) as well. You can find these through CiteSeer, or the Science Citation Index.
  
  
• Michael J. Swain and Dana H. Ballard, "Color Indexing", ijcv, 1991, volume = 7, number 1, pages 11--32.
  Color histograming, a simple method of recognition. Invented here at Rochester. Also check out sequelae to this.
  
  
• Chris Stauffer and W.E.L Grimson, "Adaptive background mixture models for real-time tracking" CVPR 1999, pages 246-252.
  Describes using mixture models for change detection in video. A variation of this is implemented in the discover_objects program.
  
  
• The July/August 2003 issue of CVIU (Computer Graphics and Image Understanding) is a special issue on face recognition, if you want to see what the state-of-the-art looks like.
  
  
• The September 2003 issue of CVIU has a paper by A.Z. Kouzani "Locating Human Faces within Images".
  Also, the October 2003 issue of PAMI (IEEE Transactions on Pattern Analysis and Machine Intelligence) has a paper by R.C. Verma, C. Schmid, and K. Mikolajczyk, "Face Detection and Tracking in a Video by Propagating Detection Probabilities" I haven't read either, but they might give some idea of the state of the art in the face detection (as opposed to recognition) area.
  
  

Infrastructure Assignments

• Communication Language Design: Blue Team
  As described above, the strategy systems need a common language to request information about the world, and to direct the players. For transparencey, this should be a (very restricted) subset of English. A formal grammar may not be required, and a handful of slotted statements may suffice. The overall goal is to ensure that all teams are working with the same set of available information and the same play instructions so that success does not hinge on a "clever" interpretation of the rules.
  
  Previous language specifications and teams:
  • No 2003 language specifications available.
    2003 Blue Team: Yu Zhao, Fabrizio Morbini, Carlos Gomez, Christopher Stewart, Ashwin Lall.
    
  • 2004 language specifications.
    2004 Blue Team: Anustup Choudhury, Pin Lu, Tanushree Mittal, Lior Privman, Benjamin VanDurme.
  
  
  
• Display System: Red Team
  In order for the audience to follow the progress of the game, we want to project an activity and status display. This display should include the information requested and received, and the commands issued by each system (i.e. all dialogue between the system and the players. It should also display the turn clock, period, and the status of each player (in penalty for next n turns, permanently out etc.) The challenge is to design a display that makes all this information easy to access and understand. It will need to have hooks so that the various systems can send the English text representing commands and information requests to the display system, and also receive information about player status from the access control systems. The communication interfaces could be implemented using sockets or any other inter-machine communication mechanism. Since it is relatively low-bandwidth, the communication mechanism probably does not matter. There is an issue about whether player status should be in a single, mutually accessible database, or if the access system should just pass messages, and the display system keep it's own (hopefully consistent) database. Discuss relative merits with green team.
  
  Current and previous display specifications and teams:
  • 2003 display specifications.
    2003 Red Team: Madhur Ambastha, Jonathan Shor, Wei Jiang, Viendra Maratha.
  • 2004 display specifications.
    2004 Red Team: Shivashankar Balu, Ding Liu, Ross Messing, Matthew Post, Arrvindh Shriraman.
  
  
  
• Access Control and Alarm System: Green team
  Each domain needs to have an access control program running. These display synchronized turn clocks, register the next player to enter the room during the "blue period" (including checking eligibility), recieve and sound any alarm sent by the monitoring process, and assign penalties to any player in the room when the alarm sounds. It also needs to maintain an common database of player status. As mentioned above, There is a question about whether this database should be in some common area, where it can be accessed by the display system, or whether the access systems should just send messages to the display system about who is caught, and let it maintain its own parallel data structure. The former is more elegant, and does not have an inconsistency problem, but is trickier to implement. Green team should discuss this with Red team.
  
  Current and previous control specifications and teams:
  • 2003 control specifications.
    2003 Green Team: Manu Chhabra, Hao Zhang, Kirk Kelsey, Abhinov Jalan.
    
  • 2004 control specifications.
    2004 Green Team: Jacob Balazar, Piotr Faliszewski, Michael Spear, Wenzhao Tan.
  
  
  

Back to CSC 400 main page