y by:
Tian Li
Nate Hansen

---

[Home]

[Group]

[Proposal]

[Update 1]

[Update 2]

[Presentation Slide 1]

[Presentation Slide 2]

[Report]

[Status]

Below is a basic outline for this first update. Remember to keep your status and abstracts (as well as the rest of your project web) as up to date as you can).

• Parts
  Have you obtained all the components (hardware and software) you'll need? If not, why not and when do you expect to receive them? What will be the total cost of the project?
  Approximately .5 pages.
  

So far we have obtained most of the necessary hardware we will need. This includes an iPaq and a computer to compile on. We are waiting for a second iPaq so we could test bluetooth to bluetooth communication. The reason we do not have the second iPaq is because we are not entitled to one from the TA managing the resource right now. But hopefully he will allocate one to us.


As for software, we have obtained Java API which we could implement the networking part of our application with. We have also downloaded the PlaceLab package for Windows CE.
The total cost of the project is approximately equal to the cost of two iPaq's price, as we are not using any other resources which cost money.


• Experimentation
  What experiments are you running to make sure your implementation ideas will work (e.g., what smaller pieces can you build first to give you confidence with the parts you are least sure about)? List all of your unknowns, that is, what you don't currently know how to do. For each unknown describe the approach you will take to resolving the issue, e.g., experimentation, searches, readings. What is your backup plan if you are not able to resolve an unknown.
  Approximately 2 pages.

In the beginning, we spend time testing out running our game with the personal server, which will alert the user through another device, such as a cell-phone.
Unknowns includes how to transfer data from personal servers to other devices in a nice way, and what type of alert would work(sound, flashing light, etc...)
In the end, we realized that there are many technical issues with this solution, and that switching to the iPaq which has a screen and input buttons is a better solution.


As described in the project proposal section, we have divided this project into components. We are currently in the process of writing software that will run the game logic, and the quest builder. Our skeleton code so far runs the game with a character with a single state: int Hp
it has a single event handler that will detect another user.
for this part, the biggest unknown is to get bluetooth detection successfully working. That is, we need to have the two iPaq's detect eachother.
The two main reason why this is not implemented right now is that we do not have a second iPaq, and that we are not very familiar with how bluetooth works.

We have just begun experimenting with the PlaceLab package, therefore this is somewhat of an unknown at the time.
Hopefully in a few days, we can have this part working correctly.


• Construction and Debugging Plan
  How do you plan to construct your project? How will you test it as it comes together? Have you thought about a debugging strategy? Are you starting with smaller pieces you can test more easily? Be as specific as possible. Describe, using a timeline, when each piece will be done, which pieces will be worked on in parallel, what are the major milestones.
  Approximately 1.5 pages.
• Appendices
  
  
  Initial design diagrams/schematics
  -Simple hardware framework: get bluetooth working
  -get placelab working
  -in parallel:
  -get the game working(for the time being just sub in the real hardware messages with simulated software messages
  
  

  the beauty of our project is that we can start with an amazingly simple software core and add arbitrary pieces to it. For example, our initial game can have functions that represents events, but just prints a message "you met another character".
  what happens in such an event does not have to be implemented. Later if we have time we'll just inherit from the parent class and overwrite the features. So we are basically using Object Oriented design to our advantage to build this thing using a divide and conquer approach.

  • Division of labor among group members
    
    • Hardware:
    • Nate: figure out how bluetooth works
    • Tian: figure out how placelab works
    • Software:
    • Tian: core game code
    • Nate: quest maker interface