Description

Player movement animations are based on the movement vector as defined in the KeyboardPlayerInputComponent to ensure player movement properly reflects the user input. Animations are designed to loop.

Main Function Explanation

Animations are triggered through entity event triggers.

The current implementation of this is:

There are two listeners currently:

• "movementIdle" ~ The player is standing still
• "movementHandle" ~ Player is moving

The movementHandle trigger is to be provided a Vector2 representing the movement direction. The X and Y components should be either 0, 1, or -1.

• -1 is defined as left (x) or down (y).
• 0 is defined as nothing.
• 1 is defined as right (x) or up (y).

Each time a new animation is activated, an internal String variable holding an animation direction enumerator is updated.

The current animation can be returned using:

public String getMovementAnimation()

Movement String Enumerators:

The current movement is stored as a String enumerator type, these include:

• MOVEIDLE = "moveIdle"
• MOVEUP = "moveUp"
• MOVEDOWN = "moveDown"
• MOVELEFT = "moveLeft"
• MOVELEFTUP = "moveLeftUp"
• MOVELEFTDOWN = "moveLeftDown"
• MOVERIGHT = "moveRight"
• MOVERIGHTUP = "moveRightUp"
• MOVERIGHTDOWN = "moveRightDown"

Currently there exist no animations nor plans for diagonal based moments (right up or right down as examples). However the additional functionality has been included for player input response robustness and as a code ready for expansion.

UML Diagram

UML diagram reflective of the final Sprint 4 implementation.

Who To Talk To?

If you need any help or want your statistics modified (or implement in a specific way) please contact Isaac Graham in Team 6 :)

In Development

Nothing!!!

Testing Plan

Utilise SonarCloud and JaCoCo code analysis tools to ensure code is largely covered.

Broad strokes of testing plan are as follows:

1. Test utility functions first. Should immediately catch errors present in other peoples code
2. Check Modifier acceptance and expiration components to ensure they properly do or do not end.
3. Check each modifiable statistic individually. Split the test into two types. Both should use permanent and temporary modifications.
   • Check multiplicative behaviour.
   • Check additive behaviour.
   • Check both the reference and modified stat variables in both tests.

Add, modify, and repeatedly test both implementation and testing code using SonarCloud code smells to ensure code is properly covered.

May need to add additional content for the player sprite itself. Will adjust testing plan accordingly once that is decided by the team.

Sprint 4 Polish

Initial SonarCloud was

After the typical code smell cleanup the report was

The only remaining code smell was due to the use of a lamba function, to my knowledge with the addListener function, I am unaware of how to implement an event based function with an input.

Change Log

07/09/2022 - Created this page! (Finally)