Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Absolut Squeak Cases Page
Absolut Squeak is composed of:
Throughout this semester, we had to build an adventure game driver along with a storyline to follow. The project was divided into 7 milestones, each about 2 weeks apart. In the end, we had to have Characters, Objects, a Player, Daemons, a Command Parser, and a World that would bring everything together. The characters had to be able to interact with or without the player. The objects could fall into many categories. They could be takeable or non-takeable, surfaces or non-surfaces, and containers or non-containers. The player was the user moving around and gathering objects as well as information about the puzzle he is trying to solve. Daemons were able to do pretty much anything they wanted. They could move a player, character or object, “say” something to the player, or even kill a player, character or object. Upon the start of this assignment, we thought it was going to be fun and somewhat easy. Well, it was fun, but definitely not easy. We ran into many brick walls not only with coding, but also with group members working together in a civil manner. We feel that this page can describe the problems and tell how we remedied them so that future groups can avoid what we did not.
Overall, this project taught us more about teamwork than it did about Squeak. We had troubles in the very beginning when developing our group before M2. Lack of communication led to 5 people thinking they were in a group. This was a huge problem since groups could only be, at most, 4 people. One of our “group” members, unfortunately, had to bite the bullet and look for another group on a very short notice. Hopefully, everything turned out well for him. Our advice is to talk constantly with teammates. Meetings should be held at least twice a week for status updates and so changes can be made to the design if needed.
The other big problem that kept showing us its ugly face was time. We never seemed to have enough of it. We did not split the work up properly, and each person was not able to complete and test his portion in time without another member’s code. Since we were unable to complete our individual portions on time, we were unable to meet our internal deadlines. This led to many all nighters and even more late nights. Our advice is to think about the requirements and split it up into portions that are as independent as possible. This way, the code can be completed and tested before integration. If each individual portion has been thoroughly tested, integration should not be too big of a problem and everything will be completed with plenty of time for sleep.
In the following, we will describe some of the problems that arose when writing the milestones.
M3 Case Study
M6 Case Study
Virtual Machines (Essay)
Moose Crossing (Essay)
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu