For simplicity's sake, we've only used static meshes in this example, but we'll soon include more advanced components. Prefabs keep a record of whenever a property is altered when used in the editor, so you can edit one prefab and not worry about how it will affect the rest of them. Alternatively, you can carry the change you just made to one prefab and apply it to all of them across the scene as well. This is both a time and labor saving process, so give it a try yourself. Let's spice things up a bit by adding some subtle particle effects to it.
Getting ready We only need to open up the prefab we just made, as we'll be building off of that. This will be an easy recipe; we're only going to drag-and-drop a particle effect onto our prefab, and combine the results. It's easy to create or edit particles on your own, but that isn't covered in the scope of this book. The content browser is where we'll begin most of our recipes in this chapter, as it offers easy access to all of our in-game assets.
Let's begin by opening that. You'll have to be careful when using particles, as they are costly in terms of computing overhead and can quickly bog down your system if too many are on screen at once. Align the particles in front of the pipe, so that it is nearly overlapping with the water.
We want to create an effect to appear as though there is hot steam radiating from the front of the pipe. Adjust the scale of the particle accordingly. Be sure to save your changes again. The content browser allows us to easily add components to our prefab by simply searching for it within the browser, and dragging it into a map. Selecting our prefab and an additional component at the same time allows the two or more items to be connected, and in turn, part of the prefab from then on. Mix and match some particle effects until you find some that really work for you.
Although it's beyond the stretch of this tutorial, spending some time with the particle editor can really add a sense, so that you have some trickling water to the pipe. Just be sure to take it easy when adding too many particles as overdoing it can quickly bog down a system due to the intense load on the CPU.
We've got all of the visual aesthetics for our prefab in place, but it's still not very believable within the game because we don't hear any sound coming from it. Let's change that. The changes here will be minor, but similar to what we've done with the particles in the previous recipe. UDK offers extensive audio capabilities, but those are over the scope of this tutorial, so we won't cover them here, but you can find a number of resources at the Unreal Development Network site, 1.
Drag it into the scene and align it closely with the other objects for our leaking pipe. Align the sound cue beneath the pipe. When you hit the PIE button, you'll notice that the sound gradually decreases as you move further from the pipe as well. Just as before, the content browser offers quite a bit of value to our level designer, as it allows him or her to quickly parse through our library of assets and drag content onto our map. Prefabs can be created at any point when we select two or more components at the same time.
See also Try adding some water beneath the piping, so that your stream is flowing into a pool of water. How do you think the sound of the water would change? See if you can find an appropriate sound cue for water splashing against another water source. Creating a PointLight archetype Archetypes and prefabs share a number of similarities, but most noticeably in that we use them to create instances of an object. All instances of an archetype on a map will update when an archetype is stored in a package, and that's one of the convenient reasons for using them.
Furthermore, if you chose to only alter an instance of an archetype, then the rest of those on the map will remain the same! So you have both ends of the spectrum, all within one tool. Archetypes also allow us to create physical representations of our code, to be manipulated and edited within the UDK editor, and later used in the game itself. Archetypes are different from prefabs in three distinct ways: ff ff ff Prefabs can be composed of archetypes Prefabs can contain sequences Kismet Prefabs preserve and translate object references within the prefab In the editor, archetypes are represented as placeable items, much like how classes are placeable resources.
Archetypes are often thought of as "script less classes", in that their purpose is to provide a way for designers to drop an actor that uses a set of default property values, which are different from the actor's class defaults. They also appear in the content browser, and provide the same functionality as any other resource type.
By default, the scripts and classes you write for UDK will appear in the Actor Classes tab, adjacent to the Classes Browser tab in the editor. By converting our classes to archetypes we can visually edit properties for these classes, thereby allowing for changes on the fly, instead of constantly having to change code in the IDE, rebuild, and then view our changes in the editor.
To have a better understanding of how archetypes work within the editor in UDK visit Chapter 2 To streamline the prototyping process and eliminate clutter from archetypes, we'll also be hiding certain properties from the level designer. Alternatively, we can expose new variables as well and organize them within categories.
This allows us to remove properties that generally wouldn't be beneficial or of any use to a level designer. If your designer ever wanted more control over an archetype, it is as simple as changing one line of code. Getting ready We'll begin by loading the map that contains our example archetype. Much like our prefab, this will allow you to see the various components used to create one, as well as teach you to create one of your own. To get things started, let's open up a new DefaultMap under the Tutorials folder. Since the development kit offers a plethora of excellent and professional assets available to us, we'll use these for most of our recipes.
Open the Actor Classes tab, and left-click on Lights to open the pull-down list. Right-click on PointLight to bring up the Create Archetype Left-click on Create Archetype With that selected, press F4 to bring up its properties. You now have a new instance of a PointLight archetype, which you can use as a template for future lights in your game. We have quite a few properties exposed here though, and things look a bit cluttered. Our level designer probably won't need access to all of these things, such as the static mesh actor, collision, and debug.
It is only a light, after all. Let's head back to our IDE and make a brief change to the class. Save your package by right-clicking on your folder marked Tutorial in your content browser. Close the editor and use your IDE to create a new class. We're going to extend from the PointLight class, as we've just used it in the editor, and it seemed to fit our needs. We've got our class created, but now we need to hide some properties from the editor.
Be careful to note, however, that you must remove the semicolon after extends PointLight, otherwise you'll receive an error. With this done, we can now head back to the editor and create a new archetype. Save your class and open the UDK editor. Use the same naming scheme as we had used before, so that it overwrites the one we've previously made, as we won't be needing it anymore. Drag your new archetype into the map and press F4 to bring up its properties again.
You'll immediately notice that many of those properties that were cluttering our screen before are now gone! Let's continue by altering some values. Let's adjust our light so that it emits a red glow. Under the light gray colored Light Component tab, select the indented, dark gray colored Light Component tab. In bold letters you will see Light Color and it is currently white. Left-click anywhere on the color bar to enable the Select a Color window, which is similar to the color wheel you would see in other art programs like Photoshop.
Left-click on the red area and find a value that suits you. I've gone with 1. Open the indented dark gray colored tab marked Point Light Component to expose the Radius property. Let's cut it in half, from the default value of down to to give us a more concentrated light. We should also shrink the Falloff Exponent property, so that the light source has a sharper decline from its brightest point to its lowest. Cutting this in half, from its default value of two and changing it to one, will suit our purpose.
You can see these changes in real time by dragging your archetype into the scene at any point. Notice that our adjustments to the Radius and Falloff Exponent properties shrink the light blue spherical lines around our PointLight when viewed from the wireframe mode in the editor. The best way to look at archetypes is to consider them as templates. You are inheriting all of the values from one parent class and simply adjusting the default properties to what you feel suits the needs for your current application. This allows us to inherit all of the properties from a parent class, as well as make changes to those properties in our new child class, while adding some new functionality of our own.
If you want your functionality to stay the same but are looking to make content or data driven differences colors, particle effects, damage, and so on , then archetypes are an excellent solution. A simple enemy of multiple classes is an excellent example to use. Say you want to have a scout class and a heavy weapons class in your game. Many of these changes are cosmetic, so you may just be altering the clothing color so that they appear different, but you want the scout to obviously run much faster than the heavy weapons, while also having a smaller amount of health.
Simply changing the default maximum hit points and run speed of these two characters will create a great difference as well. Altering objects within the editor Like I mentioned before, with using Remote Control, tweaking values during runtime or while in the editor is a quick way to iterate and allow non-programmers to make adjustments without ever seeing the code. You may find yourself in a situation where art assets for a project are not yet available, but you understand the functionality you'll want out of an object.
Therefore you can use placeholder art, which will later be replaced with the final product, but in the mean time your time can be spent putting the prototype into place. Reduction of compile-time and load-time overhead Unreal Engine 3 loads everything before it is needed, so it may take some time to build scripts and compile a project each time you make a change to the code, especially if you have a large number of references to content.
There are ways around this, however, in case of dynamically loading an object, it loads everything during the runtime. See also Feel free to edit more parameters or even grab other actors to create archetypes from, such as weapons. With the assets UDK provides, you can create something such as a rocket launcher that fires pulse beams and has a particle emitter from the shock rifle. Creating a subarchetype from an archetype An archetype is a set of property values which will be assigned to a newly created object, a template.
There may be a time when you want to extend from those values and create another template with similar properties. Getting ready We're going to create a subarchetype from a weapon pickup factory, so the only thing you'll need to get started is to open up a fresh map within the editor. Think of it as extending from a class, just as we would do with an IDE, but instead we are extending from an actor from within the editor. To do this we'll need to go back to our Actor Classes Browser, which is necessary whenever creating archetypes of any sort.
Open the Actor Classes tab and in the Search bar type Weapon to bring up the list of applicable actors. Go back to the content browser and left-click on the newly created archetype, then press F4 to bring up its properties. We're going to keep things simple and only change one property here, and that is which weapon this pickup factory spawns. This pickup factory will now spawn the shock rifle.
To test it out, drag-and-drop your archetype into the map and press the PIE button to play. When you run towards the pickup now, you'll see that it has a shock rifle floating above it. Run over it to pick it up. Time to create our subarchetype. Back in the content browser, right-click on your archetype. One of the options that appears should read Create Subarchetype Left-click on that option. Another dialog box will appear. Your new subarchetype should appear in the content browser.
Left-click on it, then hit F4 again to bring up its properties. You'll see that the Weapon Pickup Class is already set on the shock rifle! Subarchetypes inherit the properties and values of their parent archetype, just as classes receive all of the properties and values from their parent classes.
This allows us to place a number of actors onto a map that share common characteristics. We use archetypes instead of just code, as it allows our actors to be easily manipulated within the editor. So with that, let's talk about cameras. All of these classes interact to control the rotation, position, and special effects that should be applied to the player's camera during the course of a game.
The input from the player is received from the PlayerController class and used to update the positions and rotation of the pawn it is controlling. The Camera class passes its update to the Pawn class, which in turn updates the rotation and position back to the camera. By altering one or more of these classes and the way they interact, the player's camera can be set to show the world to the player using any perspective.
By default, the player's camera uses a first-person perspective with the option to toggle it to a third-person over-the-shoulder perspective. We're going to create our own camera system which will allow us to do all of that, and more. A player's view into the world is determined by the Camera class. The camera's rotation and position determines the viewpoint from which the scene is rendered when displayed on screen. Additionally, the Camera class holds properties for controlling the way the world is seen, such as setting the aspect ratio, field of view, and so on.
Cameras also have special effects that can be applied to the Camera class, thus allowing things such as post processing, camera animations, lens effects, and camera modifiers. While we won't discuss those special effects here, I, at least, wanted to bring them to your attention. The PlayerController class Responsibility for translating player input into game actions, such as moving a pawn or controlling the camera, is passed off to the PlayerController class.
It's not unusual for the player controller's rotation to drive the camera rotation, although there are other ways to handle this, such as having our target pawn implement CalcCamera. We will not be taking that approach, however. There are some negatives associated with this path, including the loss of some functionality, such as camera animations and post processing effects. Now how exactly does this tie into the pawn?
UnrealScript Game Programming Cookbook [Dave Voyles] on ykoketomel.ml * FREE* shipping on qualifying offers. Make the Unreal Engine your own and enter . By providing a series of engaging and practical recipes, this "UnrealScript Game Programming Cookbook" will show you how to leverage the.
The player's physical representation in the world is not only handled by the pawn, but it can also be responsible for controlling the position and rotation of the player's camera. By overriding certain functions, you can create new camera perspectives. This is exactly what we're going to do with our Camera and PlayerController classes. Configuring the engine and editor for a custom camera All of our recipes will require a new custom GametTypegametype class to tell UDK to use our new Pawn and PlayerController classes.
Getting ready We'll be using the same game type and player controller for all of these cameras, so we'll begin this chapter's recipes by explaining them here. We'll need to modify the DefaultGameEngine. TutorialGame With that out of the way, we can finally get to make our prototype camera system work within the editor. It may be necessary to delete your UDKGame. Our game runs off of the UDK versions; if they're still there, they'll be used without our modifications.
With our game configured correctly, we need to make sure we have the correct map and game type loaded when we start the UDK editor. We really only have to change the game type from a menu, so that UDK knows to look for our custom game, instead of its default setting of Unreal Tournament as explained in the following steps: 1.
Afterwards, left-click on the View tab at the top-left corner, which will bring down its contents. Scroll down to World Properties, and left-click on that. Now when we hit the PIE or Play In Viewport buttons, our game will load our TutorialGame, which as we learned before, is what sets the elements we need to have loaded for our camera, pawn, and player controller in motion.
When changing the default gametype and adding packages to UDK, we'll always need to configure the. Once we've made those changes, so that it looks for our new game type and package of classes, we just need to change the game type for our specific map. The properties class includes the variables we will expose to the UDK editor. Coming back around to the archetypes we spoke about earlier, our camera will now be made into one, which is what allows its properties TutorialCameraProperties. The first thing we'll need is a Camera class to store all of our variables and functions in.
We'll use these throughout the rest of our tutorials, and they'll hold the values for manipulating how the camera interacts with the environment. We can do this by creating one new class. We'll begin by creating our TutorialCamera class. As UDK's camera class already offers much of what we'll need for our own camera, we'll just extend from theirs. We'll also need to have access to our TutorialCameraProperties class, and we do so by declaring a variable for it. Immediately following that, we'll include some code which will be written to our log file when the camera is first initialized.
This allows us to verify that our camera is actually being called. It will save you an enormous amount of frustration, especially when debugging, as you will know immediately whether or not your code you're looking at had ever been called. We place this in our PostBeginPlay method as it will be one of the first things executed before a class is fully initialized.
The super. PostBeginPlay method above our 'Log function indicates that we want our parent class' PostBeginPlay method to be called first, then execute ours, wherein our parent class is Camera. Chapter 3 3. We'll have a number of vectors to define, but it is simple if we break it down: The first one, V, is simply a placeholder and of no use to us. The GetActorEyesViewPoint method required a vector as one of its parameters and we had to put something in there, so we used V.
The HitLocation and HitNormal variables are used for our trace. This comes into play when our camera bumps into a wall, and rather than clipping through the wall, allows the camera to be offset, so that it still displays our pawn without interrupting the gameplay experience. Finally, the HitActor variable declares what we've just hit when doing our trace. WeaponSocket if Pawn. Location, OutVT. Rotation ; The weapon socket is one of the properties we'll declare in the TutorialCameraProperties class, so we won't have to worry about hardcoding it here just yet. We generally want to use the rotation of our target, in this case our pawn, so that we view the world as it would.
If that's the case, we'll want to have this turned on. We will want to offset the rotation of our camera from its default socket location. This is what allows us to create first, third, and virtually any other camera we'd like to use. We'll also need to do the applicable math for the calculation. We take the local CameraOffset and adjust it to global space so it can be applied to the out vector. This is where our trace will come into play. We need to check and see if our potential camera location will work, meaning that it won't put us in a wall.
If we do run into a collision issue, the camera will automatically offset itself by the value of the normal of what we hit. Our last piece of code makes us declare the archetype that we will be using to access our camera's properties. We'll cover exactly where we get this file path at the end of our TutorialCameraProperties tutorial.
Flipping back and forth between an IDE and the editor to determine the exact numbers for variables such as offset, rotation, and distance for our camera system can be a frustrating and time consuming. By scripting one prototyping camera system from our IDE, we will be allowed to change values on the fly from within the UDK editor. This way, we can not only save valuable time and avoid frustration, but also quickly prototype new camera systems and see how our current ones work. We've created a camera system and exposed certain properties to the UDK editor to avoid cluttering our editor, while at the same time allowing for easy manipulation of important properties, such as rotation and vector.
Getting ready Open your IDE and prepare to create a new class. Exposing properties to the editor can be a far easier way to make tweaks and changes to actors like our camera. Without this archetype we are about to build, we'd have to manually change the variable within our IDE, compile the project, then view our results in the editor. We plan on making the life of your level designer much easier with this simple fix. In the following recipe we'll need to create a new class, in addition to an archetype within the UDK editor, so that our level designers can reference our class without ever having to open up an IDE: 1.
Create TutorialCameraProperties. As we're simply making an archetype, we'll be extending our class from the most basic of all UDK classes, Object. Moreover, we want to keep our editor as clean as possible, so we'll be hiding all of the camera's properties with this next step. Moving on, we'll want to expose only the variables we've created in our TutorialCamera class.
This allows us to easily and quickly make changes to nearly anything we would want to change for our camera. All of these variables were previously defined in our TutorialCamera class. You can even create your own! We don't have information to place in our default properties, but we're required to have it regardless.
Our next goal is to get the archetype created within the UDK editor. Launch the editor and open your Actor Browser. I like to add the log parameter to my editor, so that I can see the debug screen as I'm making changes. In the search field, enter Camera, and you will see it appear. Right-click on Camera to display the Create Archetype pop-up.
Left-click to bring up the dialog box for archetype options. Chapter 3 9. With that completed, your newly created archetype will be available to you in the content browser. Left-clicking on it will cause the dialog box for the camera properties to display, which illustrates all of the variables we exposed in our TutorialCameraProperty class. Adjusting any of the values in your archetype will now yield new results for your camera! Otherwise this will not work correctly! SetHidden true ; Selecting the checkbox in your editor within the game will now instantly transform your camera into a third person view!
Our camera properties class is simply an object that attaches to our Camera class and allows us to alter our camera's properties from within the editor. We've created an archetype from our CameraProperties class, so that we can reference it from UScript and attach it to our Camera class through our default properties. Attaching our CameraProperties archetype to our camera allows us to make changes on the fly within the editor, and remove the frustration of needing to go back and forth between our IDE, recompiling, and then the editor to see any changes take place.
In the default properties for our Camera class, we listed the path to our camera archetype. Now that we've created our archetype, we can fill in our default property with the proper location: 1. With the name copied, go to TutorialCamera. The following is an image illustrating the five sockets available to our pawn by default: We'll take all that we've learned from our previous lessons and apply it to this one. We'll be hardcoding a first person camera, based on the property values I've found to be consistent with what we are looking for.
Getting ready Our next few lessons will all require one similar change, all of which will occur with TutorialPlayerCotroller class. Moreover, our new camera system will look very similar to our tutorial camera, so I won't go over everything again in much detail. Rather than rely on the values we've entered in our archetype, our camera will now be built around hardcoded numbers which we've deemed to best suit our needs. Of course, you could alter them at any time through code.
UDK comes with a first person camera right out of the box, but we want to create one that fits in with our modular camera system. We'll be creating a new class, which is very similar to our previous camera class in many aspects. Additionally, we'll need to bind this new camera class to our player controller so that we can actually utilize it, which is explained as follows: 1. We'll start by creating a new class called FirstPersonCam, extending from Camera, just as we did with our previous camera system. Follow that up by declaring the two new variables that we'll need, CamOffset, which is of type Vector, and CamOffsetRotation, which is of type Rotator.
Chapter 3 Instead of relying on our archetype for values, we'll write them in default properties and store them in these two variables. Our PostBeginPlay function is the same as before. However, now that we're using a first person view, we'll want to hide the third person mesh, otherwise it will constantly be clipping into the view of our camera. Target ; if Pawn! This next part is new. We now want to declare where our point of view will begin by using a socket.
For the third person and over the shoulder views, the weapon works well; but for first person, the pawn's head works best. The offset values, we declare later, will all be from the socket point we declare here. If you aren't sure of which socket to use, then the camera will start from our pawn's eyes by default. Rotation ; This part is slightly different from what we've seen before. Rather than offer the option of choosing to use the target's rotation or not, we're just declaring that we will indeed use the target's pawn's rotation. I've also added 10 to our x value, because if we don't, then we're able to see the back of the gun's model.
With our class completed, all you need to do is compile the project, launch the editor, and you'll have a first person camera! There was no need to reference our CameraProperties archetype in this example, as we've hardcoded our values based on what worked with our easy tutorial camera.
To start things off, we needed our player controller to use our first person camera, so we made the appropriate change in our default properties block. Our FirstPersonCam extends our Camera class, and allows for more freedom down the road, as opposed to using CalcCamera. While our method requires a bit more work, we are now free to use camera animations and post processing effects. For the most part, the code is very similar to what we had in our TutorialCamera class, but instead of variables for things like camera offset and rotation being read from our CameraProperties archetype, we are hardcoding them in the default properties block of our FirstPersonCam class.
Epic's popular Gears of War franchise uses this camera style, and then zooms into an over-the-shoulder view when sprinting. We'll cover more of that in our next recipe. Getting ready As with our previous recipe, we'll require one similar change in the TutorialPlayerCotroller class.
Most notably, we're looking to hide our first person mesh, so that only our third person mesh is exposed to the camera. In the end, you may notice that your projectiles are not firing from the correct mesh. Not to worry, this isn't an issue with the camera, but a simple change that we need to make in the weapon class, which we'll highlight in the chapter about weapons. Rather than rely on the values we've entered in our archetype, our camera will now be built around hardcoded numbers which we've deemed to best suit our needs, just as we did with the first person camera.
For this recipe we'll be creating a new class for our third person camera, and then binding it to our player controller: 1. Remember when we hid our pawn from view before? SetHidden true ; There are a number of reasons as to why we do this, most notably, due to the fact that designers want to limit the detail of the weapons and pawns as the camera gets further away. There's no reason to have a high poly model present if the player never sees it.
This allows better graphical efficiency as the distance between the pawn or weapon increases. In our first person camera we used the pawn's eyes as the socket point from which our offset would be based. This time however, we're going to be using the weapon's socket, simply titled WeaponSocket. Where the magic happens is in the default properties.
That's because any values which aren't declared in a Rotator are assumed to be zero. To start things off, we needed our player controller to use our third person camera, so we made the appropriate change in our default properties block. For the most part, the code is nearly identical to what we had in our FirstPersonCam class, except for the hardcoded values declared in our default properties block, which are now adjusted to work for a third person view.
While we don't often see games using UDK take advantage of the side-scrolling perspective, one high profile title published by Epic, Shadow Complex certainly did, although with a bit more of a pulled back, Metroidvania style about it. For those not familiar with the term Metroidvania, it is a 2D side-scroller style of game with an emphasis on a non-linear, exploratory action-adventure structure; it inherits its name from the Metroid and Castlevaniaseries.
We'll be hardcoding our values again. Much of what you'll see next is similar to the code found in the third person camera code. We'll also have to make a few changes to the PlayerController class for a number of reasons. Specifically, we want our pawn to only be able to move forward and back, thereby removing the ability to strafe left and right. Moreover, our system requires that the right side of the screen is always considered forward. Just as we did with the third person camera, we'll want the first person weapon mesh to remain hidden, and continue to expose the third person weapon and pawn meshes to the camera.
Getting ready We're going to make a whole new player controller class for this tutorial, as we need to add a new function to it. For now, add this code, which you should already be familiar with by now, as it appears in our TutorialPlayerController. The next function we add allows our projectiles to fire in the correct direction. We are overriding UpdateRotation, so that the projectiles use the pawn's rotation and not the camera's rotation when firing. Without this, you'll notice that projectiles always fire in the same direction, and towards the camera. FaceRotation NewRotation, deltatime ; This next bit seems long-winded, but it is essentially one function really, a state that we are overriding from Pawn.
Hitting the left and right or A and D keys on the keyboard will now force your pawn to move forward and back across the screen. Previously, you would have to hit the up and down keys to make the pawn move forward and back. Moreover, setting NewAccel to 0 on both the X and Z axes prevents the pawn from strafing left and right. With our plane of movement locked, we can now create a true side-scroller.
In the following code, we are overriding the state, PlayerWalking, found in the PlayerController. The rest of our code will be nearly identical to that found in our other camera classes. I did change the socket that the camera is based off of, however. Previously, we were using the WeaponSocket socket, which is where the pawn grips the weapon. We don't want to see our pawn's first person weapon again, now that we're using a perspective outside of the pawn's eyes, so let's hide that as well.
SetHidden true ; If we continue to use the WeaponSocket socket, the camera pulls itself in, towards the pawn, as we get closer to the ground. Use the one that best suits your needs. Adjust it accordingly. There is one final change to make, and that's in our TutorialPawn class. We need to change our GetBaseAimRotation method. This function is called by GetAdjustedAimFor in the player controller, which is the rotator for where the pawn will be aiming its shots.
Essentially, we are telling the game to use the direction the pawn is facing for firing shots, and not the camera's. Compile the project and take a look at your results! To start things off, we needed our player controller to use our side-scrolling camera, so we made the appropriate change in our default properties block. We also had to make a few changes to the PlayerController class. Specifically, we wanted our pawn to only be able to move forward and back, thereby removing the ability to strafe left and right.
These changes tell the game to use the direction the pawn is facing for firing shots, and not the camera's. Other than the player controller though, the code is nearly identical to what we had in our FirstPersonCam class, except for the hardcoded values declared in our default properties block, which are now adjusted to work for a side-scrolling view. See also Don't forget to go back to TutorialGame. Creating a top-down camera The top-down camera is popular with RTS games or shooters, as it offers a perspective that allows players to easily see approaching enemies. With our top-down camera we'll have our pitch locked, so that the player cannot look up or down, and therefore also locks the camera from being raised or lowered.
We will still allow the player to freely yaw left and right, and therefore rotate around the world, although the camera will follow the pawn from a fixed perspective. Much of what you'll see next is similar to the code found in the side-scrolling camera code. We'll be using another custom player controller as well, which is only marginally different from that of the side-scroller's. For this recipe we'll be creating a new player controller class so that our pawn's aim is not affected by the new camera system we've implemented.
Otherwise, our pawn's aim would be way off target as it would not be using our player's rotation, but our camera's. The first thing we'll want to do here is to adjust the aiming for our pawn. Without this, our pawn's aim would follow where our camera is pointed, and not where our pawn is facing. Let's add the code for that now. The next part is nearly identical to that in the side-scrolling camera as well, and is the only change we've made to this class. At the same time, we are tying the yaw of the pawn and by connection, the camera to the yaw of the mouse. If the player moves the mouse left and right, the pawn and camera will follow.
Our default properties are left empty as shown in the following code snippet: defaultproperties 4. Next up, we need to create our TopDownCam class. Just as we've done with all of our other cameras, we'll add the code for this. It looks identical to the side-scrolling camera. I found these values by using the tutorial camera and adjusting the values with the archetype until I found what I deemed to be appropriate. You'll notice that my pitch says here though. That's because of UDK's rotation system that I mentioned earlier which is based on radians, remember?
A pitch of degrees is roughly equivalent to of Unreal's unit of measurement. Next up, we need to make a change to our TutorialPawn class. There is only one small change here from the changes we made during our side-scroller tutorial. Used by PlayerController. Therefore, our camera's rotation will follow the pawn's rotation. Additionally, we've set our Pitch to 0, so that the player no longer has any control over the pitch of either the pawn, and by extension, the camera.
The final change we need to make is in the TuorialGame class. TutorialPlayerControll ertdc' 9. Compile the project and take a look! Chapter 3 How it works We wanted to hardcode our values again. Much of what we saw was similar to the code found in the side-scrolling camera. We also made use of another custom player controller as well, which is only marginally different from that of the side-scroller's. Just as we did with the third person camera, we hid the first person weapon mesh and continued to expose the third person weapon and pawn meshes to the camera.
These changes tell the game to use the direction the pawn is facing for firing shots, and not the camera's direction. We've also locked our pawn so that it cannot look up or down when firing shots. Other than the player controller though, the code is very similar to what we had in our side-scrolling camera class, except for the hardcoded values declared in our defaultproperties block, which are now adjusted to work for a top-down view. So with that, let's talk about AI. Similarly, actions are controlled by the AIController class. Considering that they both inherit Controller, they share quite a bit of functionality.
For the most part, AI controllers don't necessarily need a pawn, just like a player controller. Moving may be as simple as following another pawn, or tracking a freshly spawned health pickup, while the other category contains things such as aiming or firing a weapon. The bots, or computer controlled pawns, can be configured to have a multitude of preconfigured attitudes or reactions towards events. For example, you can write a script that instructs the bot to run for cover after taking damage, or to only fire after being fired upon.
We won't cover any of that in depth, but we will cover how to attract pawns towards our newly created pickups in this chapter, and we'll get more in depth with their intelligence in the following chapter. Pickups Pickups in UDK are similar to pickups in just about any other game; however, they can serve a variety of purposes. In a first person area shooter, such as the Unreal Tournament series or Quake III Arena, they can be used to adjust a pawn's properties by temporarily increasing a weapon's damage, providing invulnerability, or even invisibility.
We'll be covering all of those things in the following chapter. Let's start by tracing the classes that our pickups will inherit from: Actor is the base class of all gameplay objects. It offers functions for the animation, physics, sounds, and networking for objects in UDK, which is explained as follows: ff ff ff ff NavigationPoint is organized into a network to provide AIControllers the ability to determine paths to destinations throughout a level.
PickupFactory is where our class finds begin to take shape. It becomes active when touched by a valid toucher, or actor that we define should be able to accept this pickup. UDKPickupFactory is largely responsible for how our pickup is perceived inside the game. Our materials are created from this class, as are other aesthetics such as how frequently the base of our pickup pulses and whether or not our pickup can rotate.
UTPickupFactory provides much of what is necessary for a first person shooter, that is, it updates the player's HUD and inventory in Unreal Tournament, and an additional bot AI is illustrated here. From those base classes the PickupFactory splits into four distinct classes, each of which provides unique functionality. These are given as follows: ff ff ff UTWeaponLocker and UTWeaponPickupFactory: Similar classes are used for picking up new weapons UTPowerupPickupFactory: This adds power-ups, such as improved jumping, quad damage, and temporary invulnerability UTItemPickupFactory: This contains health, ammo, and armor The trick with creating your own pickups, or UnrealScript in general, is to find a template that best suits your need, and either extend from that and override the functions and default properties you need to change, or create your own pickup class that extends from UT or UDK pickup factories.
Now that we've got a class extending from UTAmmoPickupFactory, we've also inherited all of that class's properties, including its functionality. For this recipe, we won't have to make any changes to the functions, but we will be altering some of its default properties. It can be anything from ammo or health, to a specific weapon. Bots can also be programmed to have a preferred weapon, and seek ammunition for that above all else. The higher the desirability, the more likely a pawn is to ignore other objects and often pawns to go after it. This is especially effective when changing an AI's routine during a particular gameplay type.
In capture, if the flag matches, you can often tell your AI companions to either defend your flag, attack the enemy flag, or roam about and seek enemies. We really could use any sound here, so for the sake of variety let's use the rocket launcher's pickup sound. Next, we need to add the light environment for our pickup.
We'll use an ambient glow and set all values red, green, blue, and alpha transparency to one. If you want more of a washed out look, feel free to increase the values across the board. Perhaps you'd like to bask your pickup in a glow that represents the current environment or atmosphere of a level. If you were in a stage filled with lava and fire, it may be wise to have a stronger red value than green or blue. Stages surrounded by water would be best suited to have a blue hue, so consider raising the blue value. With our light environment taken care of, we can now add the visible mesh for our ammunition.
The rotation value does exactly what you would imagine; it rotates the ammo in place. If you remember from our camera tutorial, UDK uses its own system for rotation, as illustrated in the camera tutorial. That's all there is to scripting an ammo pickup. We'll now need to create an archetype for it in the editor, so that we can place it in a level. Compile the code and launch the editor. With that done we now have a pickup that we can drag-and-drop into an editor. Drag your archetype onto the screen and it should appear like the following image: We've created our first pickup!
By extending from a parent class, which offered a considerable amount of base functionality to build from, we were able to easily add our own properties to make a working pickup. Rather than create our own assets, we chose to use those already packed in with UDK. We aren't limited to just using static meshes that other pickups use, however. Nothing is stopping us from shrinking a truck down and using it as an RC sized pickup to represent a larger vehicle.
Get the item you ordered or get your money back. Alan Thorn. Your password has been changed Sucessfully. Colin Moock. Refer to eBay Return policy for more details.
Creating a base for our pickup to spawn from Now that we have our first pickup created, we'll want to really customize it to suit our purposes. Our pickup seems kind of boring if it is just floating by itself. Arena style shooters generally have a row of four or five small health or ammo packs adjacent to one another, but what if we want to make our pickup seem more important, at least visually?
By adding a base mesh, our pickup is no longer floating from thin air, but actually appears to spawn from a device of some sort. We may want a weapon or a power-up, such as quad damage to be highlighted on the level, so we'll add a static mesh beneath it. Chapter 4 Once again we will need to start by making changes within our defaultproperties block, as that is where most of our pickup's functionality can be adjusted easily: 1. At the bottom of your class, inside of your defaultproperties block, add the following code: defaultproperties We've just added a base mesh to sit beneath our pickup.
The reason we translate on the z axis is because we want to have some room to add a particle effect in our next step, otherwise our base would look kind of bland. We also scale it to 0. You could have the base mesh at full size, but you would need to translate on the x axis to compensate for the offset. Beneath that block, let's add some code for our particle effect: defaultproperties This is added the same way that we've added the base and pickup meshes.
We add a small translation on the z axis here too, because we want it to appear as though it is sprouting from the base mesh, and finishing around where our pickup will sit. All game-related objects are derived from the base class, Actor, in the Unreal Engine. ActorComponents define numerous lightweight components that provide an interface for modularity of actor collision and rendering.
An ActorComponent object is an object which can be attached to an actor, and subclass can override some or all of the default properties of the component. In this example, we're adding a particle component to our pickup, which allows for the viewing and alteration of particles when the pickup is spawned. We've also added a component for our base mesh, which allows us to easily swap out the static resting beneath our pickup.
Both of these aesthetic changes can make it easy for players to discern what purpose a pickup serves from a distance that is, health, armor, weapons, and so on. Animating our pickup Our pickup is moving towards almost completed, but there are a few more additions we can make to it, to allow for a bit more life behind breathe life into our object. Let's add a rotation and bob to our pickup, so that it really grabs our eye with some animation. This is very straightforward. We start off by adding a rotation to our pickup, and then add an animated bobbing motion.
Just as we did with our previous tutorials, we'll need to alter our defaultproperties block as explained in the following steps: 1. In the defaultproperties block write the following code: defaultproperties Adjust the rotation rate to a number that best suits your needs by adjusting the rotation rate. This will also allow our pickup to bob up and down.
Static meshes may not always have their pivot point centered on the object that is, a door generally uses a corner so you may have to offset yours a bit. You can edit it with var vector PivotTranslation;. With the bfloatingpickup set to true our pickup will now bob in place, while BobSpeed and BobOffset are variables to fine-tune the animation itself. Increasing or decreasing the offset will force the pickup to drop and raise to lower and higher points respectively, as though it were riding on a wave.
The parent classes of our pickup offer Booleans for whether or not our pickup can be animated in a number of ways. By default their values are set to false, or off, and we are simply turning them on. Additionally, we can easily manipulate the animation properties by adjusting the BobSpeed and BobOffset variables.
Play with some of these values to really create something completely different, like a quickly spinning pickup that spawns a particle effect when picked up. Altering what our pickup does Now that we have a pickup which offers ammo to the player, and know how to alter a variety of the pickup variables and aesthetics, let's take a moment to create a pickup that now offers health.
This is a bit more complicated than our previous recipes. We'll have to create a new pickup class in our IDE, as well as an archetype in the editor, so that we're able to access the class and its variables within the editor. This is essential when working with level designers who are not familiar with code. This does exactly what you think it does.
Build your script, then launch the UDK editor. We're going to create an archetype for this, just as we did for the ammo pickup. With our newly created archetype ready, we can now drag-and-drop it into the editor's window and see the reward for our hard work. We're done! Our pickup will now offer health instead of ammo. If you were to create another health pickup which offers more health, some subtle changes can go a long way. I'd suggest placing a new static mesh for the pickup, and consider increasing the scale of the mesh, along with increasing the health value.
Furthermore, bots generally desire health pickups more than ammo, so if you do create a pickup which offers more health, be sure to increase the bot desirability as well. By extending from a different class, UTHealthPickupFactory, we are able to easily change the purpose of our pickup. Rather than have one which drops ammo, we can now have a pickup which spawns health. We can just as easily create a pickup which spawns armor as well. Again, we've created an archetype, so that our pickup class can be referenced and used in the UDK editor and placed in our level. If you had a game that relied heavily on vehicle use however, I'm sure you'd love to find a way to repair your vehicle's health, or increase its dwindling ammunition reserves.
Getting ready Vehicles in UDK cannot pickup items and add them to their inventory by default. The process of allowing vehicles to make use of the pickup inventory is incredibly simple, and we'll start by creating our own vehicle class, along with its content class. We use a vehicle's content class, because that's where all of the data for the aesthetics, weapons, and attributes are held, while the vehicle class generally holds the gameplay functions and mechanics for the vehicle.
It should extend from UTVehicleFactory. Now let's begin.
You'll use this number and email id when you log in and if you ever need to reset your password. Book Details. Support FAQs support ulektz. I agree the terms and conditions. Follow Us. This book will be added to your My Books. Do you want to continue? Cancel Ok. Your Free trial Limit Exceeded. Would you like to buy it?
Error Message. Thanks for your mail conformation. Your account will be activated Soon. Continue Shopping Check Out. Go to My Books Continue Shopping. Student Signup. Create an account on uLektz. Enter your Email ID and mobile Number You'll use this number and email id when you log in and if you ever need to reset your password.