Production

• Project creation

• Overview

For this project I will be using the program called unreal engine, the reason for this as mentioned before is that it allows the use of blueprints to create the desired functionality instead of directly using code. It also allows the user to quickly test any changes to their project without first having to package the game first, this is important as it helps save time when creating new features and testing for bugs.

In order to create my Project I will be breaking down my work over three weeks, I will intend to finish the work that week before moving on to another section of the project. I will provide a breakdown of the blueprints I created each week along with a brief explanation of what the blueprint is doing. This will include screenshots of each of the relevant blueprint sections, this is to give a visual representation of what is happening when the code is implemented.  

• Week 1

This week I will be focused on making a main menu, options menu and a simple level layout to test my camera controller. I also intend on having the camera movement ready by the end of the week, this would need to include the following:

• Getting the keyboard inputs for W, A, S and D. I will also need to get the keyboard inputs for the arrow keys.

• Setting a maximum range for the camera to be able to move.

• Main Menu Visuals

The following is a screenshot of the main menu as it appears in the the project, it only consists of three button for main menu, controls and exit, the blueprints of witch will be the first to be explained:

• Main Menu Blueprint

In this section I will be going over how the main menu, controls and exit button were implemented. These where relatively simple to implement as not much was needed to be done in order to create the few buttons that where needed to get them to function correctly.

• Main Menu Level Blueprint

 The following image shows the blueprint mechanics for implementing the UI (User interface) for the main menu. The blueprint follows the basic flow as follows:

1. The blueprint starts with the "event begin play" component, this is used for making the following blueprint code happen when the current level starts.

2. This is followed by a "create widget" component, this was used to create a copy of the main menu interface.

3. Finally this is followed by "add widget to viewport", this adds a created Interface to the camera view of a level. This allows you to actually see the main menu interface that was created by the above point.

• Main Menu User interface Blueprint

 This blueprint is for the above mentioned user interface that was added to the view port earlier, this blueprint adds the functionality to the interface itself. This blueprint starts the trend of most having multiple starting events that each have a semi-complicated functionality.

The first one on this being the part that makes the cursor always visible on screen while the main menu is visible, this is created as follows:

1. The function starts with the component event construction, this like event begin play makes sure the blueprints to follow are run only on creation of this interface.

2. The code then goes on to set a variable known as "Show Mouse Cursor" to true using the component "set", this as stated above make sure you can always see the cursor. This also had a target for the function to run this is set to player index 0. (Player index 0 is treated as player one)

The next part of this blueprint sets the button functionality, using three separate starting events. 

1.  The first one starts with an "on click event", this is for when the start button is pressed. This is then followed by the component "open level (by name)", this opens the level PvsC_V1.

2. The next one also starts with an on click event, this one for when the "settings menu" is pressed. The next component like above is the "open level (by name)", but this time it opens a level named "controls".

3. For the last button this also starts with an "on click event", this one is foe the exit button. this one uses the component "quit game" and its only role is to exit the game.   

 • Options Menu Visuals

The image below is the final visuals for the options menu, for the project. This would be replaced if the game ever got completed.

• Options menu blueprint

In this section like the main menu only consists of a basic interface intended to be the settings menu, but for the intent of the current project only shows the controls for the game.

• Options Level Blueprint

Just like the main menu, the level blueprint only implements the user interface to the viewport.

1. Just like before this also starts with the "event begin play" component, this is used for making the following blueprint code happen when the current level starts.

2. This also uses the "create widget" component, but this time it is used to create a copy of the controls interface

3. Lastly just like last time it appends this interface to the viewport using the component "add to viewport".

• Controls User Interface Blueprint

 There isn't much to say about this section of code as there is only a single button that required functionality to be made, the only other thing was an image with the games controls on placed on it. But the following is how it works. Moat of this functionality is similar to the main menu, this being because there are less options on this level.

1. The first part is like stated above an identical copy of the function created for the main menu, this is used pretty much in every blueprint oof a user interface.

