•Overview 

Unreal is a free to use software that is used for multiple purposes, but for this instance is going to be used to make games. This software is primarily used to create the actual game mechanics and world/levels and had no model creation facilities (which is why blender is used). 

 • Layout

• Default interface 

The default interface is what you see when first opening unreal engine, the following options are available:

1.  These are default options that come with most programs including new, open save, ext.

2.  Contains the shortcut to some of the standard tools required to use in unreal. (Further explained later.)

3.  This is the viewport that the project can be both seen and edited in.

4.  This is the projects "content drawer", this shows what assets are in the current project.

5.  Contains several important tools such as ""command console", "output log",  ext.

6.  Displays the hierarchy of you projects assets.

7.  Show details of currently selected asset.

• Default interface (2 Expanded.)

The default interface is what you see when first opening unreal engine, the following options are available:

1.  This is a save icon, allows for quick saving of a project without having to go through the default menus shown above. (1 in previous section)

2.  This option contains several options including "selection mode" as well as several other i have yet to use or learn about.

3. This section contains several buttons that do the following from left to right:

• This is the "get content" menu that has sections for importing external assists known as "get content",  a section for basic actors" and a section for "recently" added.

• This option contains several options relating to the current projects "blueprints", which are a feature of unreal that takes the place of traditional programming to run the projects functions .

• The last option in this section contains relating to "level sequence".

4.  These buttons allow for a simulation of the current project to be run, in terms of game making this means you can play through your game as is without having first compiled it fully. This allows for you to make changes rapidly and makes testing changes much easier then normal, as it allows for Realtime feedback on changes.

5.  This section shows a list of options based on what platforms you currently have access to develop for.

6.  This "settings" menu has various options for the setting of the "world" and plugins in the project.

• Default interface (4 Expanded.)

The "content browser" is the location that store all the assets used in the project, it mostly works as a "drag and drop" interface that  

• Default interface (6 Expanded.)

The "Outliner" contains all assets currently in the level, and allows for order and rename them for easier interaction. This allows you not only to find specific items without finding them in manually in the 3d view port it also allows for grouping items by importance. 

• Default interface (7 Expanded.)

The "details" menu contains all the setting for the currently selected item, this can be anything from location, rotation and scale to mobility setting and physics.

•Coding/Blueprints

Following are most of the diffrent types of variables that can be used.

•Basic functions

• Trigger boxes

A trigger box is an invisible item that can be placed in the gaming world, it provides an area that will "trigger" certain events to happen when a given item(s)/character(s) enter its location. 

• Placing a Trigger box

Placing a trigger box is done by done by opening the "get content" menu (as seen below) and in the "place actors" section opening the sub-menu "basic" and selecting the "trigger box option.  

• Creating a basic blueprint for a trigger box 

Creating the functions for a blueprint requires you to open the "level blueprint", this can be found in the "world bluprints menu as seen below:

• Blueprint window

This is the window that opens when you select "open level blueprint", it is where the main core of the games programming is made using unreal engines blueprints.

• Trigger box interaction

This event is used to detect an actor interacting with a trigger box.

• Cast to

This event allows you to get a reference for a character.

• Reference to character

This picture shows how to find a "reference to an actor" specifically the "bp_enemy".

• Setting location of enemy

The following shows the above "reference to character" along with the the target actor, this still requires one more part as seen bellow to actually set the target location.

• Where enemy is to be located

This has the final part that is added, this additional part shows where the enemy will be located when the trigger box is activate

 • Lights

Lights can be added into unreal and there are several versions of lights that can be added to a project including directional, point spot rect(tangle) and sky lights.

• Directional lights

A directional light is basically unreal engine version of a sun, this can be used to simulate different times of day.

• Point 

A point lights emits light evenly in a 360 degree radius

• Spot 

focussed in one direction

• rect(angle)

Similar to spot but square shaped

• Sky Lights

A sky light is the lighting system in unreal engine helps death with the brightness of shadows in the scene

set visibility

• Lights in my project

My game is inside a mansion and as such my main lighting is going to be the mansions lighting, this will be mostly provided my spot lights. During the game the monster will show up, this will start disabling the mansions lights and you will have a spotlight over the character that shows a minimal area around yourself. There will however be a torch available in the level that can be used to see properly, this will also be required to beat the monster. 

• Game project

 • Overview 

Here is a video and of the "game" I designed to practice unreal engine along with screenshots of the code used on make specific parts work. There is also a few images of the blueprints created for the game along with  a brief description on how it works.

 • OBS Recording

