I want to rehaul the animation system, I feel right now that while our current system is working, it does not have enough flexibility or accuracy to be polished.

The current method forces a huge amount of conditionals throughout the code in random locations, which overcomplicates problem solving and can often leave selection of the current sprite up to down to unknown factors. As complexicity increases its only going to get more and more difficult to work with.

The following is a psuedo code write up of how the new system should work:

CHOOSING THE CORRECT SPRITE
In order to polish and more accurately select the right sprite for any given time, I propose the following system.
CONS: Slightly complicated to set up
PROS: Will result in a much sturdier and accurate sprite selection

Currently we play the animation like this:

  if (this.grounded) {        
        if (avx > 5) {          
           if (!this.moving || this.turning) {            
              if (avx > 10) {   this.playAnimationAtFPS('walk', 20);   }        else
              if (avx > 300) {   this.playAnimationAtFPS('run', 30);    }
  }   }  

Directly in the code

Instead I propose we create an Array called
public var sprArray: Arrray = [];

We push the information into an array

  if (this.grounded) {        
        if (avx > 5) {          
           if (!this.moving || this.turning) {            
              if (avx > 10) {   this.sprArray.push(”walk”);  }        else
              if (avx > 300) {   this.sprArray.push(”run”);   }
  }   }  

To play/select the animation we use a switch statement at the end of the step cycle (or in its own function)

  currentSpr = sprArray();

  switch (currentSpr) {

  case “run”:
  this.playAnimationAtFPS(’run’, 30);
  break;

  case “walk”:
  this.playAnimationAtFPS(’walk’, 30);
  break;

  case “land”;
  this.playAnimationAtFPS(’land’, 15);
  this.landTimer.start(); this.landAnim = true;
  break;
  }

Then we clear the array and start the cycle again

  sprArray() = [];

WHY SWITCH TO THIS METHOD?
The main benefit of this system is more accurate prioritizing between multiple conflicting sprites

Let say that the character has an avx speed of 350 and has just landed on the ground. We have two conflicting sprites.

  if (this.grounded) {        
        if (avx > 5) {          
           if (!this.moving || this.turning) {            
              if (avx > 10) {   this.sprArray.push(”walk”);  }        else
              if (avx > 300) {   this.sprArray.push(”run”);   }
  }   }  

  override protected function landed():void {      
         super.landed();      
              if (this.jumping) {        
                  this.sprArray.push(”land”);
  }  

Using the "push method" we end up with an array that looks like this

sprArray = (”walk”, “land”);

We can then break down and prioritize what sprite gets used in this situation

  for (var anim in sprArray) {
  switch (anim):

  case “walk”:
  for (var ii in sprArray) {
  if (ii == “land”) { currentSpr = “landmoving” } else { currentSpr = “walk” };

  }

In this case we know the dino is walking and he has landed at the same time, so we use the “moving land” spr

IN CLOSING

This alternative method, offers the following:

Flexibility and accuracy. In short, we will have alot more control over prioritizing sprites and selecting the correct one.

1. Cleaner code. All the sprite prioritizing/conditions will be done in a single location/function.
   All the sprite playAnimation functions will also be done in single location.

2. We can accurately observe the number of simultanteous conflicts by tracing the sprArray.

3. Accurate prioritization. Even if we have 3 or 4 conflicting sprites fighting to be displayed, we can filter through the stack by heirarchy and current conditions.

Imagine the following scenario. The character gets hurt. We need to display the hurt sprite. In the current system we would have to have an conditional statement which says if the character is hurt, don't use the falling/landing/jump animation etc, for every condition which are fighting for to be displayed. Its a reactive response. In the new method, we can give it a higher priority without having to alter every other line of code which may conflict.

4. Increased simplicity. As the complicity of conflicts increases, the code should remain relatively easy to problem solve

Let me know if you have any questions.

• Rotate the final sprite when falling in the direction of the fall
• Limit the rotation to 45 degrees downward, so it's impossible to go headfirst into the ground.

It needs to not only be based on horizontal velocity, but also if the player is grabbing the left or right wall.

I am guessing your getting settled in to your new appartment and school =)