Fundamental Game Systems Implemented in Unreal Engine 4 For Use With or Without Oculus Rift

Transcription

1 Fundamental Game Systems Implemented in Unreal Engine 4 For Use With or Without Oculus Rift Documentation of an Honours Project for Carleton University Comp 4905 Written by Matthew Imtiaz for Wilf LaLonde In this document I will provide detailed documentation and instruction for the things I ve learned and accomplished during the semester using Unreal Engine 4 and Oculus Rift. I ve properly implemented a good number of foundational gameplay systems in the industry leading engine, adhering to my primary goal: to keep my systems extensible. The act of their implementation included a great deal of research, much more than I had originally anticipated, as many lessons required follow-up debugging. The most important lessons this project taught me were not limited to the engine and its functionality; I also learned a great deal about game and level design workflow, and how to tackle the daunting task of learning a new commercial engine and API without guidance. Doing this while adhering to guidelines for creating a comfortable virtual reality experience was the challenge I faced, and successfully overcame. 1

2 Contents Design Choices & Rational... 4 Blueprint & C++ Interactions... 5 Setup and Extensibility... 5 Creating a C++ class from the editor... 6 How C++ and Blueprint Scripting Interact... 6 The Player Character... 8 Components... 8 Event Handlers... 9 Tick... 9 Open/Close Menu Interact With Selected Objects Item Interaction Selecting Objects Introducing Multiple Outline Colors Player Inventory The User Interface Adding Objects to Player s Inventory Interacting With the Inventory Equipping Items Loot Loot Spawner Containers Gold Pickup Items Scene Design Modular Design Landscape Texturing Foliage Lighting Post Processing Level Creation Landscape Holes AI

3 AI Pawn Setup Behaviour Tree Nav Mesh Bounds Networking Setting up a Networked Game Instance Complexities of Replication Conclusion & Next Steps Research

4 Design Choices & Rational After much consideration earlier in the year, I chose to pursue a project making a game for Oculus Rift. The technology is new, and accordingly, any content published that harnesses the virtual reality platform garners a great deal of attention compared to non-virtual reality content of the same quality. I plan to use the game systems I have created in this project as the basis for an indie game. I plan to continue to add and improve upon these systems over the next 6 months, and hope to have an entry to submit to the Oculus Rift developers website. Eventually I also plan to put the project on Steam and KickStarter, with a low funding goal, in the hopes of shipping my first game. I chose to use Unreal Engine 4 (UE4) for many reasons, most of which can be summed up as wanting to spend as much time on content creation as possible, as oppose to implementing engine features. UE4 provides an excellent array of tools and features for developers to use, as well as a low cost point of $20 per month. The Blueprint scripting allows me to easily create advanced systems without having to do much (if any) research into the engine s API. If I find the scripting does not meet my needs at any point, I can code what I need in C++ through use of UE4 s heavily documented API. Paramount in what drove my decision to use UE4 was its plugin for native Oculus Rift support. With the basic functionality of the Oculus Rift included in the engine, I was free to focus my attention on designing gameplay systems around the technology, instead of spending time coding the hardware itself. Throughout the process design choices have been made that adhere to the Oculus Rift Guide of Best Practices in order to provide a smooth, comfortable virtual reality experience. If these practices are ignored, virtual reality can lead to eyestrain, disorientation, or even nausea. In an emerging medium such as Oculus rift, it is these design choices that have the biggest effect, and distinguish one virtual reality experience from another. Learning these guidelines is imperative to creating a successful game on the Oculus Rift platform, and UE4 was an effective educational tool in doing so. I ve included the guideline in the Research section, but as it is very thorough (~50 pages) I won t go into detail about specific items it teaches. My focus of this report will be documenting the systems that I have successfully created over the last 4 months. In doing so I will provide instruction for how a reader would reproduce my work. The documentation is detailed enough that it should not require any previous experience using UE4, therefore this document will be very useful in educating new members of my team to my project. 4

