Week 11
For Week 11, I have been working on adding further mechanics to Arctic Rush mainly involving around AI with some material work on the side.
For example shown in the GIF below, is a circle pulse effect I created using a material blueprint. I aim to use this, mostly within the tutorial phase, to indicate where the user should place the penguins. I’m debating creating alternative versions such as red or white, to indicate what the player is doing is incorrect. Either that, or testing whether the original material could be adjusted to go from white to green once the penguin is placed within the zone.
AI
Below is an example of my work with testing out possibilities with AI for my game. The left version involves each AI travelling to a “random” point within the nav mesh and the right is patrol point based with the AI moving between each point in a specified order. However, the main issue surrounding the random path is that once I started to add more AI, they generally ended up taking the same route and bumping into each other. Although comical, this could potentially become frustrating and game breaking for the player. Personally, I feel that the patrol point based is enough for moving my penguins around their icebergs. Although, I am experimenting with an adapted version which creates the blueprint on the point not the AI itself. The advantage of this is that it allows for the points to be altered more dynamically by placing them in the scene rather than assigning them in code.
Random AI
This allows for the AI to move in a seemingly “random” order. However, once applied to multiple AI characters they all appeared to move along the same route which is not ideal within a small space.
Patrol AI
The patrol AI allows for the character to walk on a designated path which is useful if you want to have complete control.
Week 12
Path AI — Dynamic Update
Following on from the first try at path point AI, I have since adapted the method so the blueprint is controlled via the path points themselves rather than the AI character. This works by creating the PathPath object as an actor which are placed throughout the scene. For example, within the image below, the path point placement can be seen with the arrow which indicates the direction that the AI will follow. This system has been implemented in game to control the boat’s movement through the water.
This task is quite a large blueprint, hence the two images. Essentially it involves getting a reference to the boat, then finding the patrol path array and current path index from the object. It then uses this information to determine the location and defines a random point before using this to set the blackboard vector key. It finishes by defining the wait time command which is calculated using a combination of the defined wait time and deviation (how much it can vary by) and the result of these two values is how long the AI waits in the point for.
An enumerator stores the different patrol options for the AI such as:
These are used within the ReachedEndPoint Task to define the next behaviour steps.
This essentially checks the number the AI has reached within the available index and if the number is still valid within the range, it continues along the path. If not, there is a switch in place and depending on the chosen behaviour within the editor, the AI will either: Do Nothing — Finish Execute aka nothing else will happen, Patrol Back — set the path direction by -1 so the AI will go backwards along the route and Loop — sets the index to 0 so the AI goes back to the beginning of the route.
However, for this to work correctly, I had to assign a character class to my boat object as pawn’s do not move due to not having the capability of utilising a navigation mesh. Strange workaround but it works! Here is a screenshot showing the settings within the inspector on the boat object:
I believe that by implementing simple name changes in blueprint and duplicating the existing setup, I will be able to re-use this to create the Penguin AI movement system.
Updated Player Movement
After testing, it became apparent that the movement system needed to be changed as teleportation just wasn’t working due to my map and playable area being extremely small and thus it just became more of an inconvenience than anything else.
Above shows my first attempt at creating locomotion movement using the oculus controllers. This worked somewhat well, however, the player would fly backwards if the down direction was pressed on the joystick which isn’t ideal!
The second method worked a lot better! This method didn’t use the actors location for reference and instead only used the camera and the different movement inputs. The only slight issue I had with this was that the players collider was getting stuck on the terrain due to its low height, however, this was fixed by simply changing the slope angle that the player could walk on to higher than 45 degrees. Now, the user can move the pawn around with the left joystick and turn with the right creating a more pleasant experience.
