Unreal Temple. COMP4905: Carleton Computer Science Honours Project

Transcription

1 Unreal Temple COMP4905: Carleton Computer Science Honours Project By: Nicholas Bowen Student ID: Supervisor: Lou Nel Supervisor Date: April 21 st

2 Abstract The goal of this project was to create a game using one of the mainstream game development engines, and have it playable on the Oculus Rift. The Rift is a virtual reality headset and is one of the leaders in virtual reality to date. Utilizing the Unreal Development Kit (UDK) and the Oculus UDK integration, available through the purchasing of the Oculus source development kit, I have made a game called Unreal Temple. This report will go over the rules and controls for this game, as well as a few setup instructions for setting up the UDK environment. I will then go over some of the lessons that I've learned and some future possible enhancements to the project that could be made. 2

3 Acknowledgements Much thanks to Oliver M-H, an online blogger who's tutorial on parallax occlusion mapping helped me a great deal. The blog can be found at 3

4 Table of contents 1.0 Introduction Game information Setup Input and motion controls Gameplay About the engine Setup Download Configuring the project Unrealscript coding environment Overview of the unrealscript in the project Useful tips for unrealscript Bringing Custom work into UDK Characters and weapons Materials and textures Sounds and Music Kismet Packaging the game Reflections What worked well What did not work well What would be done differently making the game again Possible enhancements for the future Conclusions

5 1 Introduction The game that was made for this project is called Unreal Temple. It was implemented through the Unreal Development Kit and is capable of being played on the Oculus Rift. The game is a first person shooter style of game in which the player navigates through the level to try to escape. They will find enemies along the way and must collect a couple items, and have to solve a couple of small puzzles. The Oculus Rift is very new technology that has only recently surfaced. They are one of the leaders in virtual reality, and after using their product, it becomes evident fairly quickly that virtual reality is the future of gaming. The technology isn't far behind this vision either. That being said there has not been much work done for the virtual reality devices and thus it became a pretty good idea to implement a game for this device as an Honours project. I knew early on that I wanted to use a development kit for the project as I did not possess the knowledge to do it on my own, and have it be anywhere near the quality that I desired. It then became a choice of a couple of the Oculus integrations that currently exist. I had tried to use Unity, another of the very well known engines, and quite liked it. The only problem was that to get Oculus working on that engine required a Pro version of Unity, which is very expensive. The Unreal Development Kit however was free, fairly easy to pick up and install. The only drawback was having to learn their scripting language (unrealscript), but it was certainly worth it. 5