5 Blueprint & C++ Interactions Setup and Extensibility To create an Unreal Engine 4 project for use with C++, create a code project from the Unreal Engine Launcher, with either some basic pre-existing tools implemented, or a blank project, as seen in Figure 1. The launcher is available with an account on the Unreal Engine website. With a paid account you can also access the engine s source code on GitHub. To run the engine from code you must be running Visual studio 2013, and it cannot be the express version. Figure 1 Selecting the proper platform and compile mode of the project, as in Figure 2, is also important. According to Epic s programming tutorial, the main difference is choosing between runtime speed and debug-ability where development is the most highly-optimized, but least debug-able, and debug is least optimized but provides the most debug options. Figure 2 5

6 Creating a C++ class from the editor The editor is now being run from visual studio, and can be accessed by going back to that project in visual studio, or from the Unreal Engine launcher. From the menu, choosing Add Code to Project will allow you to choose a class from which to extend from, to be added to the visual studio project. Figure 3 How C++ and Blueprint Scripting Interact When defining classes in C++, you set how they function within the engine. The way the class interacts with the engine and editor is controlled by the flags set by the UCLASS macro, as seen in Figure 4. Figure 4 6

7 In Figure 4, you can see I added a meta-tag BlueprintSpawnableComponent in UCLASS which allows me to create and place them as components when working with the class in blueprint scripts as shown in Figure 5, along with the various other pre-existing components that can be added to an actor class. Figure 5 Blueprint scripts can call C++ functions if the proper flags are set in the definition of the function, such as BlueprintCallable as shown in Figure 4. The term _Implementation must also be appended to the function name in the source file, as seen in Figure 6, but not in the header file, as the matching function definition is seen in Figure 4. Figure 6 C++ functions can also enact blueprint scripts, to do this a dummy C++ function would be created, but with the BlueprintNativeEvent property. This means the function is allowed to be overwritten by a blueprint script, thus any call to the function would enact the script written in blueprint instead. Now if any C++ function calls that dummy C++ function, the blueprint script will be enacted instead. It is important to note that at this point I m unsure about the order of execution: I do not know if the entire blueprint script would be run before the next line of C++ code is run, this would require testing. This can simply be avoided by making any calls to blueprint scripts be last to execute in C++ functions. 7

8 The Player Character Components For my player character, I have my own implementation of a class extending from an example character in the template for first-person-shooters. This template character comes with some movement aspects already setup, such as the input controller, turning speed, and camera component. In the list of components in Figure 7 you can see all of these components, as well as some others I have added. The large red sphere is a collection sphere, used as a larger radius to check collision with power-ups to be picked up. I implemented this in C++ and prevented it from being overridden in blueprint scripts by adding the BlueprintReadOnly flag, as seen in Figure 8. Figure 7 Figure 8 The other components I added were done through the editor/blueprints, the menu components, a point light, and a post-processing component. The post-processing just allows certain post-processing attributes to be accessible from within the character s blueprint, which was necessary in order to adjust the outline color of objects based on what the player is selecting, and will be required for additional effects in the future. The point light is simply a light radius around the player that can get larger or smaller based on items he/she has equipped, and the menu components I will explain in the User Interface section. 8

9 Event Handlers Moving onto the logic inside the character, I have set up the main event graph to act as an eventdispatcher, shown as Figure 9. The gameplay events are received here and sent to the appropriate handlers, I will discuss each. The events currently handled are: the tick; the open/close menu button (the i key); interacting with highlighted objected (right-click); and damage being received. The damage events have very basic functionality at the moment, and simply reduce the player s health by some float passed into the event. The other events I will detail in full. Figure 9 Tick Firstly, let s examine the tick functionality, zoomed in for detail in Figure 10, which is the basis for all of the player s interaction with the world. I will go into more detail on the FocusSelectedObject and UnfocusAll functions in the User Interface section, for now I ll just describe the functionality of the player character s tick. 9

10 Figure 10 On every tick, a ray cast is done from the center of the player s viewport. The ray cast is set to a different collision channel (ChannelToCheck) based on whether or not the menu is open. Two custom collision channels were created to do this, Pickups and Menu, which is done from the project settings menu as seen in Figure 11. This allows the ray casting to only collide with objects that are assigned to the corresponding channel. This means this mechanism can be used for interacting with the menu when it s open, or selecting objects in the game world when the menu is closed. 10 Figure 11 Open/Close Menu Opening and closing the menu toggles between the 2 collision channels for the ray cast in the tick function, and in turn controls what the player can interact with. When the button is pressed to open/close the menu, the IsMenuOpen boolean is properly modified to represent its state, and the menu visibility and ChannelToCheck is set accordingly, as seen in Figure 12.

11 Figure 12 Interact With Selected Objects Next I ll explain how the function InteractWithSelectedObjects is handled. First a check is done to see if any valid object is selected, and if so, we then check to see what type of object this is be performing casts on it, as shown in Figure 13. There are currently 3 types of interactions scripted: picking up gold, picking up items, and opening chests. Figure 13 11

12 The HandleInteraction_ItemPickup is the most complex of these 3 player interactions, as it involves dealing with the player s inventory array. I will go into detail on the inventory system in the Player Inventory section. The player s interaction with containers/chests is the simplest one, and simply calls the OpenContainer function on the selected chest (Figure 14). The logic of this will be examined in detail in the Containers section. Figure 14 The handler for gold pickups is shown in Figure 15. It simply adds the gold amount from the pickup to the player s amount, and deletes and deselects the gold that was picked up. It also displays a debug message saying some amount of gold was picked up. Figure 15 12

13 Item Interaction Selecting Objects It was necessary to be able to discern exactly what items were being selected when using the Oculus Rift. The most intuitive way of doing this was to show the selected object with an outline. Every part of the currently selected object will be outlined when the player s ray cast is colliding with it, even if the object has multiple pieces, as in Figure 16. Figure 16 This is done using the post-processing shaders of UE4. To modify the default post-processing, a Post Process Volume from the Volumes tool, as seen in Figure 17, should be placed into the level. Figure 17 This will affect everything inside of the volume, unless the Unbound attribute is set to true, as seen in Figure 18, in which case it will affect the entire level it is placed into. We then need to create our custom post processing effect, as we are not just adjusting the pre-existing effects in the details panel, but making our own. To add our own effect, we need to create a blendable (a post-processing material) and add it to the list of blendables, as shown in Figure

14 Figure 18 Figure 19 To create this blendable, a new material should be created in the Content Browser tab (Figure 20), and in its properties, the Material Domain should be set to Post Process, as shown in Figure

15 Figure 20 Figure 21 The scripting area of the material dictates how it functions. For my outline effect I used the technique that was demonstrated in the tutorial videos I purchased. It offsets the object a slight distance in each of the 4 screen space directions, multiplies this with a given color (the outline color), and then returns this as the emissive color, resulting in an outline drawn over the object in the final scene. The script for this effect is shown in Figure

16 Figure 22 There was also a jittering effect after it was implemented. Research led me to some information about the G-Buffer, and explained how the stuttering look to the lines was a result of the temporal-anti- Aliasing (all research links are in the Research section at the end). This was averted by moving the post processing effect to a different spot in the rendering pipeline, by changing the Blendable Location attribute shown in Figure 23, from After Tonemapping to Before Tonemapping. Figure 23 This process uses the Render Custom Depth option that must be enabled on objects. Thus I can easily turn this effect on or off simply by toggling that boolean on the objects. I set this in the GainedFocus and LostFocus functions seen all the way back in Figure 6, so an object is highlighted in an outline color only when it is under the player s crosshair. Unreal Engine s documentation for this is very helpful. 16

17 Introducing Multiple Outline Colors To distinguish between object types, such as containers and item-pickups, I needed to be able to control what color was input into this post processing effect, and change it during run time. To do this a MaterialParameterCollection is necessary. This is an asset that can be referenced globally in materials. To begin, create one in the Content Browser (as shown in Figure 24), and then add the necessary variables that need to be accessible. Figure 24 Figure 25 Now, in my player character class I have created a function called ChangeHighlightColor (Figure 26) which takes a vector (a color) and enacts the script SetVectorParameterValue. This allows you to take a material collection, choose an attribute from it, and set that attribute. 17

18 Figure 26 I now have a function in the player that controls the outline color in the material parameter collection. To use this in the shader where I need it, I create a Collection Parameter node in the shader, then in its attributes, choose my collection and the parameter I want to access. Figure 27 shows what the creation of this looks like, while the shader in Figure 22 shows the node in use and driving the effect s color. Figure 27 Finally, the implementation of this system is wrapped up by the FocusSelectedObject function found in the tick event (Figure 10). This is called once the player has focused his/her crosshair on a new object. Casts are used to determine what object is selected, and the outline color is changed accordingly, as seen in Figure 28. In this function, the GainedFocus C++ function is called, which is defined in Figure 6. We now have a very useful highlighting system which we have a great deal of control over. Figure 28 18

19 Player Inventory The User Interface Figure 29 Designing a user interface that was accessible to players both on a monitor or using the Oculus Rift headset began as a challenge. All of the existing APIs, including Slate, UE4 s primary UI library, involved detaching camera control from the mouse to allow for typical traversal through menus. As players using the Oculus Rift will be using controllers to play, and pointer control with a joystick is typically very cumbersome, I knew the menus had to be traversable with the Oculus Rift, and the control for keyboard + mouse would have to fall in place after that. My resulting design is as follows: when the inventory button is pressed, this cube of menu objects that surrounds the player will become visible. These menu objects remain in place allowing the player to rotate to interact with the ones he/she needs. In the future the player will be able to rotate this cube of menu components as to not need to turn the character to access different parts of the menu. The idea is conceptually equal to that of the menu system in Zelda: Ocarina of Time, shown in Figure 29. When the player presses pause, the cube rises around the player and fades in from transparency. The player can interact with the parts in front of him/her, and press buttons to rotate the cube allowing access to different menus. The player s components are shown in Figure 30, with the appropriate components (all menu objects) selected in the component list. Pictures of my implementation in-game are seen in Figure 30 and Figure 31. Keep in mind the work I did was on the implementation of the system, with only minimal visual attention, mostly just what is necessary to see the system working. I have had people test out this system of interfacing with their inventory and it has received good feedback, and feels natural. 19

20 Figure 30 What is important to note about the setup of the player class s components, is the hierarchy of the menu components. All menu components share the same root, MenuComponents. This is a Scene Component, an invisible dummy component used for organization. Each of one these Scene Components serves as a root for a group of visible components: InventoryMeshGroup holds all the inventory slots as children (a visual representation of the actual Inventory array), EquipMeshGroup holds the slots that represent equipped items, and MenuLabelGroup holds the selected slot, and text labels. I can easily show or hide the entire menu by setting MenuComponents to visible or invisible, and have it propagate to its children, or do the same with individual menu groups. Figure 31 20

21 Figure 32 Adding Objects to Player s Inventory To explain the functionality, I ll begin with the event of a player trying to pick up an item. When the object the player is trying to interact with has been identified as a pickup item, shown in Figure 13, the function HandleInteraction_ItemPickup is called. It is this function that would check requirements for picking up an item (such as inventory space, quest status, etc.), and then places this item in the player s inventory. Currently it does not check any requirements, and just attempts to place it into the player s inventory. The definition for this function is shown in Figure 33. An array of InventoryItems is checked to find the first empty position. If an empty position has been found, an instance of the class InventoryItem is created, with its model set to that of the item being picked up. The AttachItemToSlot function is then called, which is shown as Figure Figure 33

22 Figure 34 Interacting With the Inventory With the inventory open, the player can right-click on inventory slots that have items in them to move them from slot to slot, or to put them in the equip slots, the left-hand or right-hand as shown in Figure 32. The inventory slots are also highlighted with a red outline when highlighted, and when clickedon/selected, are displayed in the upper-left of the inventory in a selected slot (Figure 35). 22 Figure 35

23 The logic for these interactions started simple but ended up going through a few iterations to become the extensible system I have now. The system is also very readable in its blueprint script form, Figure 36 shows a zoomed out, complete picture of the current InteractWithSelectedObject function. Figure 36 The green comment blocks indicate success at an execution branch (essentially an if-statement), and the red comment blocks indicate failure at an execution branch. With the comments I ve added over blocks of nodes (mostly looping over arrays and accessing indices which don t merit further detail) it is easy to follow the flow of control, the blue comment blocks at the end just indicate the outcome of each logic path. Also, not all control paths are complete: currently the player can only pick items up from slots and place them into empty slots, trying to swap an item in-place with another will not work. Equipping Items If we look at the function for handling item interactions (Figure 33), we can see that it only checks and places items into the inventory array, not into the EquipSlots. These will undergo different checks than the normal inventory slots, and represent the items a player has equipped. Currently there is no combat system in place, so equipping items has no effect on the player at this point; but the system is in place. The next steps with this system are to read attributes and modifiers from the items and use them to modify player stats, such as health or strength. What is preventing me from doing this next step at this point, is my lack of design for how I want weapon modifiers to work. It is not as simple as, giving the sword some attributes, such as health, strength and energy, and only having values above 0 for the attributes the sword actually has. In the end there will be a large selection of modifiers that can be applied to various items (see Research section for examples). My plan from here includes making a modifier class, where I can attach as many as I want to an item, to change the damage or attack speed, or give an item various special effects. I have a bit more research to do in creating this class properly: one that will only exist when attached to an item, but properly accessible to the necessary blueprints. The modifiers from every item equipped to the player would then be easily combined and applied to the player. 23

24 Loot Loot Spawner When an enemy dies at any given location, or when a chest is opened or barrel is broken, an instance of the LootSpawner class is created. The main advantage of having a separate class to handle loot spawning is that it will handle spawning loot wherever and whenever I need it in the game. On creation, the LootSpawner generates a random number and runs through a probability tree to decide what loot should be spawned. This essentially acts as a global function, as the result is the same script being run, regardless of where in code I create the LootSpawner. For now I only control the items dropped through use of float parameter called tier, which currently just changes the amount of items that spawn, but in the future will also act as a system to ensure that high level items drop solely in high level areas. The LootSpawner has a small chance to spawn a trap, otherwise it follows the flow control through the green block shown in Figure 37, where it has the chance to spawn gold and items. Figure 37 The GoldSpawn and ItemSpawn functions are identical except for the actual object that is spawned. At this point the only item is a sword, so there is no logic deciding between object types to be spawned. In both functions there is simply a probability tree, as shown in Figure 38, that determines the amount of items to spawn. Once the number has been decided, it spawns the item and propels it away from the spawn location, to clear the radius of the chest it may spawn in. 24

25 Figure 38 The trap spawn is in a simpler state, shown in Figure 39. All the function does is spawn the only trap that is implemented at the moment, an explosion that does damage, and a fire that persists after that, which currently does no damage. Figure 39 Containers There are a few points of interest to the way a container class works, its logic shown in Figure 40. Currently, it is the only object that handles its own interaction; when a player tries to interact with a container, it calls the OnOpenContainer event. This allows each container to handle its own opening animation, and accordingly, how long to delay the spawning of loot. 25

26 Figure 40 Figure 41 shows a close up of the actions that take place when this chest is first opened. A LootSpawner is created, then a timeline is started. A timeline allows a designer to visualize the function they need and set the timing/bounds of said function, as shown in Figure 42. This particular timeline feeds back a value between 0 and 1 over the course of two seconds. This value is put into a rotational linear interpreter, which results in the smooth application of the specified rotation. This is a very useful tool in animating game objects, and has many other uses in performing time-based actions. Figure 41 26

27 Figure 42 For container class objects, the GainedFocus and LostFocus events are currently overridden in blueprint script. As shown in Figure 43, allowing access to do this means we can easily propagate the functionality to all the object s children, in this case, the lid of the chest. Gold Figure Figure 44

28 As gold is the most common item in the game, I constructed the class in a way that would help avoid it looking repetitive. The class currently consists of mesh 14 components, each the child of the one preceding it. I then placed these mesh components on top of each other in a realistic looking pile. The result is that I can select piece 10, then hide it and its children, removing the top portion of the gold pile (making it look smaller). I can do this with any individual mesh piece, giving me an easy way to create a multiple variations with virtually no effort. The construction script for the GoldPickup class is shown in Figure 44, and 3 pictures depicting how the tiered mesh components work are shown as Figure 45, Figure 46, and Figure 47, with the top piece selected each time for clarity. Figure 45 Figure Figure 47

29 Due to this tiered approach, the GainedFocus and LostFocus must also be overridden, similar to the Container class, as the attribute change must propagate to all children. Pickup Items The only pickup that is currently implemented is the sword. On its creation it randomly chooses between 2 available sword models. Eventually every weapon and armor type will be its own class. Scene Design To construct my first scene, shown in Figure 48, I followed the tutorials from a professional Unreal Engine level designer (website is referenced in the Research section). This allowed me to have a great deal of starter content from which to begin to construct my level. The only lesson to be gained from this was the concepts of proper design and lighting using the tools that UE4 offers. As such, there were a lot of internal systems already in place in his project, so all the gameplay systems I implemented were done in a separate project, and this one was solely for constructing a scene. 29 Figure 48 Modular Design By designing smaller modular meshes that can be quickly snapped together in the editor, such as Figure 49, larger composite models can quickly be created and iterated on. Using this process the overall speed in which a scene can be created is greatly increased, avoiding complex 3D modelling. Attention must be taken to match the imported object sizes with multiples of the grid-snap size that is set in the engine, so

30 that these models can be quickly arranged together. Depending on the planned material/texture for the mesh/model, care must also be taken when setting the proper UV coordinates on the model before importing to UE4, as to avoid textures being misaligned, as seen in Figure 50. Figure 49 Figure 50 Landscape A landscape in the context of Unreal Engine 4 is a tiled heightmap. To create a landscape one must be created from the tools menu, the mountain button will access the landscape features, and the New Landscape button will create a new one (Figure 51). From here a few options can be adjusted during its creation, such as number of tiles and the resolution of each tile. The engine offers basic terraforming 30

31 tools, shown in Figure 52, and provides designers and artists with the abilities necessary to create and shape landscapes. Each of the tools has a few adjustable properties, such as the size, strength, and shape of the brush. A scene can produce a very polished look simply by using the sculpt and smooth tools alone. Figure 51 Figure 52 Texturing After the landscape is shaped, it must be textured using the paint brush (Figure 53). There are brushes that can blend textures onto it in the same fashion as the sculpting tools, with various size and strength properties. These textures are set up in the landscape material shader, using something called a landscape layer with a weighted priority. This means on any given vertex, the textures on that vertex have a weight for each, which all add up to The heavier the weight of a texture the more visible it is compared to the others on the same vertex, allowing for a realistic blend between the textures. This material is setup using nodes called LandscapeLayerWeights, which simply allows for the proper communication between the landscape texturing tool and the different textures in landscape material. Figure 54 is an example terrain material from the professional tutorial s lessons. 31

32 Figure 53 Figure 54 32

33 Foliage The foliage painter is a very effective, simple to use tool to improve the look of a scene. Any mesh can be dragged into the Meshes area, as shown in Figure 55, which the tool can then paint across different surfaces, using the specified parameters such as random rotation or Z-offset (height). The foliage tool uses batch rendering, thus the performance cost is insignificant for simple meshes. Figure 55 33

34 Lighting Figure 56 The lighting shapes are all found in the Lights menu, as shown in Figure 56. Lighting is what gives a scene the punch it needs to wow players. Knowing how and when to use the proper lighting types available in UE4 is very beneficial to creating a visually appealing scene while keeping performance costs at a minimum. UE4 has 3 classes of lights: Static, Stationary, and Movable, which are detailed in Figure 57. Figure 57 Lighting has the single greatest effect on a scene, and as such the right class of light need to be employed in the proper situations to have the greatest visual impact while maintaining a small performance footprint. Knowing when to use what shape of light is also imperative, as in Figure 58. Despite the large spotlight on the building, the area around the light would be dim without the point light in the same position. When done properly, lighting can be done very efficiently: the spotlight will be a stationary light, as it casts shadows and is a critical light source of the scene, while the point light is a simple static light and only serves to light up the building around it. 34

35 Figure 58 The lighting should be placed into a scene after its main components have been constructed. The professional tutorial I followed instructed me to be generous with static lights (Figure 59), as they are tremendously cheap. Figure 59 35

36 Post Processing Post processing is the final step to creating a scene, and is accessed by placing a Post Process Volume into the level from the Volumes menu, as shown in Figure 60. The post processing will only be applied to the area the volume encompasses, unless the unbound attribute is checked, as seen in Figure 18, which applies the effect to the whole level. The default post processing attributes include a large selection of options, as shown in Figure 61, such tint and color mixers to control color tones, control over shadows and highlights to fine tune contrast, grain, bloom, lens flares, and a wealth of other options that are too numerous to list. I have just played around with the bloom and color correction to find a good visual style that suits the scene. By using post processing volumes it is also easy to make one environment exist next to another that has a completely separate visual style. Figure 60 Figure 61 36

37 Level Creation Landscape Holes Pivotal to my level creation process is the ability to apply landscape holes using the landscape visibility tool (Figure 62). Similar to painting textures onto the surface of a landscape, this tool paints transparency, thus both the visible and physical elements that are painted on will be removed, allowing caves to be created, shown in Figure 63 and Figure 64. Figure 62 37

38 Figure 63 Figure 64 Once this hole exists in the landscape, a blueprint script can randomly choose between hiding it with a boulder or creating a new landscape and dungeon underneath (as in Figure 65), where it can then be extended and painted, and so on. Figure 66 is a completed version of a dungeon entrance. 38

39 Figure 65 Figure 66 Overall, I have a few variations of an outdoor area, with visibility masks in different areas. On loading one of them is chosen at random, then the locations of where the dungeons will be created are chosen from the available visibility holes. At these locations a dungeon is then generated using a selection of assets from a dungeon tileset, and my maze generation algorithm shown in Figure XXX. This spawns a dungeon maze piece by piece until the requested size is reached, and then fills any doorways left open with rooms or walls, creating a full dungeon. The long orange lines in the center of the script show the transform being sent to the appropriate dungeon-tile being spawned. 39

40 Figure 67 AI Unlike all of the other material I have detailed so far in this document, the AI and its behaviour tree is not something I would be able to reproduce without following the explicit directions again. As such, I ll discuss my knowledge and experience with the system, but to properly reconstruct the functionality I have, I recommend following the tutorial provided in the Research section, as my direct instructions may not be successful. AI Pawn Setup I currently have a simple implementation of an AI bot in the game. At this point the bots just run toward the player and stop when they reach him/her. There were a few steps involved in properly implementing this, and it ended up being somewhat of a complicated process. As my player character is an extension of the first-person template character, it was apparently lacking something or some things that would allow it to act as a bot. To circumvent this, I had to import a third-person-character template from a different project. I believe the controller (the class that handles movement of the character) for the first-person character was missing some necessary attributes. At this point in time I haven t located the difference that allowed one character template to work but not the other, but I am comfortable in the fact that I have a working bot and behaviour tree, with the ability to add new behaviours. 40

41 Behaviour Tree The exact steps for creating AI with an accompanying behaviour tree involve many classes: an AIController to control its movement, an AICharacter to represent it in the world, a BlackBoardDataAsset to store information shared between bots to be accessed by their behaviour trees, and finally the BehaviourTree itself to store a behaviour hierarchy. After these classes are created each of the behaviours must also be created, extended from the BTTask_BlueprintBase class. These are called behaviour tree tasks (BTTs). All of these classes must also interact with each other in a specific way, otherwise the AI will have no behaviour whatsoever. For example, the AICharacter must have the AIController as its controller, the behaviour tree must reference the BlackBoardDataAsset, and all the BTTs must be added to the behaviour tree, as in Figure 68. In addition to this, AIModule needs to be added to PublicDependencyModuleNames in the build file, as shown in Figure 69. Figure Figure 69

42 Nav Mesh Bounds Once the bot has been created and the behaviour tree has been set up, the area that a bot can move within must be defined. To do this we use a NavMeshBoundsVolume, from the Volumes tools (Figure 70). Figure 70 Figure 71 In Figure 71 we can see I ve encompassed the entrance to this dungeon in a NavMeshBoundsVolume, which allows bots to freely traverse from the inner landscape to the outdoor one, meaning enemies will chase the player out of the cave. I can place several of my bots and they will all chase me when I am inside the nav mesh, shown in Figure XXX. 42 Figure 72

43 Networking Setting up a Networked Game Instance Setting up a test instance of a networked game is a simple process in UE4. If running from the editor, next to the play button there is a dropdown menu that will allow you to choose the number of clients to run, and whether or not 1 will be a dedicated server. If the number of clients is more than 1, one of these will be the authority/server for the session. 43 Figure 73 Complexities of Replication I originally underestimated the complexity of the networking system in UE4. Although connecting to a multiplayer game instance is a straightforward process, the actual logic of which function calls to replicate on which machines is a very complex process. Essentially it involves detecting who has network authority, and executing certain logic based on this, but complexities have already arisen. For instance, when a chest is opened by a player, that event is not shared between players, therefore all other players will still view that chest as closed. The main areas of gameplay replication according the UE4 documentation are actor replication, variable replication, and event/function replication. We must decide which events are important enough to distribute across the network to the players in the game. This is the stage I am currently at. After the

44 proper replication of actors, variables, and events is achieved, attention is then placed on relevancy. This is summed up by the UE4 documentation as how to handle the case where an Actor was irrelevant and then becomes relevant. To properly test the suitable networking playability, the proper method of managing replication and relevancy in UE4 must be practiced. At this point I have only implemented the basic networking functionality. In a game the server and client players both have a label over their head indicating their authority, and bots currently always run toward the authority. however the accurate shared view of a chest opening and loot spawning is not currently complete. Conclusion & Next Steps I feel that I have made a great deal of progress over this semester, and learned a wealth of knowledge about UE4 and its workflow. I also feel I ve picked up many skills that are independent of the specific tools I used this semester, such as proper placement of lighting in a scene. The game is not far off from being something playable at this point. I simply need to add an enemy channel to the player s ray cast so that he/she can target and damage enemies, and then start adding in abilities and cool ways to kill said enemies. With the player damage and inventory system in place, as well as a system for spawning proper loot, I am very close to the point I hoped to be in at the end of the semester. Unreal Engine 4 continues to impress me, and I aim to continue to use it to develop my first game to be shipped. 44

45 Research Unreal Engine main website UE4 Introduction to C++ UCLASS Macros tml UFUNCTION Macros x.html Material Parameter Collections ml Post-Processing Materials & Blendables ndex.html Diablo 2 Item Modifier List Landscape Material Landscape Layers and Visibility/Opacity Mask Oculus Rift Guideline of Best Practices AI and Behaviour Trees in UE4 Networking and Replication in UE 45