Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team 13 Members & Overview
- Billy Hoffman
- Allison Jensen
- Scott Kilpatrick
- Seth Levy
We range from 2nd year to 5th year CS majors, and have worked together
Project Summary: The class project was to develop a location based service in
squeak. This service required the ability to leave messages at various
locations (air-graffiti), and the final segment of the project involved custom
extensions, for which we developed a capture-the-flag type game. Users are able
to specify their location, view, and leave messages at their location. The
client application was required to run on both desktop and Pocket PC PDA
platforms. The server was designed specifically to run on the desktop.
Issues Implementing the Project:
Language Difficulty:Several of our team members possessed extensive experience
programming in other object oriented environments. We found it difficult
adjusting to Squeak's syntax and unconventional combined interpreter/IDE . We
quickly realized that extreme programming was helpful in compensating.
Specifically, we had two people working on one computer at all times. This
allowed us to more easily identify and avoid problems common to Squeak novices.
This also enabled the two programmers to jointly find ways to implement
functionality in the easiest and most straightforward manner possible, despite
a relatively low competence level in Squeak.
Integration: We found the available CVS tools for Squeak to be in a
disorganized and undocumented state. After trying several, we were unable to
install a solution that would let the four group members concurrently edit the
project. We're unsure as to what degree this can be attributed to Squeak
itself, versus the authors of these systems. Regardless, this seriously harmed
productivity compared to the level team members expected based on past
collaborative development projects. Integration was eased somewhat due to the
adoption of extreme programming, as we were continually merging two code paths
instead of four. To further assist, we abstracted code as much as possible to
enable unit testing before integrating with the other team. This minimized the
number of issues resulting from the two-path code integration.
Networking: Our initial intention was to implement a traditional client/server
architecture to support the location based service. Each client would log-on to
the server with basic personal identification information and starting
location, and the server would subsequently push updated maps to all connected
clients. We encountered a lot of problems while trying to implement the server.
Specifically, we could not get the server to handle multiple client connections
due to the way Squeak handles threads. Our eventual understanding was that the
only way to do this was through creating morphic objects that ticked with a
stepper. However, since we became concerned after the second milestone that we
did not have a working network, we abandoned this approach. Due to the nature
of this application, we determined that the client could be fully responsible
for keeping track of state. Therefore, we implemented a stateless server, which
simply echoes the universe back to clients when they change any information.
Clients also poll for updates, however, for efficiency reasons, every copy of
the universe has a time stamp such that redundant universes are not downloaded.
A secondary benefit of this stateless approach was that we utilized Squeak's
built-in HTTP based webserver, which we believe to be more scalable than a
custom multi-threaded server. This webserver easily transports any MIME data,
and we chose to use SIXX to encode and decode XML representations of native
squeak objects. We also eventually used squeak's built-in capability to fetch
images via HTTP directly. Converting images to XML objects using SIXX creates
massive strings, taking a cost prohibitive amount of time to send.
Division of Labor: One of the pitfalls of our extreme programming strategy (and
the nature of our project) led to a strict division of labor in terms of a
front-end interface team and back-end network application logic team. Both
teams had a comparable challenge in terms of development difficult, however the
teams probably did not go far enough in understanding the nature of the other
team's work. This became significant at integration time when all four team
members were working on the final deliverable at one workstation; for any given
problem only one of the teams had adequate knowledge to solve it, leaving two
Milestone 6: Treasure Hunt
Design: For M6, we were required to develop our own location-based service. For ease of deployment and development, we decided to implement our service using the note posting and receiving infrastructure developed for M5. We wanted our M6 to use our Notes object, or some container that inherits from the Notes object.
Ultimately we created a Treasure Hunt game. Specific clues would be left at a location pointing to the clue's location. A typical clue would be something like “Go to the building which just had a chemical spill.” Since Squeak isn't a typed language, our Message member of out Notes object could hold text clues, pictures, audio, or even video! These clues form a chain that leads to a treasure. Once a user gets the treasure, they receive a win message, and all other players in the game receive a lose message. The server will clean up all the old game, and restart a new one. Their can only be one game on the system, and as soon as someone wins the game is restarted. Players can join or leave the game at any time. The game in only over when the treasure is found.
We created a ClueNote class that extended our Notes object. The MServer handles creating new games, and handling games that win. To create a new game, the Server randomly selects a location for the Treasure, and places a ClueNote there with a Victory message. MServer assembles a chain of clues to the treasure by backtracking 1 location at a time, for some Random number of location, selecting clues that point to the next location. All the ClueNotes in the chain are then added to the appropriate locations as if they were regular Notes. When MServer populates the world with this ClueNotes our timestamp for the LocationWorld object increments, so that every MClient will pull a copy of the new world on their next refresh request.
Since Treasure Hunt had to run concurrently with our M5 Notes service, we needed to add some filtering code to LocationViewer so that only people playing the game will see the ClueNotes. We also added a way to join the game. Our LocationWorld object has a gameID unique for each game. When a user joins the game, LocationViewer stores this ID locally.
Users follow the clues until they reach the treasure. The treasure is denoted by a special string in the Message variable of a ClueNote. MClient displays a victory message to the user and sends a special message to MServer, telling it the game has been won. MServer then removes all the old ClueNotes, and starts a new game with a new gameID. Our network design doesn't allow MServer to pro-actively contact all the users.
When a user who was playing the game does a refresh, they will receive a new LocationWorld object, because the timestamp is different. They will see that the gameID in the world is different than the gameID they were playing in, and understand they lost the game. The client will display a notice to the player that they lost the game.
All of this is completely unobserved by all of users of the system that are not playing the game!
Conclusions: Treasure Hunt was very easy to implement. Key was finding a way for Treasure Hunt and M5 to coexist on the server. By designing our M6 service around using our M5 infrastructure, only minimal changes to the client and server were needed.
Here are our .st files for our M6 project:
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu