To start with the development of the game, I have used the First Person template that is provided by the Unreal Engine to get a head start and not have to waste time coding the simple controls such as player movement and camera controls and edited the player model by removing the gun that is attached to it as well as the hands but keeping the spawning of the balls as that mechanic can be slightly modified to be used as the throwing mechanic such as preventing the balls from being deleted after a certain amount of time.

To be able to add the ability of throwing a ball, a new blueprint is created which checks if the player has pressed the left mouse button and then secondly, checks if the player is holding a ball or not by checking a boolean variable. If both of these conditions are true, then a ball is then spawned slightly in front of the player and speed is added to it in the same direction the player is facing.

After throwing a ball, the player has to be able to pick up a ball which has been done by having a boolean variable in the ball blueprint determining whether the ball can be picked up or not and when there is a collision with another object that the ball collided with has the tag of "Player" and if the recently created variable states we can pick up the ball, that ball will be deleted and a ball that is attached to the player will become visible.

Moving on with the game, I have started to learn how to implement AI into my game by learning how to create a behaviour tree and how they work at a simple level to be able to create more advanced, working AI to play against.

To start of making the AI, I have made the behaviour tree that is connected to the AI to find a position within a certain distance from the pawn, move to that position and then wait a few seconds before moving again. Along with this, I created two different mesh bounds to determine the area that the AI can move around in. This would allow me to create two teams, place them on the either side of the arena and prevent them from moving to the other side.

As well as the very basics of the AI being implemented, the ability to detect when the player has thrown a ball and hit one of AI has been added by doing simple checks that firstly the

From this point, I plan to improve the AI by having them react to the environment around them. For example, I plan to have them

To start the week, I have had a chat with my supervisor to check on my progress with the game and where to take the game in the future. This talk did however end with a different result as I was expecting advice on how to make the AI in my game be the best they could be, however this was not the case. Instead, I have been suggested to move away from the AI concept all together which I have been reluctant to do with the whole game being based around the AI and is something that I personally wanted to focus on as it is a big thing in video games and would love to get a better understanding on how to make them to a good standard.

Instead of focusing on AI, I have been suggested to change my focus to making my game a multiplayer game which I was reluctant at first to do mainly because I had just finished making a multiplayer game in Unity using PUN which was relatively difficult which wasn't the easiest thing to do and didn't want to experience the problems I had when using PUN. After some time, I decided to accept that it would probably be better to move towards a multiplayer game due to the time constraints that I had and how much more it would allow me to add to the game. After doing some research on how to do a multiplayer game in UE4 (Unreal Engine 4), I realised that is was a lot easier to do compared to PUN and was a lot more on board with it.

The first thing I had to do was be able to get two or more players in the same area which was relatively simple by using the player spawns and having the host as listening host. After this, I created a simple sprinting mechanic and then had to learn replication to be able to have the game the clients sprint as well as the host as without replication, the client would not be able to sprint. This was a good starting block on how replication works and has allowed me to make the other mechanics that already exist in the game to work in multiplayer such as picking up balls and throwing balls.

Carrying on from last week, I needed to move away from having the player being a basic ball that has been stretched to be given the illusion its a capsule shape as this would help improve the aesthetics of the game. To improve the player model, I needed to firstly find a player model that could be used by all players that suits the theme of the game which leads to the player character requiring to be sporty looking. To find the specific model I need, I used "mixamo" which has lots of different player models that are free to use along with a load of animations to go along with the models.

After looking through all of the models that are available, final model that was decided was the model called "Adam" as the model is wearing athletic clothes which fit with the theme of the game which is being a sports game. Along with the model, animations have to go with the model as otherwise the player would just float around and ruin the immersion and these can also be found on "mixamo".

After looking through the movement animations that were available, multiple animations have been downloaded to be able to have the model be able to move forward, backwards, sideways and diagonal along with an animation for being idle. A throwing animation has also been downloaded for when the player throws the ball.

After getting the movement animations, a blendspace has been used to be able to put them all together and have the appropriate animation play depending on the direction the player is moving as it makes it easier to determine which animation needs to be played depending on the direction of the player. A blendspace also allows for a smooth transition between switching animations to help maintain the immersion.

After deciding on the player model and setting up the animations for the player model, the initial UI was created with the first aim to be creating a working timer. This was then followed by creating visually displaying the number of players in each team by checking the length of each team array and setting up the progress bar that is located under each team number. The progress bar for the number of players remaining in each team was achieved by taking the current number of players remaining on each team and dividing it by the initial number of players on each team. This returns a percentage which could then be used to decide how far the progress bar needs be.

The world interaction was the main focus of this week but first the hit detection had to be refactored as errors were appearing when players were being hit. The main difference between the refactored piece of code and the original is that the organisation of the code has been improved allowing for easier editing of code allowed me to find the error that existed in the old hit detection.

After the refactoring, new mechanics were added which were to have the ability to pick up dodges by picking up powerups on the floor and increasing the players stamina by also picking up powerups. To be able to have this work, a box simple box is used which has collisions disabled to allow players to walk through the powerup and an overlap detection is carried out. If there is an overlap between the player and the powerup, the number of dodges the player has is increased by 1 while if the player picks up a stamina powerup, the player has their stamina fully restored.

To be able to have the player have their stamina restored, a stamina system had to be implemented which was done by having a timer for how long players can sprint for. When the player is pressing down the sprint button, which is left sprint, the variable that stores the players stamina is decreased by the delta time.

Along with the powerups, the wall that moves in towards the centre of the arena was next to be implemented. To accomplish this, new blueprints were created for the walls which firstly checks to see how much time is left in the game and if enough time has passed, the walls move in towards the centre by using the "move component" node which allows a destination to be set for the component to move to and the amount of time it takes for the component to move to the destination being determined. This allows for the walls to reduce the size of the arena the players are in to try and increase the number of players being hit.

The final extra mechanic that has been implemented is the ability to bring back players into the arena by hitting a target on the opposite side of the map. To have this possible, two new arrays have had to be created to place the players that have been eliminated into which allows for a random player within the appropriate team to be brought back in to the map when the target is hit.

For this week, no progress was made on the game as other assignments were due in this week and time needed to be put aside to be able to complete those assignments. Work on the game will continue next week.

During this week assets that were found to improve the visuals of the game. The assets that were acquired was a gym which replaces the grey walls surrounding the players, powerups to replace the cones and cylinders that were used to represent the powerups and textures for the walls that move in to move the players closer together with each of these assets coming from the Unreal store.

Converting the world into the gym was a lot harder than expected due to multiple things such as the coordinates powerups can move to, the location the players get teleported to when the game starts and when they are eliminated and so on and errors appearing when the balls hit the floor and walls as there was no tags assigned to them. Due to the gym having large numbers of assets creating the walls and floor, the easiest way to fix this issue was to have 5 large invisible cubes with four of them being placed just in front of the four walls and the last one being just above the floor, with each of them having the tag "walls". From doing this the error that was appearing earlier disappeared.

During the final week of the project, the only piece of coding that was done was setting up the ability to reset the map after a match is finished. In particular, the parts that needed resetting was the arrays that store the players, the match timer, game state and so on. Without this, the match could only be played once.

After setting up the reset function, the rest of the week was dedicated to writing the dissertation that went along with the game.