Here is a link to the a video the bellow if was created from (game recording.mp4) along with a lower quality gif below.

 • Blueprint

 Following are a couple mechanics used in the above example, they are "door", "key" and "light" (flashlight and main lights) mechanics. 

• Door

The following is the blueprint for the door, this is the overall blueprint, I will breakdown the blueprint with more in-depth information on other images. It is designed to create the movement for a traditional swigging door, it also contains a section for locking/unlocking the door if necessary. There where several issues making the door work, these will be explained in more depth when I get around to the section in question.

•  Door inside

The following image shows the part of the door(blueprint) code that is activated when the door is approached from the "inside", starting at the "on actor begin overlap" following the white line. Firstly the combination of  "on actor begin overlap" and "Cast to"(targeting the "player character") functions work in tandem to detect when the player first enters the doors inside hit box, it then proceeds to check if "B-doorLocked"(Boolean) is true or false. If "B-doorLocked"(Boolean) is true, then the door is locked and the game proceeds to print a message to the command console but if its false then the door is unlocked and proceeds further into the blueprint. The next section checks "B-doorActive"(Boolean) if true the code end doing nothing but if false sets "B-doorActive"(Boolean) to true then continues with the code. Following on from checking if the code can be activated the next step sets both "B-doorLocationA"(float) and "B-doorLocationB", (float) these used later in the code to make sure the door opens in a direction away from the character.

•  Door Outside

The following image is of the code(blueprint) that is activated when the character interacts with he doors "outside" hitbox, although this looks almost identical to the "Door inside" code it has subtly different yet important differences. The first main difference is that both are activated with different hitboxes, the next is that when "B-doorLocationA"(float) and "B-doorLocationB"(float) are set they have to set a different value so the the door opens away from the character, if left the same as inside the door would open towards the character. Thye rest of the code is almost a carbon copy of "Door inside".

•  Door Open

The following image shows the section of code(blueprint) that controls the doors opening rotation, it follows from both the above blueprint sections as it has both connected to its "timeline". The timeline will "start from the beginning every time it gets an update from either of the above sections (Door inside and/or Door Outside) it attempts to provide a rotation value to a "set actor rotation blueprint". The code intercepts this rotation value and alters it using both "B-doorLocationA"(float) and "B-doorLocationB"(float) so they open in the desired direction, both these floats being set earlier in the code(blueprint). One of the last notable things is the "set actor rotation blueprint" uses the "B-Door" object as its target, this can be changed to affect other doors although several other parts to the code would need updating. The final thing that happens in this code(blueprint) block is that once the "timeline" finishes it goes on to a section of code similar to this that tries to reverse the doors rotation rhus closing it.

•  Door Close 

This image shows the final section relating to the door code(blueprint) this like the above (Door Open) controls the doors rotation, just in an attempt to close the door. This part starts with a delay, this is so that the character has time to go through the door without getting stuck on it. After the delay the the the code(blueprint) then sets "B-doorLocationA"(float) to "B-doorCurrent's"(Rotator) "x" value, it then sets "B-doorLocationB"(float) to the desired "closed" position. The next section of the code(blueprint) works in a similar way to the "Door Open" code in the fact the timeline sets a smooth rotation that gets altered my the doors "B-doorLocationA"(float) and "B-doorLocationB"(float) variables. The final important part of this section of code is that it sets the "B-doorActive"(Boolean) that was set back in "Door inside" and "Door Outside" to false otherwise you would only be able open the door once.

• Door issues/bugs

There was several issue getting the door to work as intended, the fact being that the door still has minor bugs that I couldn't sort out. Following is a breakdown of issues I had to resolve making the code, then a section of bugs that still persist.

•  Resolved issues

1) When I first created the doors I placed the initial setting of "B-doorLocationA"(float) and "B-doorLocationB"(float) after the "B-DoorTimelineA"(timeline) this caused issues where the door would rotate normally if the trigger box was only activated once but would rotate in unintended ways if activated mutiple times. 

The way this was resolved was to placed the above mentions floats before the timeline, as and additional backup there was also "B-doorActive"(Boolean) that was created to prevent multiple activations from messing with the doors rotation until the current activation is complete. (this was added much later in making the code however)

2) If the door rotation was interrupted the door would end up stopping at a random rotation values, resulting the door remaining in an open position that was unintended. This could result in the door clipping into the wall, character and sometimes knocking over other objects, this was a problem as it ment when the trigger boxes where activated again it could cause more collision problems.

How this was resolved was to create the whole section for "Door Close" section as it wasn't a simple fix. This was also the same time that the "B-doorActive"(Boolean) was created and linked to other areas if the code(blueprint) and not only helped here but in several other issues. I was when I also leaned that you could get the current rotation value of an object, until this point I was using hard coded values (90 and -90) and thus "B-doorCurrent"(Rotator) was created to store the doors current rotation values. As previously stated those changes in tandem helped reduce the issue, there is still a few that will be explained later.

3) Both door hitboxes originally had there own separate code blocks, as above they can be seen join to the same timeline ordinally they both had separate but almost identical code(blueprint) blocks. (minus the fact they have different data stored in theirs variables) This caused the door to have a "snapping issue" where due to two septate hitboxes being activated when going trough the door would cause the rotation to attempt to happen from two location causing the snapping issue.

This was one of the main reasons for the creation "B-doorActive"(Boolean) so that this kind of issue wouldn't it happen again.

•  Persistent issues (Known of bug still in game)

1) The player can still cause the doors animation to to snap to different locations if the trigger boxes are activated at very specific times, however unlike above they tend to snap to one of two location and then proceed to close to the intended location.

2) There is a bug that prevents the door from opening, this happens if the player stays in a trigger box and lets the door close. They can then walk up to and touch the door but it wont open, at least not until you leave the location of the door and come back.

• Final note for the Door

You may notice that the "B-doorCurrent"(Rotator) is mentioned and used in multiple locations but not set at any point in the doors code.(blueprint) This is because its set in a different block of code(blueprint) and will be explained in the section labelled "Game tick" functions. As seen above this code had more errors then the rest as it was my first area of code to be worked on as such it was mostly down to not knowing how blueprints worked.

• Key

The following image of the key code(blueprint) a shows the basic set up for the key mechanic, this is relatively simple as it only really needed to do one thing. That being setting "B-doorLocked"(Boolean) to false, so the associated door can open.

•  Picking up key

Just like the door this starts at a "on actor begin overlap" combined with "cast to"(targeting the "player character") to make sure the character is close enough to the key in order to pick it up, it then proceeds to check if the key has been picked up already (by using a "branch"(if) with "B-keyFound" as its target) if it returns true the code does nothing. If the code however returns false, then it continues to "print" a message to the console. After printing the message the code then proceeds to set "B-doorLocked"(Boolean) to false and "B-keyFound"(Boolean) to true. It then moves the keys location by using a "set actor location" function (with the object "B-key" as its target) to set the keys location to an area out of bounds.

• Final note for the Key

Although this key code works fine as is, there wasn't any real issues with getting the code of the key to work as I had figured out a lot through the trial and error of making the door code beforehand. Although there was no errors in creating the key as its a simple code change, there are several parts to the code I later realised wasn't needed as it could be done another way but ran out of time to update it. This being the "B-key" branch that checks of the "key" has been found, I later found out when creating the flashlight that you can link items together and have them both move when the parent does so this section of code wouldn't be needed if I had updated that part. Another one being that I still don't know how to "despawn" objects, I would have done this instead of moving it.

• Getting flashlight

The flashlight just like the key seems simple enough in its code(blueprint) this is because a lot of the functionality for the flashlight had to be connected to another "function" as it required "event tick" that apparently can only be used once. The flashlight starts just like the key as a in game "pick-up", all this code really does is to set the variables for the flashlight. It does however do one more thing, it swaps the "visibility" of the characters and the torches light sources.

•  Picking up flashlight

Just like the other code(blueprint) blocks, this one also starts with a "on actor begin overlap" combined with "cast to"(targeting the "player character") just like the key this is to make sure you close enough to the object before it can be picked up. The code(blueprint) then proceeds to set "GB-flashlight"(Boolean) to true and at the same time setting the "visibility" of a "spotlight" attached to the flashlight to true. (this makes the light show up in the game only once the flashlight had been picked up.) Lastly the "visibility" of two "point lights" that follow the character is set to false. (this is because they no longer needed when you have the flashlight.)

• Flashlight issues/bugs

There was a large amount of issues concerning the flashlight, from the location, rotation and scale not properly being updated to not properly following the character. There are several others but they will be explained bellow.  

•  Resolved issues