2. The next section is the functionality for the back button that takes you mack to the main menu. This starts with the component "on click event", this also as before goes on to the component  "open level (by name)"

• Level Visuals

The following is a screenshot of the level as created at the moment, this will be changed later as this is only temporary to test the camera controller:

• Level related blueprints

In the next section I will be going over the blueprints involved in getting the level to work, these include the camera controller, building placement and unit control functions. Due to there being so many different blueprint section to get the level to work I will break each down separately. I will also attempt to order the different section in order of relevance, but this might be difficult as many tend to interact with other blueprint sections, but this will be explained wherever it is important.

• Camera Controller - Blueprint overview

 The following image shows the overview of the camera controller, this blueprint contains most of the functionality of the  project. As such I will be explaining each section of it separately 

• Camera Controller - Keyboard input

This image shows the part of the blueprint that takes the input from the keyboard, this is then stored in separate Booleans for each direction that the camera can move. (Up, left, down and right).

For example taking the up movement part of this blueprint it functions as follows:

1. It starts with either the component "Keyboard Event W" or "Keyboard Event Up", for these it is looking for when the key is pressed and when it is it sets the Boolean "Key Up" to true. 

2. At the same time it is also looking for the "W" key or the "Up" to be released and when it is it sets the Boolean "Key Up" to false.

The other parts of this blueprint section work in a similar fashion to the above but are linked to different keyboard events and set another Boolean relating to another directional movement instead. The main reason for this will be apparent later, but for now its basically used to store what button is being used and when.

• Camera Controller - Collision

The following section of the blueprint checks for the camera collision on the boundary of the level, it does so by checking a set of collision boxes attached to the camera rig. There are sperate collision boxes for checking collision with the north, south east and west boundaries if the map. Below is a breakdown of how this works, the example being for detecting the north collision:

1. Firstly the component "on component begin overlap (CC_CB_North)", it also uses the component "actor has tag" to check if it has the tag "wall". It then uses a branch to check if it does have the tag wall and if it does it sets "Collision North" is true .

2. The blueprint then has a similar section but in reverse for checking when the collision stops. This uses the component "on component end overlap (CC_CB_North)", this also checks for the tag "wall". This also uses a branch to check if it it a wall and if it is it sets "Collision North" to false.

The code then proceeds to do the same for detecting the collisions for west, south and east. The only differences being that the  "on component begin overlap" checks a different collision box and the Boolean they set is based on the direction the collisions took place. The reason for setting these will come up in the next blueprint section, but essentially they are to make sure the camera cant leave the boundary of the level.

• Camera Controller - Movement

The following images show how the blueprint handles moving the camera, this blueprint section relies on the Booleans that were set in the "Camera movement-Control input" and the "Camera movement-Collision" sections. This section starts with the component "event tick", this is because this had to be updated every frame of he gameplay. The blueprint section had to be split into to separate images to be more clearly seen, the last part of the first image and the first part overlap at the branch component for the right button to make it easier to follow. 

So for a brief explanation of this blueprint section :

1. As stated above it starts at the component "event tick", it then proceeds to a branch (if) component that checks the Boolean "Key Up". If true it then uses another branch component for the Boolean called "Collision North", if this is false it then sets a variable "speed Up" (integer) to another variable called "Master Speed" (integer). However if the branch checking "Key Up" is true or the branch checking "Collision North" is false, it instead sets the variable "speed Up" to zero.

2. It then proceeds to to the same as step 1  for west, but instead of checking Booleans "key up" or "Collision North" it checks "key left" or "Collision west" instead. As for the variable it sets its called "Speed left" but it still uses "Master Speed" when setting the integer or setting it to zero when applicable.

3. This also follows in the same vein as step 1 but this time uses the  Booleans "Key Down" and "Collision South", the integer it sets is "Speed down" instead.

4. The last similar section is also almost identical to step 1, this time however it uses the  Booleans "Key Right" and "collision East", as for the integer it uses for the set component it is "Speed Right".

5. Finally the blueprint uses the component "Set",  this sets a vector called "camera location" that takes the cameras location on the level to be used later. It then uses the component "set actor location", for the X axis it uses the "camera location" along with the "speed up" and "speed down" to locate the new X axis location for the camera. At the same time it get the new location for the cameras Y location by using the "camera location" again, along with the "speed left" and "speed right". For the Z location it uses the location rom the vector "camera location" without any changes.

• Week 1 - Review

During the development of the blueprints this week I would say that making the main menu and option menus went that difficult, I managed to implement these quicker then expected. The only thing couldn't get to function correctly was the image in the options menu, I couldn't get the image to resize based on the size of the display.

 As for the main issue I came across this week, it was when I was creating the boundary box to make sure the camera (and later other moving assets) wouldn't leave the perimeter of the map. The issue I was having was that although the camera would stop when it collided, it it then collided with another wall for instance at a corner it would end up phasing through the wall and escape the boundary of the map. The following code was what I attempted to create, I realised that it was getting overcomplicated and wasn't working so I ended up scrapping it. That being said the next attempt was the one that was kept for the final product, the one that was explained in the Camera Controller sections.

• Week 2

This week was focused on creating the User interface for the level, this will contain a majority of the functionality of the game so getting it made next was ideal. This involved creating a UI widget, that itself contains a lot of important code that will be referenced and used a lot in later blueprints. To a lesser degree this will also need to referenced by other blueprints but this will be explained when it becomes relevant. I also managed to get the functionality for the building completed this week, I was planning on that carrying over until week three but it went better then expected.

• In-game User Interface Visuals

The following is a screenshot shows the in-game user interface implemented in-game alongside the development level geometry. This was also the time the level geometry was altered in order to give more space for testing the building and units functions that will be developed later.

• In-game User Interface Blueprint overview

 This blueprint shows the overview of the functionality of the In-game user interface, this sets most of the important variables that will be used by most other blueprints going forward.

• User interface - Initial parameters

For this section of the blue print is used to se the initial parameters of of the interface, these being the numbers and arrows present on the interfaces buttons. I also set the cursor to be always visible, just like the main menu and options interfaces, this is so the player can still interact with the interface alongside the accompanying level. The blueprint itself works as follows: 

1. It starts with an event construct, that is followed by a set component that sets the on on-screen cursor to always being visible. This component uses the target player controller at index zero, so the program know what user it is referring to.

2. It then proceeds to use the component set text with the target of "BO-A" (Building option a) which is the first button from the top of the left list. The program sets this using a variable called "Current building list" (integer) and increasing its value by one.

3. The code then repeats the last step three more times for not only the last two numbered options for the building list (BO-B and BO-C) but also the three options for the unit list. (UO-A, UO-B and UO-C)

The reason that the arrow keys aren't set during this time is that they already have a default value set that isn't variable until, not until something happens later in the blueprint.   

• User interface - Building buttons (Option A)

This section of code defines what happens when the first button of the building list is pressed, (BuildingOptionA) the other buttons (BuildingOptionB and BuildingOptionC). The only differences in the code is what the buttons text are changed to, so I will only really need to explain one. 

So for this example it goes as follows:

1. Firstly it starts with an on click event, this is then followed by a branch component that checks if a Boolean called "Current building Busy" is true or not. 

2. There is also a section that runs from the first branch component of the code that runs only if the "Current building Busy" Boolean was false when the button was pressed. This goes on to se the Boolean to true, then proceeds to set all the other buttons on the building menu  to a capital "X" and sets itself to a capital "B". It does this by using the set text component several times, each with target of one of the buttons in the building list. (BuildingOptionA, BuildingOptionB, BuildingOptionC, BuildingOptionUp and BuildingOptionDown)

3. If the Boolean "Current building Busy" is true then checks another Boolean to see if the button pressed was actually buildingOptionA, it does this by checking if a variable called currentBuildingSel (integer) is equal to currentBuildingList (integer) plus one. If it is it proceeds to set all the button back to their ordinal setting they had before they where changed in step 2. 

• User interface - Building buttons (Up and Down)

Unlike the code that is ran when when the other buttons are pressed the buttons for both up and down are connected to the same line of code, this is because the function of each button relies directly on the other. Because of this I will also be explaining its functionality separately from above, as follows:

1. This blueprint starts at an on click event for the "buildingUp" button, it also has another starting event which is also an on event click but for "buildingDown" button. (Go to step 2 for the "buildingUp" button or go to step 3 for the "buildingDown" button)

2. For the "buildingUp" button after the click event, it uses a branch component to check if the variable "currentBuildingBusy" (Boolean) is false. If it is false then it checks another branch component, this time to check if the "currentBuildingList" (integer) isn't one and if it isn't it sets it to its current value plus one. (Go to step 4)

3. For the "buildingDown" button just like the "buildingUp" button it has a branch to check if the variable "currentBuildingBusy" (Boolean) is false. if it is it then checks the variable "currentBuildingList" (integer) isn't zero, if it isn't it then sets 

4. Once the above code sections combine together, they both go on to set the numbers in each button (BO-A, BO-B and BO-C) to either one more or one less then their current value. This is achieved by using the set text component targeting each button, then using the variable "currentBuildingBusy" (integer) and adding a number to it (one, two or three) based on the button it is changing at the time.

• User interface - Unit buttons functionality 

This blueprint section works in an almost identical fashion to the above building button blueprint section. The only differences being that any reference to the word "building" being replaced with the word "unit" and the buttons having U instead of B in their names. (Being UO-A, UO-B and UO-C)

So with the exception of the above differences it would be like explaining the same functionality again, the below image has been provided to show that they are almost identical. 

• Camera Controller actor - Building Placement Cursor movement and Visibility

This blueprint section shows the code behind part of the functionality of the cube used to place the buildings. This part of the code both sets the visibility and controls the movement of the building placement cursor:

1. You may notice that this part of the code doesn't have a visible start component, this is because it needed to be connected to the event tick component therefore carries on from that section of code.

2. This section starts with a branch that checks a variable called "buildingPlacmentExists" (boolean), if true it sets the location of the building placement cursor. If it is false however it uses the spawn actor component to spawn the building placement actor, this being the building placement cursor mentioned above. It then does the same as before and set the location of the cursor. 

3. Finally it ends in a branch that checks if the called variable "currentBuildingBusy" (boolean), if its true then it sets the building placement cursor to visible using a set visibility component. if false it sets it to invisible instead. 

• Building placement actor - Camera controller Bridge

This blueprint section shows the code used to allow the building placement actor to interact with the Camera Controller, this allows this blueprint to gain access to functionality of the Camera Controller that it would otherwise not have access to. It does this by doing the following:

1. This section of code starts with the component event begin play, this is then followed by the component cast to. The target of this being the player pawn, the player pawn being the camera controller as this is what the player controls. 

2. Next it creates a variable called Player Ref (Object Reference) as a reference to the camera controller blueprint, to be used later in the blueprint.

• Building placement actor - Building placement checker

Just like the blueprint section that was created for the up and down buttons on the user interface, this blueprint also has two start points. The first is for when the building cursor begins to overlap another asset (actor) and another for when it ends overlapping another asset. This blueprint uses a function of unreal engine known as tags that only this and the camera controller itself use.  It uses them to count how many overlapping actors there are that have the tags wall or building, it does so to know if a building can be placed or not. the code itself goes as follows:

1. The first fork of the code starts with a component called on component begin overlap (Building Placement), it then checks if the building placement cursor is overlapping another actor. It then sets a variable called "otherActor" (Object Reference) to a reference of the other actor.

