Current Status

    Here's the minutes from the last couple of meetings.

PRIORITY TASKS

We have eight tasks which *need* to be done. Here they are in order of
priority (not in chronological order). 

   1. Three or four days of debugging and play testing. This will
      commence on Wednesday the 27th. We will round up random people
      from the labs around noon and force them to play our game and
      tell us what they think. We will take copious notes.

      I think it'd be cute (perhaps, overly so) if we got actual
      recording of people saying things about the game and put them on
      our web-page. (The positive ones of course.)


   1½ All the models must be scaled down so that one Direct X unit is
      equal to one meter. This is mostly happening anyway since all
      the new models that are being created are at the correct
      proportions. 


   2. Animation and Models need to be created in Alias|Wavefront and
      imported in to the game. See below for a discussion of how the
      animation will be incorporated in to our Server-Client model.


   3. Game rules tweaked and coherent. At our Sunday meeting we hashed
      out a complete (if not polished) set of rules for the game which
      will be honed through the trials mentioned in above (1).

      Here is a list of new game rules:

	   o Getting the ball to the other side earns a team 100
	     points. 

	   o Falling off the edge of the world (difficult to do!)
	     loses that player's team 50 points.

	   o Team scores are never negative.	     

	   o Using the "suicide" key to respawn subtracts five points
	     from that player's team score. 

	   o The first team to reach 300 points wins.

	   o The goals will now be delimited by rings rather than just
	     colored lights. Kicking the ball in to the ring allows
	     the player to score.

	     [By the way, I suggest that we shrink the goals to be
	     somewhat difficult to kick the ball in to. We'll only
	     count it as a goal if the balls velocity goes to zero
	     while in the ring.]

	   o If the ball is jumped on (whether in a pit or not) it
	     will randomly respawn to *any* point in the world. [Well,
	     perhaps we should limit it so that it doesn't respawn in
	     to the players goal.]

	   o If the ball is kicked off the edge of the world, it will
	     respawn at its homebase.

	   o There shall be a key to get up which the player must hit
	     some number of times in short succession in order to
	     right her Luxo after she is knocked over. (Else, the
	     player may suicide to restart at the base).

	   o Mass shall be inverseley proportional to distance from
	     the base. The winner in a collision between to Oxuls will
	     be decided based upon mass, velocity, and leverage.


   3½ Sounds are integral to the impact of our game. We must set aside
      time to search for and create new sounds. I'll bring the mic
      once we set up a date. Can someone tell me if the client side
      ignores sound messages that it doesn't understand? I think we
      should be tossing in "play sound" messages all over the place in
      the server. (If later on it turns out that it slows down the
      render rate we can turn them off).


   4. We need a status bar to display the scores, a simple compass,
      and a little bar graph showing the amount of "jumping power"
      they've accumulated by holding down the jump key. 


   5. Trampolines should be added to the game. Ryan has already
      removed the "Jet Pack" feature.


   6. Mouse-look & User Defined Control Keys.


   7. Collision detection must handle collisions between antagonistic
      Luxos properly and choose which (if any) Luxos should fall down.


   8. Collision detection should be modified to take in to account
      angular velocity before stretching the bounding boxes. This will
      prevent the bug where Luxos get locked together.




WISH LIST

There are a few things which are desired for the game but aren't
completely necessary. Here is a list in no particular order.


   1. The DUDE should run around randomly in the game, hiding behind
      trees, chasing players, and just generally bashing in to stuff.
      It'd be nice if he glowed somewhat and occasionally mumbled
      inanities. (Also, if we make his mass high enough that he can
      push around the luxos, he could become a serious factor in the
      game).

   2. When a new player joins a sound should be played for all the
      other clients to hear so they know why their machine has
      suddenly frozen. Also, it'd be nice if there was a little flash
      of light where the player warps in, but it's unnecessary.

   3. Have we got those timeouts implemented in the Client Receive
      thread yet? 

   4. It'd be nice to have a key that turns on the lamp only while its
      pressed down. That way we could actually transmit morsecode as
      in our project spec.

   5. Speaking of the project spec, if another luxo is moving within
      hearing distance, a sound should be made. Perhaps, a creaking as
      in the original Luxo, Jr. The current jump noise is fine for the
      occasional big jump but we wouldn't want to play it continuously
      when a luxo is simply hopping forward.

   6. It'd be good to have some sort of a UI set up so that players
      can see who's playing and choose which team they're on. 

   7. When a player exits the game, their carcass should be cleaned up
      and the memory freed. Ideally, we'll also free the ObjectNums of
      the player so that they can be reused, but this is unnecessary.

   8. It'd be nice to package up our game with a short "manual" on how
      to play and stick it on the web page.




TIMELINE

Here is the current timeline for our project.

     Games rules implemented	    BEFORE May 27

     Play testing starts	    May 27, Wednesday 
				   
     Spec Freeze--debug only	    May 30, Saturday

     D-Day (Demo Day)		    June 3, Wednesday


ANIMATION

Animation of the models should add a lot to our game. After a meeting
that took way too long, we decided on the following things:

     1. A "jump" is when the user hits the jump key to leap high. 

     2. A "hop" is when the user's luxo automatically makes a small
	jump as an artifact of moving forward.

     3. A hop animation could be a canned movie of a small jump which
        isn't actually happening in "reality" on the server. (There
        was much debate about this).

     4. Because the jump animation must be tied in with actual events
        happening on the server, it cannot be a canned movie on the
        client.

     5. However, the server should not micro-manage the animation of
        the client either. If it has to tell it when to play each
        frame, it'll chew up the network.

     6. As a compromise, the server will send messages to the client
        telling it when to play a certain fragment of the jump
        animation. There are currently only two fragments:

	a. Jump up. The luxo transitions from its normal, ready to
	   leap, squashed state to stretching up and finally to a
	   squashed state representing the luxo at the apex of the
	   jump. 

	b. Anticipating landing. The luxo changes from the final
	   squashed state in a. to a stretched out state getting ready
	   to hit the ground.


	Fragment a. is played when the player releases the jump key.
	Fragment b. is played when the luxo's y velocity becomes
	negative (and if it's not playing already). This way b. would
	get played if the luxo were to fall in to a pit as well. 

	When the player lands on the ground, the regular "staying in
	place" animation is played which shows a somewhat jiggly luxo
	in squashed-position and ready to go in to action.

     7. The protocol which the server will send to control the client
        will be something like this:

		SET OBJECT _#_ ANIMATION _STAYPUT_
		SET OBJECT _#_ ANIMATION _HOPFORWARD_
		SET OBJECT _#_ ANIMATION _JUMPUP_
		SET OBJECT _#_ ANIMATION _ANTICIPATION_
		SET OBJECT _#_ ANIMATION _STRAFELEFT_
		SET OBJECT _#_ ANIMATION _STRAFERIGHT_

	Note that when the animation is set for an object, it
	immediately starts playing without waiting for any previous
	animation to finish. This will be somewhat jerky, but will
	give the players maximum control. Hopefully our animations
	will be short enough that this will not be much of a problem.