6 2 Game Information 2.1 Setup The setup of the game is fairly straightforward. You must simply run the UDKInstall- UnrealTemple.exe file to run the installer. The installer will prompt you for an install location and you can provide it with any install directory you want. While running the game, you can elect to play with the Oculus Rift or without it. To toggle between the two it requires that you enter in a console command. To open up the console, hit the tilde button ( ` ) on the keyboard, and it will open up a black and green window. The command is 'stereo on' to go to Oculus mode, and 'stereo off' to go back to playing it normally. Note: This is assuming that the Rift is set up properly, which is covered in their documentation in a much more informed way than I could describe here. 2.2 Input setup and motion controls The keyboard setup for the game is as follows: Left mouse - Fire Scroll Wheel - Changing between weapons. W,A,S,D - Forward, strafe left, backward and strafe right respectively C - Crouch E - Push Buttons ESC - Pause Space bar - Jump. You can hit space again to perform a double jump (it must be hit again while you're going up and not whilst falling) The motion control for the head movement with the Rift will take a bit to get used to. You can turn your head left and right, and up and down to rotate the view. You can also tilt your 6

7 head and the view in game will tilt as well. The trick with the first person shooters is what to do with the crosshair while the user's head is bobbling around to look. It wouldn't be ideal for the crosshair to be stationary and therefore making the head the way to make small adjustments. The solution to that is having the cross hair have a bit of leeway to move around the screen, and therefore moving the mouse with small adjustments would not rotate the view as it would in the typical first person shooter. Instead the view only rotates with the mouse when the crosshair would touch the edge of the screen. The pitch cannot be controlled with the mouse however, make large adjustments up or down the user must look in that direction. 2.3 Gameplay The goal of Unreal Temple is to make it from the entrance, all the way to the exit of the temple. The player will start out with only one weapon, a pipe, and they must fight some enemies so that they can take weapons to use. There are 3 items in the game, the pipe, the Rifle and the Grapple gun. The rifle is the ranged gun of the game and it is what all of the other enemies use. It does not do as much damage as the pipe does, and has a low fire rate, but it can shoot enemies at any range. The last item is the grappling gun, it is used to grapple up to higher levels of the map to progress. The grappling gun cannot grapple on to just anything, it can only grapple on to one target: 7

8 These are highlighted by a bit of white light in the level so that the player can hopefully see them a bit clearer. The player will have to click a number of buttons in the level, a couple of which are to open doors, and there's another that will be explained further down. This is what the buttons look like: There are a couple of progression puzzles in the game that I'll explain here so that it's perfectly clear when encountering the two of them in the level. The first puzzle that the player will encounter is a breakable wall, to break it the player can hit it with their pipe or shoot it with their rifle. The next puzzle involves trying to get the enemies to step on a button for you that opens up a door. The following is that room: 8

9 The rock on the ground in the front is the pressure panel that will open up the door straight ahead. The trick is that when the player steps off that panel then the door closes. What you've got to do is push that button (the light right beside the door) and it will spawn enemies inside the crevices to the left and right, as seen in this screenshot. As the enemies run on that plate, the door will open, meaning that the player has to either kill an enemy on that plate so that the body keeps the door open, or run in through the door as the enemies are running passed it to get to you. The last puzzle has to do with a breakable floor that will only break if the player is falling fast enough when it touches it. The following is a screenshot illustrating the floor: 9

10 This is inside the crevice in the level. The player will get this message while landing on the floor while not going fast enough. The goal of this mechanic is to get the player to climb up as high as possible (and thus progressing through the dungeon), to then jump down and break the floor, they will then fall down into a pit of water which leads to the exit and the termination of the game. The end of the game is a bit abrupt for my liking. When you reach the end you'll see a message saying that you've escaped, in the same style as the one about the ground, and then the game will exit and stop completely. I didn't have time to make a main menu screen as it was not a huge priority with only one map, so the game just closes on exit. 10

11 3.0 - About the Engine The development engine that was used for this project was the Unreal development Kit. The kit is free for download for both non-oculus versions and for the Oculus versions. What the UDK does is provide a GUI layer between the user and the messy c++/directx and shader coding that goes on underneath everything. If changes are however needed to be made in that area of coding, it would require downloading the Unreal Engine. The engine itself costs $19 a month and then will take 5% of the game developer's gross revenue. This gives you access to the full set of tools, and the source code of the unreal engine. For my purposes, free was always better as I had to shell out a chunk of money to get the rift, meaning the free UDK was the way to go. 3.1 Setup The following section will describe the setting up the UDK for use of the creation of a new project, or the use of an existing one Download The version of the development kit that you've got to download is the version that is provided by the Oculus Rift. The reason for this is that there are some changes inside the script files, as well as some configuration changes that are made to make it possible to convert to Oculus viewing inside the games. The download can be found on the Oculus developer website ( The version that Oculus makes you download is the UDK from September They have since released UDK4, which Oculus does not seem to have followed up with yet. 11

12 3.1.2 Configuring your project There are a number of things that you must do to begin the level creation for a project of your own in UDK. The first thing to do is to create your own package, which will contain your materials, sounds and etc. The way to do this is through the UDK content browser. CTRL+SHIFT+F will open this up, or the button on the top toolbar between the binoculars and the green K. Once this is open, in the packages division on the bottom left, under new packages you'll see an Untitiled_* where the star is some number. This is a new package. Click on it, and you'll see the middle area becomes blank. Right click anywhere in there and create something new, nothing is going to be done with this new thing that's created, the sole purpose is to just get your map package saved so you've got a place to put new materials, sounds and etc. To save the package, right click on the Untitled_* and click save. This will bring up a file dialog to get you to save your package somewhere. When I had first made my project, I kept a separate folder outside of the UDKGame folder for my content, including map and package. It did not work because the engine would not look inside my folder when trying to find packages to bring into the level. I had elected to fix this by simply saving my new package inside the {UDK Install directory}/udkgame/content folder. This way the engine would always find it and I wouldn't get any cryptic errors that didn't make much sense. An example of the error you'd get would be: 12

13 Here the UDK is saying that it couldn't find your package, and then lists a bunch of resources that it cannot find (located in your package). I'd tried to get it working VIA the config changes, as presumably there is a property in there somewhere that dictates where is searched for packages to import but I couldn't get that working properly. Now that the package is saved it will be visible inside the content browser under that same Packages section. It will be under the UDKGame/Content folder. You are now free to import everything you need to bring into your game into that package. A new level can be created with File->New, then a level environment type selection will pop out. It doesn't matter where this level is saved. To bring an item or material in from your package, you just need to navigate to the package (UDKGame/Content) inside the content browser, click the item and then drag it in. There are constraints on what you can actually drag into the game, for example a material can only be dragged on to a surface, but that is the general method to getting an item from the package into the game. A quick note: To save the level, navigate to File->save current level. Do this very often, CTRL+S does not save as it does in every other type of file (not by default anyway). One thing that I've experienced with fairly often is crashes in the engine, some of which due to coding on my end, others I cannot explain. Sometimes the engine fights for control over DirectX so if there is something else running in the background that could be using DirectX and is conflicting with UDK then UDK might crash. Another thing that should be done is backing up the level. UDK is nice in the fact that there are auto saves but those get cleaned up after a while. If the engine has just crashed and there has not been a backup then navigate to {UDK install folder}/udkgame/autosaves. Here there is a list of all of the autosaves that have been created. The reason for the backing up is because I have run into my level becoming corrupt for no apparent reason. I was doing something completely normal and then my engine crashed. Each time I'd try to launch my map, the engine would crash. Luckily I had been saving backups as I go and only lost half a day of work but it was still disconcerting to know that it could happen for no reason. 13

14 3.2.0 Unrealscript coding environment The UDK uses its own scripting language to specify some interactions between things that are in the game. To get started with creating the scripts to go with the game that you have started making, a folder needs to be created that will house all of the unrealscripts that will be made. This folder location should be: {UDKInstall directory}/development/src/{project name}. Then inside that folder create a classes folder, and this is where all of the classes made will be stored. If the classes that are being made are extensions of the collection of UT classes, (UTGame, UTPawn, UTWeapon and etc.), then there are some specific configuration changes that need to be made. Regardless of whether or not the use of the UT classes is planned, the folder name of the project is required to be in the config files. The files to change are: DefaultEngineUDK.ini and DefaultEngine.ini. Inside these files there is a section called '[UnrealEd.EditorEngine]'. Within this section will be a bunch of key value pairs of '+EditPackages'. You must include the folder name as another key-value pair. In the case of Unreal Temple, the line '+EditPackages=UnrealTemple' needs to be added into both files. Now if the package you add has any dependencies on other packages, then those dependencies need to be declared before the package that depends on them. If the dependencies are after the package, then the package will not know about them and there will be some ugly compiler errors that are generated. The following is an occurrence of the error where this has occurred: Running: [C:\UDK\UDK \Binaries\Win32\UDK.com, make, -unattended, -debug] Init: Version: Init: Epic Internal: 0 Init: Compiled (32-bit): Sep :45:31 Init: Command line: -unattended -debug Init: Base directory: C:\UDK\UDK \Binaries\Win32\ Init: Character set: Unicode Log: Executing Class UnrealEd.MakeCommandlet Core - Debug Engine - Debug Package Engine changed, recompiling Warning, Failed to delete..\..\udkgame\script\onlinesubsystempc.u 14

15 Warning, Failed to delete..\..\udkgame\script\utgame.u Warning, Failed to delete..\..\udkgame\script\unrealtemple.u Warning, Failed to delete..\..\udkgame\script\utgamecontent.u Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\Engine.u' IpDrv - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\IpDrv.u' GFxUI - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\GFxUI.u' GameFramework - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\GameFramework.u' UnrealEd - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealEd.u' GFxUIEditor - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\GFxUIEditor.u' WinDrv - Debug Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\WinDrv.u' OnlineSubsystemPC - Debug Error, Could not load existing package file '..\..\UDKGame\Script\OnlineSubsystemPC.u'. Check the log file for more information. Compile aborted due to errors. Warning/Error Summary Error, Could not load existing package file '..\..\UDKGame\Script\OnlineSubsystemPC.u'. Check the log file for more information. Warning, Failed to delete..\..\udkgame\script\onlinesubsystempc.u Warning, Failed to delete..\..\udkgame\script\utgame.u Warning, Failed to delete..\..\udkgame\script\unrealtemple.u Warning, Failed to delete..\..\udkgame\script\utgamecontent.u Failure - 1 error(s), 4 warning(s) Execution of commandlet took: 3.97 seconds This error is a bit cryptic as it does not state explicitly that there was an error of dependencies or anything of the sort. The error log can vary a bit, therefore when examining the error, look for the Failed to delete ' ' as this would be a good indication that the packages are defined in the incorrect order. The problem is that this fix won't only happen once. Throughout my programming of unrealscript I've managed to get into the state of my packages being defined in the wrong order without changing the config files, and I'm not sure how it happened, so be prepared to have to make this change a few times. 15

16 One of the frustrating things about compiling unrealscript is that the editor itself cannot be launched when compiling the scripts. The reasoning being that it loads in all of the compiled scripts at launch time, therefore if you need to make a change to the scripts then the editor needs to be shut down. After long hours of coding, and you run into the compile error for the first time it will not be obvious at first at all. Here is the compile error that results in trying to compile the scripts with having the editor launched: Running: [C:\UDK\UDK \Binaries\Win32\UDK.com, make, -unattended, -debug] Init: Version: Init: Epic Internal: 0 Init: Compiled (32-bit): Sep :45:31 Init: Command line: -unattended -debug Init: Base directory: C:\UDK\UDK \Binaries\Win32\ Init: Character set: Unicode Log: Executing Class UnrealEd.MakeCommandlet Core - Debug Engine - Debug IpDrv - Debug GFxUI - Debug GameFramework - Debug UnrealEd - Debug GFxUIEditor - Debug WinDrv - Debug OnlineSubsystemPC - Debug OnlineSubsystemSteamworks - Debug SubstanceAir - Debug SubstanceAirEd - Debug UDKBase - Debug UTEditor - Debug UTGame - Debug UnrealTemple - Debug Package UnrealTemple changed, recompiling Warning, Failed to delete..\..\udkgame\script\unrealtemple.u Warning, Failed to delete..\..\udkgame\script\utgamecontent.u Analyzing... Scripts successfully compiled - saving package 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u' Warning, DeleteFile was unable to delete 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u', retrying... (GetLastE-r-r-o-r: 32) Error, Error deleting file 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u' (GetLastError: 32) Warning, DeleteFile was unable to delete 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u', retrying... (GetLastE-r-r-o-r: 32) Error, Error deleting file 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u' (GetLastError: 32) Error, Error saving '..\..\UDKGame\Script\UnrealTemple.u' Package saving failed. Warning/Error Summary 16

17 Error, Error deleting file 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u' (GetLastError: 32) Error, Error saving '..\..\UDKGame\Script\UnrealTemple.u' Warning, Failed to delete..\..\udkgame\script\unrealtemple.u Warning, Failed to delete..\..\udkgame\script\utgamecontent.u Warning, DeleteFile was unable to delete 'C:\UDK\UDK \Binaries\Win32\..\..\UDKGame\Script\UnrealTemple.u', retrying... (GetLastE-r-r-o-r: 32) Failure - 2 error(s), 3 warning(s) Execution of commandlet took: 3.44 seconds You train yourself to look for certain aspects of the errors to make the solving of them much easier. For myself, I had inadvertently trained myself to whenever I got an error to make sure that the editor was not launched. I had also noticed that the '2 error(s), 3 warning(s)' often signified that the editor was launched as it was a pretty unique combination of errors and warnings that happens consistently if the editor is launched at compilation time of the scripts. As for different editors to use, I have tried three in total. At the beginning I tried notepad++, as it has been my go to editor for some time now, and I figured that there must be a plugin for unrealscript. Sure enough there did exist such a plugin but the problem was that there was no auto complete, the syntax highlighting was a bit off and there was no way to search up the hierarchy of classes to try to find something without going to the file system and manually searching for it yourself. The next editor I used was Unrealscript Editor-X. It was definitely a step up from the Notepad editor, as the highlighting was all current and there was a minuscule amount of browsing up the hieararchy of classes. The problem was that there was still no good implementation of auto completion. The autocomplete would complete a function name but it would not fill in the parameters for you and it just became cumbersome after a while to try to still have to search through to find the function you are trying to call anyway just to see what parameters have to be passed into it. This led me to my most preferred editor in Eclipse. I had used eclipse for around four years now and I really should have tried to find an editor for it first as I have really enjoyed using it thus far. Sure enough there was an editor for it, complete with proper syntax highlighting, 17

18 complete hierarchy browsing capabilities and as well as a good auto complete that would not only complete function names but give the description of the function (if one was provided), auto complete variables inside the classes as well. All in all it was a great editor to use. The only gripe with it that I have is that each time you save a file, it recompiles the scripts. I impulsively save files whenever I make an addition to it and so there was a lot of recompiling. If you had edits in multiple files, and saved one of the ones that you were working on, it would not save all of them, so you'd have to go through and save and build for each of those files that you saved Brief overview of the Unrealscript In the project Everything in the game from an unrealscript point of view is considered an Actor. The characters inside the game that the and the AI controls are called Pawns. The pawn is responsible for handling the firing, managing it's own inventory, and etc. The pawns possess controllers, and the controllers are responsible for controlling the actions of the pawns. The player pawn(s) possesses a player controller, and each AI pawn will possess its own AIController. Each controller will also end up triggering the drawing of the heads up display( HUD ). For this project I extended the UTPlayercontroller functionality to add in my own drawing of the HUD, due to the fact that the default HUD didn't quite apply to what I was wanting to have for the project. I did not have as much data that I needed to display as the default Unreal Tournament HUD. I therefore had to create my own custom HUD class for drawing the information onto the screen. This also needed to be done because the current implementation of the HUD drawing didn't take into account the fact that the game could be in Oculus mode. In Oculus mode, the corners of the screen are often not visible to the player, and therefore the HUD information needs to be moved closer to the center of the screen. There is a static function that is provided inside the Engine class that has a check that looks at the current configuration to see if the 'stereo on' command has been sent, so it was just a matter of checking to see if that function returns true and then producing some offset for the HUD elements. 18

19 The weapons in the game are extensions of UTWeapon, as explained before. The major reason for this was because there wasn't any hugely substantial changes that needed to be made in those classes, just the fact that the grapple and pipe do not consume ammo. The weapons are responsible for the drawing of themselves on the screen, and this is handled in the SetPosition() function inside each weapon. The TempleMeleeWeapon (pipe) needed to override the UTWeapon position setting because the mesh that I had brought in required a different offset for when the game was in Rift mode. Each weapon is responsible for drawing it's own components on the HUD. In the case of this project, the only item that each of the weapons draw on the screen while equipped is the crosshair. This drawing occurs in the DrawHud() function, and this is the spot where custom hud elements could be added, such as a new crosshair or a new piece added onto the canvas. The grappling gun was the only weapon that required significant changes, and it's in the TempleWeapon_Grapple and the TempleProjectile_Grapple classes that contained the requirements for making the grappling work. The player can only fire one grapple shot at a time, and their movement, including mouse movement, is stopped for that time until the projectile hits something. If it hits the grapple target then it will let the pawn that fired the projectile know that it has hit the grapple target, and will then send that pawn into the grappling state. If the projectile hit something that is not the grapple target, then the pawn will be notified that it can exit the blocked movement state, and it can resume moving. The AI controllers are used to dictate how the bots in the game move and behave. I have two types of enemies in my game MeleeBots and RangedBots. They aren't very distinguishable, but are made in a way that they could be modified using different weapons, and thus different behaviour. At the moment, the distinction between the two are the fact that the MeleeBots have a home point, and when they see the player they will chase them, until the player is no longer visible, or there is not a path that is available to get to the player. After that they will return to their home point and face the direction that they were initially. The RangedBot will patrol between two points, and if it sees the player then it will follow him as long as there's a path to the player. If the bot cannot reach the player, or it stops seeing them, it will return to patrolling those two points. Both of these bots use the rifle weapon. Even though the MeleeBot's name would 19

20 suggest otherwise, it too uses the ranged weapon. The reason for this is that there were already animations for the character for firing weapons, but there aren't any for swinging a melee weapon. I'm not knowledgeable enough in the area of animations and so I decided that my plan was if I had some time at the end of the project then I'd try to add the actual melee weapon. Inside the RangedBot class at the top there are the variable declarations. When a variable declaration takes this form: var(behaviour) name StartingState; var(patrol) int PatrolPointId1; var(patrol) int PatrolPointId2; then it means that these variables are available inside the UDK. The name inside the parentheses are the category inside the object properties that the variable will be listed. This will create an effect shown below for a RangedBot placed in the level: The starting state and two patrol points are passed through to the unrealscript code. The patrol point ids refer to two patrol points that are located somewhere on the level. These two points are what the ranged bot will roam between. The reason that I was dealing with IDs of 20

21 patrol points, and not the objects themselves is because I could not figure out a way to get the object from inside UDK, and pass it along to the unrealscript code. It did not seem possible to accomplish this task, therefore I created an ID that the patrol point would possess, and then when the bot is going to go to a patrol id, it can loop through all of the patrol points in the world and find the patrol point that has that id, giving the code access to the object. The navigation of the AIs are done through what's called the NavMesh, or Navigation mesh. To build this mesh in the level, pylons are used. Pylons essentially create an area, and build all of the paths along surfaces for that area, creating a mesh of navigation possibilities that travel around the obstacles inside the mesh. The controllers for the Ranged and melee bots will attempt to find the current navigation mesh that they are inside, and then it will generate a path to their next target, whether it is the player or the next patrol point Useful tips for Unrealscript There are a couple of things that I wish that I knew upon starting the unrealscripting experience. First of which is a method of searching through the entirety of a certain type of class in the world. For example, I could search through ever patrol point, checking their IDs to find the point. The following is a code snippet doing just that: ForEach WorldInfo.AllNavigationPoints( class 'PatrolPoint', P ) { } if(p.id == tosearch) { currentpatrolid = P.id; return P; } This is looping through all of the navigation points (PatrolPoint is a subclass of navigation point), looking for an id that is predetermined, and then returning when it's found. Note that it is looping through all of the navigation points, if it is not a navigation point that is being searched for then calling WorldInfo.AllActors(...) is the way to go to accomplish that. 21

22 The next tip would be how to log in unrealscript. While trying to figure out the way that everything flowed, I would stick log statements everywhere because there are no debuggers for unrealscripting. The log statement is: `log( Stringstring... $variable); I however only learned recently that you can chain multiple variables in the log statement. Before I thought that it was only possible to write one variable per log statement, and that would lead me to having multiple lines of log statements just for writing two variables into the log. The following is an example as to how you can write multiple variables: `log( Variable one: $ variable1 $, variable 2: $ variable2) Another tidbit that was useful for me was that it was possible to tell what called a function by using a special keyword in unrealscript called Instigator. This held the class that called the current function. The reason that this was useful was that it helped me figure some of the more tricky concepts came to happen in unrealscript. The feature I spent the longest trying to figure out was how the firing happened because I was trying to see if it was feasible to implement my own weapon firing. The instigator is also useful for callback functions. The last tip that would be useful is getting the reference to an item in the content browser into unrealscript. Right click on the item in the content browser, and then click the Get full name. This will generate a textual reference to the item in question, which can then be put into the unrealscript. For example: SkeletalMesh = SkeletalMesh'UnrealTempleResources.PipeWithBone' This is a reference to the skeletal mesh of the pipe, inside the UnrealTempleResource package with the name of PipeWithBone. 22

23 3.3 Bringing in your own work into UDK Characters and weapons There are a number of different modelling tools that can be used to create your own characters and weapons and import them into the game. The one that I had used to create my pipe weapon was 3ds Max (from This software is free if you go and sign up on the Autodesk site and specify that you're a student. One very important thing note this software, and something that I had run into a vast amount of trouble with, is the version that you need to install. The issue is that the file format that you import the model and animations with is a bit finicky in comparison with the UDK version. The format in question is the FBX format, which is the format that UDK requires you to import. The version of UDK that was installed from Oculus required an FBX version that was of a version that was not the newest to date. This meant that the version of 3ds Max that I had installed (the latest 2014 version) was not actually going to be able to work since it used the newest version of creating FBX files. I had tried all of the other exporting options to try to get it to work but UDK was very set in needing the 2012 version of FBX. The version of 3ds max that ended up working for me was the 2013 version as it used the 2012 version of the FBX plugin, and thus I was finally able to export the animations properly. I had begun to explore Blender as a modeller to try to get the FBX problem fixed, it was fairly similair in how you do things as in 3ds max, it was also free, but I was still not able to solve the problem. It is definitely another alternative to 3ds max if for some reason it is not possible to obtain 3ds max for free from Autodesk. There are a couple things to keep in mind if you're going to be extending from the current functionality provided in the UT framework instead of making your own firing mechanisms (for weapons specifically). Again, Unreal Temple extends from UT. This means that 23

24 you have to add in some specific animation names to the weapon. You need these animations (the file names need to be exactly as follows) : WeaponFire, WeaponEquip, WeaponIdle, WeaponPutDown. These are the four default animations that are used by the class UTWeapon. If it is not desired to extend from UTWeapon, then it is possible to make up different animation names, and use them in conjunction with your extension. For the purpose of this project, it was far more efficient to just extend from UTWeapon, as I had wasted a great deal of time trying to get the animations to be seamless on my end. It would have been possible to get it working a bit more efficiently if I tried again at this point, but just starting out there's not much reason to do something different, as you can just override the functionality that is not desired from UTWeapon while keeping the animations aspect working properly. I did not create any of my own characters because I did not have the skillset, patience or the time to create them, with their own materials and animations, so the rest of the explanation is going to be directed at weapons. Once the mesh and the animations are created, they are ready to be imported into UDK. Navigate to your package in the content browser, and then you can right click anywhere in the browsing area of the package and select import. You can then browse to your mesh and then click okay and go through. The mesh will then be visible inside the content browser, it will however not have any animations uploaded to it because they need to be imported separately into an animation set. 24

25 To create an animation set right click anywhere in the browser for the package and click create new Anim Set. You will be taken to a screen that looks like this: The first thing to do is to select your mesh for the Skeletal Mesh dropdown. Then go to the Anim tab, and select the AnimSet that you just created, it should take the form of {AnimSetName}[0], the zero meaning that there has been no animations imported for the mesh. With your animation set, go to file, 'Import FBX animation', then you should be able to go and select each of your animations (the WeaponFire, WeaponEquip, WeaponIdle, and WeaponPutDown). After those animations have been imported you should be able to click the play button with each animation selected and see the animation play in the editor. The final piece is to add in a socket location for the weapon. What this socket does is enables the code to have this spot as a point of reference for the gun to be attached on to the pawn inside the game. Again, if you're extending the current UT framework like this project is, then you have to create a socket with a specific name. In this case the name of the socket has to be WeaponPoint. Then when you end up creating the weapon inside the unrealscript code, it will 25

26 use that point on the weapon to attach to a corresponding point on the pawn Importing materials and textures To import materials into UDK to apply them to surfaces, they must first be imported as images. Gimp is a great, and free image tool that can do a great number of tasks, and it was very valuable on the creation of textures front. It can be downloaded from The textures, for whatever reason, need to be in a resolution that is a power of 2. Upon opening your image in gimp, you must first scale it, and then export it as some file with a resolution that's a power of 2. The image format that I have been using for UDK is the png format. After the image is converted, import it the same way that has been done before. Once the image is imported (it should be shown as a texture now), it will still not be able to be dragged onto a surface. This is because it has to be made into a material. To create a new material, right click on the texture and then select create new material. The material screen will open up, it looks like this: 26

27 I won't go into this fully, to move an individual node, click on it, hold down control and then it can be moved around the screen. This tool is essentially deciding how the material will interact with the light and other attributes with of the world. Connecting the black dot to the diffuse will mean that each pixel of the texture is affected by the diffuse light, and this will allow the texture to show up on the material. This tool is in a way an abstraction of the type of work that you would implement in shader code. There are quite a bit of features that can be implemented with it, including bump mapping and parallax occlusion mapping. There will be a bit more discussed about this when the bump mapping is talked about. The material can now be placed onto surfaces in the world Importing sounds and music into UDK To import sounds into UDK, sound or music file needs to be in the WAV format. Import the sound like any other import that has been done, and then there will be a SoundWaveNode created. SoundWave nodes can be placed in the level as ambient sounds. If it is not an ambient sound, but a sound that is needed for a weapon firing, character taking damage, or etc, a sound cue needs to be created. Sound cues can also be triggered inside unrealscript. To create a sound cue from a SoundWaveNode, right click and hit new Sound Cue. This screen will pop up: 27

28 Then go back to the SoundWaveNode that was imported and drag it into to this window. After it has been dragged in, drag the black dot from that speaker and connect it to the node that was brought in. This will allow the use of this sound cue from unrealscript, and from various other parts of the UDK that can use the sound cues. 3.3 Kismet Kismet is another means of defining interactions between objects and actors inside the map. Along with Kismet is an example of a Matinee, which is essentially a scripted set of actions that occurs. There are a variety of uses of Kismet, anywhere from the entirety of the AI functionality being defined in it, to ending the game from touching a trigger. For Unreal Temple, any button that was in the level had its behaviour controlled in Kismet, as well as the action that followed, such as a door opening or a sound playing and etc. I also used Kismet to handle my bots spawning at the touch of a button inside the room at the bottom of the level. Kismet also works hand in hand with matinees to control all of my elevators inside of the level. I had thought about using it for my bot functionality as well but I wanted more hands on control of the bots. 28

29 Another tremendously useful thing about Kismet is that you have ability to create your own nodes that can handle functionality that is very specific to your game such as ending it in a specific way. I also created my own node to setup the controller of my spawned bots. I needed to do this because I needed to set the home patrol point of the bots that I spawned so that when they could no longer see the player, they would go to back to that spot. I won't go into much more detail about that because the process is self explanatory after looking at one of the nodes, the SetupController provides a great example of how that works. 3.4 Packaging the Game The UDK comes with its own installer builder called UnrealFrontEnd located inside the binaries folder of the UDK installation. It has a few quirks in trying to get it to run perfectly however. First of which being that there are some configuration changes that need to be made in order to get the installer building with your own game class (as opposed to the default UDKGame that is imposed). The first set of changes to be made are in the DefaultGameUDK.ini file. This file is what the other config files will be based off of upon config loading (if new configuration files need to be generated). Under [Engine.GameInfo], the following lines need to be inserted: [Engine.GameInfo] DefaultGame=UnrealTemple.TempleGame DefaultServerGame=UnrealTemple.TempleGame PlayerControllerClassName=UnrealTemple.TemplePlayerController DefaultGameType="UnrealTemple.TempleGame"; This is telling the engine that our default game type for this game is the TempleGame class, the default player controller class is TemplePlayerController and the default game type is still TempleGame. The UnrealTemple part of UnrealTemple.TempleGame signifies the folder name in which the unrealscript classes are stored. That same change needs to be made inside the DefaultGame.ini file, switching out the DefaultGame, DefaultServerGame, 29

30 PlayerControllerClassName and the DefaultGameType properties. The other piece that needs to be changed inside this file has to do with the default map prefixes, again under [Engine.GameInfo]. The following line needs to be inserted: +DefaultMapPrefixes=(Prefix="Unreal",bUsesCommonPackage=FALSE,GameType="UnrealTemple.TempleGame") This line is saying that for every map that begins with Unreal, we're going to use the game type of UnrealTemple.TempleGame. There are a couple settings that can be changed inside the UDKSystemSettings.ini file. The most important change in here would be forcing the game to run in fullscreen mode from the start, otherwise if the player switches to Oculus mode, it wouldn't be in full screen and the Oculus would not be usable. The property is called Fullscreen and it needs to be set to true. There are a couple of other visual quality settings that could be turned up if it is desired. The settings I'd recommend for starters would be the MaxAnisotropy, MaxMultiSamples. Turning these two up should increase the visual quality of the game, with a small hit on performance (for Unreal Temple scale of game). The final setting to change is inside the DefaultEngine.ini file. Inside the [URL] block there are a couple properties called Map and Local map. These settings should be the name of the map that you are going to be cooking with the game. The property is telling the program what map to look for when it first launches. Typically it would look for UDKFrontEndMap.udk, which is the main menu, but since I didn't make a main menu separate for this project it seems more appropriate to send the player directly into the game. 30

31 To get started on building the map, you must first add it in the maps to cook. Clicking on add will bring up a list of maps that are able to be added, this is where it is required to have the map located inside the {UDK install director}/udkgame/content/maps folder. If it is not in that folder then it will not show up in the list and the map will not be able to be added. If the map was not in the correct folder, and it was moved from some location inside where the other map was visible, then there might be an error that pops up, talking about an ambiguous package name. To rectify this simply rename the map that was just moved into the UDKGame folder. If you rename the map, then it is crucial that you remember to rename the property mentioned above inside the DefaultEngine.ini class. If it is not renamed then the game will crash on startup because it cannot find the map that it's supposed to load on startup. 31

32 After the map is added then then it is time to do a full recompile of the scripts, and then a clean and full recook, and then disable the cooking step inside the pipeline at the top. The reason that it is necessary to do the cooking separately from the building of the installer is because when it is done inside the pipeline, for no good reason, the game will crash on startup. I have no idea why that happens, only that it does and that it took a very long time to try to figure out what was going on because as usual the error that occurred was fairly cryptic and not all that useful. After the full recook then you can hit the start button and the packaging will be on the way. The game will launch if that step has not been disabled, which is no big deal if it isn't. After you close down the game there will just be a few more steps to getting the installer set up. These steps are fairly straight forward. At the end of the process the install file will be created in the UDK install folder. Run that.exe file and it will launch the installer for the game. If for any reason there are errors after installation of the game, there is a log directory that can be examined to try to figure out the reason why it's not installing or running properly. The directory is located at {Install folder}/udkgame/logs/. Typically it's the Launch_2 logs that provide the detail on what went wrong on the launch, but both logs should be examined to be sure. 32

33 4 Reflections 4.1 What worked well There are a number of things that I felt like succeeded in this project. The first of which is just a general observation with making levels; The immersion of the level was enhanced greatly when the all of the aesthetics were added in to the level. This is most likely true for any game ever created, but as I had never truly made a game from start to completion, it was great to see it in action. The lighting in my opinion was what gave the greatest contribution to the immersion of the level. This leads me to the next success which was using some lighting tricks to hide some of the mediocre textures in the level. For example, in the very large room, those four walls use one texture, and it's only one iteration of the texture up the entire wall. The fact that it isn't lit all the way up allowed the player to not see this small flaw, while still having a high quality look about them. Another instance of this is the room in which you must spawn enemies. The ceiling in the room was a failed attempt at parallax occlusion mapping (similair to relief mapping, where you provide a texture to the material and a few other effects to try to real bumps in the material). I had elected to have that room fairly dark so that the ceiling couldn't be seen perfectly and reveal the flawed attempt. What I had tried before the parallax occlusion mapping was the use of bump mapping. Bump mapping provides the material with the illusion of depth of bumps with the use of a normal map of the texture. To generate the normal map, I used a plugin that I found for Gimp, that allowed the creation and modification of normal maps. In conjunction with the lighting, the bump mapping was able to add in some great depth some parts of the level even though it was terribly blocky, and minimal textures were used. Here is an example of what the level like without the bump mapping: 33

34 The walls have the illusion of depths while still being flat and non jagged. Here is the material without the bump mapping: 34