9/13/04 - Met in Poppa. Followed up on Sunday's updating of sample POP game. Game files created for Velma's Revenge using the Pop Framework handout steps. Decided character should move in which ever direction the keys are pressed as opposed to having a direction the character is facing. Weapons will not be directional but rather a radius around the player. Completed most of the desired functionality for prototype.

Decided that the following items need to be updated to complete our prototype:

• Add clock for level length
• Add party at bottom of screen where enemies and friends disappear
• Attract friends to party
• Delay when friends talk to you.

Additions for final:

• Implement "proximity weapon" kills.
  • Proximity weapon in cCritterVelmaPlayer::shoot() -- implement cCritterArmedPlayer::proximity()
• Camp Sec calls -- using pbiota()->purgeNonPlayerNonWallCritters();
• Score updated by killing enemies
• Enemies repell each other?

9/15/04 - To Do:

• enemies come one at a time
• graphics
  • background - multiple bitmaps allowing multiple party map layouts
  • entities
  • intro screen
  • level info - health, clock, score?
• clean up memory leaks caused by creation of new cPerformanceTimer
• add sounds
• change release dates and numbers

9/19/04 - Ran CVS update on my (Ryan's) turing account but didn't get latest code. Tim had problems compiling because of an inability to link a lib file. Started updating code to differentiate enemies from friends. took randomSprite() code from cGame class. Made makeEnemySprite() and makeFriendSprite() functions in cGameVelma class. Couldn't use them, however, because pgame() returns a pointer to a cGame not a cGameVelma. Thus, after we figure out the CVS and compilation problems: To Do:

• Differentiating enemies and friends
  • take code uploaded to Updates topic and add it to files indicated
  • add lines to cGameVelma constructor to set the _enemyspritetype and _friendspritetype where _spritetype is set right now
  • add a pgame() function to the velma critter classes that overrides the cCritter class method. Have it return a pointer to a cGameVelma instead of a cGame. This will allow us to use the makeFriendSprite() and makeEnemySprite() functions to differentiate friends from enemies.
• proximity weapon
• camp sec calls
• Graphics
  • change makeFriendSprite() and makeEnemySprite() functions to use the bitmap images of characters
  • change cCritterVelmaPlayer constructor to have a setSprite function.
  • have separate bitmap images for each level
  • intro screen
  • health, score, clock?????

9/27/04 - Met at CMC to finish the documentation, final report, and wiki page.

-- Posted By RyanAusankaCrues

10/3/04 - Met in AC to begin work on Project 2.

• James began work on the Triangle, Point, and Room classes.
• Ryan began work on the CollisionHandler class.
• Tim began work on the Ball class.

10/6/04 - Met at AC to continue work on Project2. Ryan worked on the display code to correct some problems. James and Tim went to LAC while Ryan was at another meeting. Mix up caused James and Tim to work together for a few hours without Ryan. Ryan came back from meeting and worked on display code while James and Tim worked on collision code. Ryan later met them in LAC.

-- Posted By RyanAusankaCrues

10/11/04 - Met in AC again following cs105 lab. Fixed up bounce function in ball class. James worked on cleaning up the CollisionHandler class so that it can be extended for the current prototype. James and Tim worked on implementing standardization of triangle and ball classes. Problem was discovered for edge and vertex collisions not returning the proper normal vectors. Ryan created Gantt chart and UML Class and Sequence diagrams for the classes currently implemented. To do:

• Edge and vertex collisions do not return proper normal of surface
  • problem with numerical inaccuracies causes ball to get stuck.
• Triangle standardization
• Generalized edge and face collisions
• Test with multiple triangles
• Test with triangles not in SO
• Flickering - Fixed today by Ryan
• Ball doesn’t bounce on vertex collisions

• Problem with ball bouncing off of only one triangle...the right triangle on the bottom of the cube.
• Ball also eventually falls through the bottom triangle if it is allowed to bounce for awhile
• If the ball bounces get to be a certain size due to gravity, the bounces won't get smaller.
• Problems with rotate code causes some triangles to be improperly transformed into standard orientation
• Problems with degrees vs. radians