2.  Then it uses a branch component to check if the overlapping actor has a tag (either wall or building) if it does, then it sets a variable called overlaps (integer) and sets its value to its current value plus one. (To see how this would carry out skip to step 5 for the next dection of code.) 

3.  The second fork in the code starts with an on component end overlap (Building Placement) component, it then goes on to set the variable called "otherActor" (Object Reference) to  reference the other actor.

4. It then uses a branch component to again check if the other object has a tag (wall or building), if it does then it sets variable called "overlaps" (integer) to its current value minus one.

5. This section starts with a branch that connects directly to the other two forks in the code, it checks the variable "overlaps" (integer) to see if its more than zero. If it its then it sets a variable called "canPlace" (Boolean) to false, if it isn't then it set the same variable to true instead.

• Camera Controller actor - Building placement Command

This section of the code is the part that works in conjunction with both the building placement cursor and the building placement checker blueprint sections. This section of code is the part that spawns the actors for the buildings, because it takes up so much space and cant be read I will break the image down it to smaller sections and explain each part separately.

• Camera Controller actor - Building placement Command (Part 1/2)

This is the start of the building placement command and it functions in the following way:

1. This section starts with the mouse event (left mouse button) then uses a branch to see if the variable "canPlace" (Boolean) is true. 

2. If it is then it check another variable using another branch, this being "currentBuildingBusy" (Boolean) is true, if it is then it carries on the the next point.

3. The final branch in this image checks the variable "currentBuildingSel (integer) equal one, if it is it goes to the next component in the image. This is is the spawn actor component and spawns the actor "builderSite", then carries on to the next part.

4. If the above mentioned "currentBuildingSel (integer) is more then one (up to four) as seen in the above image, each of those sections is also the spawn actor component. Just like above each section spawns its own building being a generator, barracks and vehicle bay. After each section spawns its own building, it moves on to the next part.

• Camera Controller actor - Building placement Command (Part 2/2)

This section carries on from the pervious section after it has spawned it relevant building, this part resets the button on the in-game user interface for further use. It does so as follows:

1. This sections starts with the mouse event (left mouse button) then goes on to call the custom event Movement Select, this has nothing to do with the functionality of the building placement. It is only here because it also needs to be called of the left mouse button and you can only have one of each starting event. 

2. It then properly starts by setting the variable "curenntBuildingBusy" (Boolean) to false, this being so the program knows its finished with placing the building.

3. It then goes on to use five of the same component, that being the set text component which sets the text for the in-game interfaces building list buttons back to what they where before the building placement command was activated.

The fact that the custom event for Movement Select was called here will be important later, but its so that unit based blueprints can be interacted with by the left mouse button. 

• Week 2 - Review

During this week of production, quite a lot was created but most of the issues I had was keeping track of all the variables and this was partly resolved by learning how to use the    cast to function to crate bridges between blueprints. This allowed the blueprints to read and alter the variables in each other, this allowed for more complex interactions in the project. 

The main issue this week was getting the cursor for placing the buildings to detect if a building could be placed, this took a fair amount of the week in itself. The issue I was having was that the cursor would detect any overlapping assets, but if it stopped overlapping an asset it would allow for placement of building even if it was still overlapping an asset(s). The problem was that I started using a Boolean for checking for overlapping assets but it would come back as false after ending overlap with any asset even if it was still overlapping with another one. So what I did was added the variable "overlaps" (integer) after the check for walls and buildings to count the amount the cursor was overlapping with and added another branch to check if this was zero before allowing for buildings to be placed. This ended up fixing the issue for walls and building, but you can still place buildings on units which is another issue to be resolved. The reason I didn't have any code to show here is because I managed to fix the issue without throwing it all out.

• Week 3

This week was supposed to be focused on finishing the building related blueprints and then moving onto the unit blueprints, but because making the building blueprints went easier then expected I could focus on the harder units blueprints. The main reason these would be difficult was having to implement basic AI (artificial intelligence), for this project it was a nav (navigation) mesh. This was so that the units spawned by the buildings could be moved by the player. The following blueprint sections are what was created to achieve the desired results.

