TWiki > Team6 > IndividualLogs > RyansLog	TWiki webs: Main | TWiki
	Team6 . { Changes | Index | Search | Go }

• Worked on use case realization study with PaulScott
• Wrote first half of Power Point presentation for Project 1, including the use cases and their realizations, and stubs for other sections.

05 Feb 2004

• Investigated timers in POP and creation/use of other critter classes.

06 Feb 2004

• Further researched timers in POP and worked on implementing graphical meters.
• Added varying enemy types and a graphical health meter to my Space Invaders game, in order to indicate completion of my assigned task.

15 Feb 2004

• Reserached critter movement and forces.

16 Feb 2004

• Excerpt from email:
  • I've fixed up everything that probably should have been finished before the code got to me. There are numerous tweaks here and there to simplify code, and the wrench indicator now works. Also, (this is for you Paul), note the slightly modified method I use for level generation. You can make adjustments to my style as you see fit, but I think you'll like the utter lack of references to arrays, etc.
• Excerpt from another email:
  • Ok, I got enemies implemented, but I'm not sure how they'll behave if there are obstacles such as tables. There are the three fundamental types that we discussed earlier: printer-seeking, printer-breaking, and bouncing. If the player touches a printer-breaking student, the student downgrades to simply printer-seeking. After a printer-seeking/breaking student reaches his target printer, he will turn on his heals and head for the "door" (currently, the supply cabinet), and upon reaching that, will die (i.e., leave the room). Bouncing enemies will knock the wrench out of your hands if you touch them (it was the easiest penalty for me to code), and also die if they hit the door. Enemies do not currently spawn during play, as was intended, but that feature can easily be added in the future.
  • I made a few more small changes to things, the largest of which involves graphics. The meter graphic modifications are now all done in the update functions, meaning we don't have to explicitly tell their graphics to change (update will take care of it for you). To keep the framework from rapidly resetting the same graphics all the time, I added a small amount of wrapper to the graphics code in the update functions.