1) Originally when I attempted to make the flashlight a "pickup", it would rotate to face the some direction as the player, it would also follow the player but wouldn't stay in front of them.(the blueprint for this is found in the "event ticks" section and explained more there) For example if you pick it up then it tun 180 degrees it would be behind you but he light would still shine in the right direction for the way your facing.

The way this was resolved was to remove most functionality of the flashlight and add those removed functions to another blueprint, that up to this point was only used to get current location of the in-game "doors" using "game ticks" (explained later) then adding an "empty" (a cube with "visibility" set to false) to anchor the flashlight to. This will be fither explained in the "game tick" section.

•  Persistent issues (Known of bug still in game

1) The flashlight cant be aimed up, ran out of time to figure out how to make it aim up.

• Final note for the flashlight

 A lot more work was required on the implementation of the flashlight then was expected and as such caused other things to need to be left out of the project due to lack of time. There was also issue in trying to do thing in a more complex way then I had the knowledge of and instead decided to use a simpler workaround, it might not be a perfect fix but it worked.

• Main lights

The main lights have a really basic code(blueprint) block, its added on to the blueprint for the "guest bedroom" key. The reason for this being that it was unnecessary to make a completely different block of code to make the lights turn off when it was intended to happen right after that key was picked up.

•  Turning off the main lights

There's nit much to say for the "main lights" as from the "on actor begin overlap" to the "set actor location" everything is practically the same as the "key" example from above, the only real difference being that after the "set actor location" the code(blueprint) carries on. The new part uses the "set visibility" function to simultaneously turn 22 light off.

• Final note for the Main lights

 Just like the "key" code(blueprint) block this one didn't really have any "bugs" as its not that complicated and the learning of how it works was done during the creation of the "flashlights" code(blueprint) block.

• Event tick

The following is a collection of functions that had to use the "event tick" as part of their functionality but you can only have one of per "blueprint". There are parts that relate to the door, lights that follow the player and the flashlights functionality. The reason these functions need the "event tick" is that they all need updating each in-game tick.

•  Door event ticks

The event tick code(blueprint) block starts by setting all "door current"(Rotator) values to their related "doors" current rotation, this uses the "get actor rotation" (with the related door as its target) then sets a relevant "door current"(Rotator) to the retrieved value.

•  Main Light event ticks

This section of the code(blueprint) block gets the location of the character and uses "set actor location" along with some "math nodes" on order to place two lights above the character head. That is why there is two similarly set up "set actor" layouts, one is for a "strong" light sources and the other a weaker one. The main reason for them following the character is to make it so you can see when the lights go out, they don't have a great range as its only supposed to light up the area directly surrounding the character.

•  Flashlight event ticks.

This section of the code(blueprint) block is what was originally a part of the flashlight code(blueprint) but was moved here because it needed to be done every tick, not just once. What this does it checks for the "GB-flashlight"(Boolean) if its true then it proceeds use "cast to", (with object "get player pawn") it does this because it need to get the location of an "empty" (as explained above in the "flashlight issues/bugs" is just a box with its "visibility" set to false ) that was added to the characters "pawn".  It then uses the location of this "empty" as the "new location" for the "set actor location and rotation" function, it also gets the player characters rotation values and uses them for the "new rotation" value for the previously stated function. With all that it just makes the flashlight move with the character while remaining in a location and rotation on screen. 

• Event ticks issues/bugs

The original reason for this code(blueprint) block was to set the "doorCurrent"(Rotator) for each door to the correct value ever in-game tick, it then evolved to contain more things that required the "game tick" for proper functionality such as the doors and moving lights. So there was a fair few issues with this section, ranging from missing items to faulty code.

•  Resolved issues

1) Like stated in the "flashlight issues/bugs" section the flashlight was not following the character properly, staying a fixed distance away from the character but not rotating around them.

This was fixed my moving the code here, not only was this so the flashlight would move with the character as it was intended to but also to get other important information every tick. 

•  Persistent issues (Known of bug still in game)

1) Just like mentioned in "flashlight issues/bugs" none of the fixes attempted here helped with the fact the flashlight wont aim up or down.

• Final note for the Event ticks

There is several issues that issues that arose that required this code(blueprint) block to be made, as well as several that came about because of it. This section was required as several key functions required some variables to be updated "live" (per "game tick") to work properly, this was difficult as its one thing I have never had to do before. The main issues came when sorting out the flashlight, several false leads where tried including using "bones". I couldn't figure out what what going wrong with the "bones" way of doing things, so I reverted to a way I knew of doing it with another program, by making an "empty" (already explained above) and this forked fine.