• Camera Controller actor - Unit Spawn function

This section is similar in functionality to the building placement command, it essentially spawns actors just like the building command does. The main differences are that the units wont spawn unless their required buildings are present. If they aren't then the function will wait until the building is available or the function is manually cancelled. Just like with the building placement command i will be breaking this blueprint up into two sections and explaining them separately. 

• Camera Controller actor - Unit Spawn function (part 1/2)

This section starts with a custom event component, I only noticed this was available in unreal engine late into development and didn't end up having time to alter all the code to using this component. I know this would have made the whole program more efficient and streamlined but I wouldn't have had the time to finish the rest of the project if I changed everything over to custom events now. As for this part of the function, it runs as follows:

1. The first part after the custom event starts is a branch that checks if the variable "currentUnitBusy" (Boolean) is true and if it is it goes on to another branch, this one checking branch the variable "currentUnitSel". (integer)

2. If the variable "currentUnitSel" (integer) is one, then it goes onto a get actor of class component that looks for the building site actor. If it is one then it goes on to a spawn actor component, that spawns the builder actor in front of the building site if it exists. 

3. If the branch that checked for the variable "currentUnitSel" (integer) was given a value of more than one, it would go on to three more branches, each checking the variable to see if its one more than the last branch checked. Then it would spawn a different unit for a specific building based on the value of the variable "currentUnitSel". (integer) 

4. After this the code then goes onto the next part where it joins up to one component.

• Camera Controller actor - Unit Spawn function (part 2/2)

This section of the code is similar to the code section mention in Building Placement Command (part 2/2) in the fact it is basically resetting the buttons back to what they where before a unit was selected. As such it has a similar functionality as follows:

1.  This section carries on from the spawning of the units in part 1/2 and starts with a setting the variable currentUnitBusy (Boolean) to false.

2. It then goes on to use five of the same component, being the set text component that again is used to set the buttons back to what they where before spawning the unit. The only difference being that it is resetting the buttons for the unit list this time.

• Camera Controller actor - Unit Spawn function, calling the function.

 Seeing as this is a custom function, you have to call it in order for the code connected to it to run. The following image is part of the camera Controllers event tick function code, the custom function was placed here because it has to be called frequently. It was placed between the part of the code that moves the camera and the part that controls the movement and visibility of the Building Placement Cursor.  Its only a very simple part of code, but it works as follows:

1. This section starts with a branch that checks if "currentUnitBusy" (Boolean) is true if it is it goes to call the custom function Place Unit then carries on to the code for the Building Placement Cursor.

2. If the "currentUnitBusy" (Boolean) was false it just skips the call to the custom function and goes straight to the Building Placement Cursor code instead.

The reason this custom function is called every tick is so that any units that are waiting to be spawned because their building isn't ready will spawn immediately when the building is available.

• Camera Controller actor - Unit Movement Code (Part 1/2)

 The following blueprint section activates when the custom event Movement Select is called, this will called whenever the left mouse button is pressed. This code also has a small section dedicated to the right mouse button, I will explain both as follows:

1. For the start this part of the blueprint has a mouse event (Right Mouse Button) and when pressed sets a variable called "deselect" (Boolean) true. When the right bouse button is it released it sets "deselect" (Boolean) to false instead.

2. As for the custom event of Movement Select, it starts when the left mouse button is pressed as seen in the Building Placement Command Blueprint.

3. This command first sets the variable unitTarget (object reference) to the object that was selected when the left mouse button was pressed.

4. It then sets another variable called "unitLocation" (vector) that stores the location of the area that the mouse cursor was pointing at when the left mouse button was pressed. 

This is to get all the required information ready for an upcoming blueprint section and will make more sense soon.

• Base-GameUnitV2 - Unit Movement Nav Mesh

