UGS Polishing

Summary

Following sprint 3 it was found that the UGS was not fully integrated with necessary systems which in turn limited its functionality. Examples of this included the main character and enemy not being included in the UGS, effectively meaning the player and enemies could traverse any part of the map and walk through structures and obstacles, heavily impacting the overall game play experience. Further issues which had similar effects on the overall game play included: the lack of isometric movement, and lack of extensive jUnit tests.

Overall, fixing the aforementioned issues is important to the studio as it will greatly improve the game play experience.

Fixes

Isometric Player Movement

Through feedback received from sprint 3 it was found that player movement was preferred to be fixed to four directions (i.e. the player can either move up, down, left or right). This movement system was ideal given the UGS was created as a grid layout. Implementing this feature is important for the studio given that it will allow the full utilisation of the UGS' features, allowing detection of objects and enemies in the player's movement path.

In implementing the isometric movement of the player, the physics component of the players movement was removed in replacement for completely grid based movement. The players movement direction is defined as a vector containing their x and y directions in the UGS. This vector is calculated by calculating the residual force of opposing directions. For example, if the player holds down A and D simultaneously, the residual force would be 0 in the x direction. This is implemented as follows:

if (gameTime > lastMovementTime) {
        float posX = movementKeyPressed[3] ? 1 : 0;
        float negX = movementKeyPressed[1] ? 1 : 0;
        float posY = movementKeyPressed[0] ? 1 : 0;
        float negY = movementKeyPressed[2] ? 1 : 0;

        Vector2 movement = new Vector2(posX - negX, posY - negY);
        movePlayerInUgs(movement);

        lastMovementTime = gameTime + movementTimeDelta;
}

The lastMovementTime is used to stop the player from continuously moving at an extremely high speed. This only allows there to be any input registered after a certain number of frames, determined by movementTimeDelta.

This movement vector is then handled by the UGS, in movePlayerInUGS():

ServiceLocator.getUGSService().moveEntity(player, playerCurrentPos, direction.x, direction.y);

more details on the moveEntity function can be found here. LINK TO MORE INFO.

Player / Enemy UGS integration

Another issue identified at the end of sprint 3 relating to the UGS was that enemies an players had not been fully integrated with the UGS, allowing them to move through obstacles and structures. This is intended to be remedied, and is important to the studio as it greatly hinders game play.

Enemy movement is now handled entirely based on its position in the UGS. Instead of using a Physics component that applied an impulse to the entity and changed its game world coordinates, the enemies now use a simplified version of Dijkstra's shortest-path algorithm to move towards the target.

This movement algorithm is attached to an entity via the AITaskComponent; for example, the MeleePursueTask implements this:

                                .addTask(new MeleePursueTask(target))```


In MeleePursueTask:

public MeleePursueTask(Entity target) { this.target = target; dayNightCycleService = ServiceLocator.getDayNightCycleService(); movementTask = new MovementTask(target.getCenterPosition()); }

/**

• start chasing */ @Override public void start() { super.start(); movementTask.create(owner); movementTask.start(); }

## Testing
Finally, further jUnit and mockito tests were created and integrated. 


## Future Expansion
In the future, to further expand upon these features should another development team take over, further user testing, and research amongst developers should be conducted to ideate what further polishing should occur.