The player modification framework provides a simple component extended class that automates the application and removal of temporary and permanent buffs. Modifiable variables MUST be stored in components attached to an entity, otherwise they cannot be accessed.

Player statistics should not be changed outside of the modification framework.

All modifications should be applied through the create_modifier function.

public void createModifier (String target, float value, boolean scaling, int expiry)

It takes the following 4 inputs:

1. String - Target statistic (i.e. "moveSpeed", "stamina", "mana")
2. Float - The value of the modification (5, 0.25, -1)^1a
3. Boolean - True for multiplicative scaling, false for additive increase
4. Expiry - Modifier duration in milliseconds (0 if a modification is permanent)

Use the defines provided in the Player Modifier component to set the String targets of functions. The only stat that cant be set to a negative value is movespeed (as it would invert player controls).

MOVESPEED = maxSpeed in the PlayerActions.

DMGREDUCTION = damageReduction in CombatStatsComponent.

MANAREGEN = manaRegenerationRate in CombatStatsComponent.

MANAMAX = maxMana in CombatStatsComponent.

STAMINAREGEN = staminaRegenerationRate in CombatStatsComponent.

STAMINAMAX = maxStamina in CombatStatsComponent.

You are one dark soul - After rolling your feel inspired to move a little faster than normal. Player speed is increased by 50% by for 3 seconds.

This skill contextual buff would be created by: playerModifier.createModifier ("moveSpeed", 0.5, true, 3000);

A monument to all your sins - After killing the hampter you feel a heavy weight on your shoulders. Player move speed is permanently decreased by 2 units.

This game contextual debuff would be created by: playerModifier.createModifier ("moveSpeed", -2, false, 0);

Other functions that might be useful include:

checkModifier (String target, float value, boolean scaling, int expiry) - Finds if a modifier fitting the given parameters already exists. True if there exists one, false otherwise.

getModified (String target) - Find the float value of the modified stat.

getReference (String target) - Find the float value of the reference stat.

The difficulty with implementing a timed modifier system is returning the variable back to its beginning value once the modifier ends. To combat this there are two statistics managing variables.

• ref[Statistic] - The reference statistic value (i.e. public float refMoveSpeed)
• mod[Statistic] - The modifier altered statistic value (i.e. public float modMoveSpeed)

The reference value is considered your stat base, or point of reference. All multiplicative modifiers are based off this. Permanent modifiers will increase both the modified and reference values.

The modified value is the one being changed and used for setting functions (i.e. updateMaxSpeed).

**Example Reference Permanent and Modified Interaction

Do not worry about excessive decreases, they are bounded (unless otherwise organised by a team). When the modifier that decreased it is ready to expire, the difference it has created is restored. (THIS IS ONLY APPLICABLE TO TEMPORARY MODIFICATIONS)

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

Nothing yet ;) Cause I am about to submit for sprint 1!

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.

Below are the various sprint 4 code improved files related to the implementation of the Player Modifier framework. Each section will show the SonarCloud reports at the beginning and end of the sprint.

com/deco2800/game/components/player/PlayerModifier.java

To improve the SonarCloud rating of this system the following changes were made:

• Alter the usage of static variables and functions to be more appropriate
• Inclusion of new auxiliary variable return functions
• Additional JUnit tests and modified JUnit tests
• Removal of previous placeholder JUnit testing code developed before understanding of mocking and resource services

The new SonarCloud has almost complete code coverage and zero duplication, code smells, and bugs.

These changes were included in this hyperlinked commit

The only code coverage that doesn't exist is on default switch cases that do nothing, and an additional check case that is too difficult to reach.

As these default functions are never used due to the rest of the code library preventing such a value from ever reaching this case, these specific code coverage-less spots can be safely ignored. It could be argued that it would then be more appropriate to use a series of if-else cases, however, the switch cases are much more human readable.