The following image shows the current level in the game, the section highlighted green is called a nav mesh (navigation mesh) and is necessary in order to have the units move in a reasonably useful way. It allows for them to know where obstructions are and navigate around them, there is a slight error in the nav mesh, as shown in the image. The error being the small amount of green highlight on the middle wall, this is unintended but I didn't have the time to fix it and it doesn't really affect the AI movement much anyway. 

• Base-GameUnitV2 - Unit Movement Code  (Part 2/2) 

The following image is the code that runs along side the above Nav mesh, in order to let the player select and move unit(s). This is done in two parts that will be explained as follows:

Bridge to camera controller

1. This begins with the event begin play component, it then uses the default controller component targeting itself to set up basic part of the AI functionality.

2. It then uses the cast to component targeting the player pawn (camera controller) and sets a reference to it for later.

   Unit movement

1. This part of the blueprint starts with the Event Tick component, next it has a branch that checks if the variable "deselect" (Boolean) is true or not. If its true then it sets another variable called "isActive" (Boolean) to false.

2. If the variable "deselect" (Boolean) stated above was instead false, it goes on to another branch that checks if the variable "unitTarget" (Object reference) is equal to itself. (the object running this code)

3. If the branch checking the "unitTarget" (Object reference) in the previous point came back as true, then it sets "isActive" (Boolean) to true. But if it was false then it continues to another branch that checks if the "isActive" (Boolean) is already true.

4. If the variable "isActive" (Boolean) is already true, then it uses the AI Move To component with the target of self and the destination given to it by the variable  called "unitLocation" (vector) to move to a new location chosen by the player earlier.

• Week 3 - Review

The was the last week of production that I could reasonably afford to do while still being able to complete all the requirements for the course by the deadline. So this week was focused on wrapping up a couple important things. The first being setting up the creation and then the movement of the units, this went surprisingly smoother then I expected. The only errors I had here was the movement of the units ignores any player spawned assets such as buildings and other units when planning their route. This causes units to crash into buildings and other units, causing them to scrape past the obstruction and occasionally getting caught behind/between them. I count figure out a way to fix this issue so it persists even in he current version.

• Final product

• Persistent known issues

• Controls menu image

 When creating the image for the controls page, I couldn't figure out how to get the image to resize to fit the screen. So it still just stays the same size and anchored to the middle of the display.

• Untextured sphere

While creating the project in week one, a random untextured sphere just started showing up randomly. I never managed to figure out what it is, so I never managed to fix it. It does however seem to cause several issues when it shows up, including but not limited to.

1. Blocking the cameras view of the play area if it spawns in the area above the play area but below the height of the camera.

2. Interfering with the navigation/movement of the units of it spawns intersecting the ground of the level, potentially causing the units to get stuck on it.

3. For some reason the bug of the untextured sphere always show up intersecting the centre of the map when loading the level from the main menu button. 

• Ai movement 

1.  The ai move to still ignores both the buildings and units when it comes to choosing he path to take when moving to its target location. I couldn't figure out how to fix this in time, but my guess would have to be I'm missing a setting that is needed to make spawned actors affect the nav mesh. 

2. There is also the problem that the units have a tenancy to keep slowly moving if more than one is selected and targeted to move to the same location. The first to the location stops and the rest slowly love around it until they get stuck on each other or get close enough to the target location.

• No pause menu

There wasn't enough time to create the pause Menu for the game, so there is no way to exit the game once the level has been started beyond the escape key and the task manager. I was planning on adding a pause menu if there was time, however I had already planned to do a lot and already had to cut a few things for time reasons.

• Video of the final product.

In the following video is a showcase of the various features I created for the FMP project. I thought having a visual representation of the above code would make it easier to understand.

 • Final notes on the video

I found recording the video difficult, this being because I lack confidence when it comes to talking about something I have done or created. I tried to record this video multiple times and this was the best attempt that I created.