The title of this lecture comes from a song by one of my favorite groups of all time, The Clash. If you've never heard of The Clash or you've never checked them out, pause this video, go check out The Clash, and then come back. In this lecture, we'll learn how to clamp the character's location so the character stays fully within the bounds of the screen. More generally, we use the term clamp when we want to keep a particular value within a range of values or a set of values. To support clamping our character into the screen, I've added some constants for the screen, so we put them in a namespace called ScreenConstants. The way I generated this particular script is over and unreal, I created a new script with none as it's parent, and then I added to the code I wanted here, and deleted some of the code that was in the default script that was provided. In our header file, I've got a new namespace here. We've used namespaces before, but this time we're creating our own. I'm declaring four constants for the left, right, top, and bottom edges of the screen. I will say that there's certainly a way to calculate those boundaries using characteristics of the camera and so on. But we're just going to set the constants because I know what the numbers are, and this will be fine for us. We've seen const and float in variable names or constant names before, but we've never seen this extern keyword before. Here's how it works. Constants in C++ have internal linkage by default, and what that means is those constants are only visible within this translation unit, not other translation units. Other translation units are loosely, although not precisely, the other implementation files in our project, and we want these constants to be visible from other implementation files. Specifically, we want them visible from the CharacterPawn's implementation file. We need to mark them as extern for external so that other translation units can access those constants. The implementation file for the ScreenConstants just gives values to each of those constants. This will be useful to the CharacterPawn to know where the left, right, top, and bottom edges of the screen are. Over in the CharacterPawn header file, I've declared some constants for the half-width and half-height of the character that we're using, and a vertical offset that I'll talk about when we get there. The way I actually figured out the half-width and half-height for this character is, I went to the actual Static Mesh, and I opened up the Static Mesh Editor. Over here on the left, it tells us the approximate size is 6, I know that's the depth, by 25, I know that's the width, by 32, which is the height. This is a rough way to get the size of the mesh. We could certainly, if we replaced the simple collision that was automatically added when we imported the mesh, if we removed that and added a capsule collider, we could access information about the height and width of that capsule collider. But that's overkill for what we're trying to do here. We'll just use this information instead. Let's move to the implementation file for the CharacterPawn. All our work will be in the set location function. Recall last time, all this function had was this one line of code, and I want to add some more lines of code to actually keep the character in the screen. I will say because I'm using these constants from the ScreenConstants' namespace, I had to add a pawn include for the header file for those ScreenConstants, so if you forget to do this, and you try to compile, you get a number of compilation errors. The first one is the trigger for the rest of them. It says, "'ScreenConstants' is not a class or namespace name". Whenever you see that error message, your first thought should be, I forgot a pawn include. I've pawn included ScreenConstants, and Visual Studio takes a while to catch up to me in realizing that I've done that, but I'm going to use the clamp function in the Fmath class to clamp Location.Y so that it falls between a minimum of left plus half-width, so you should think about this, if I'm on the left-hand side of the screen. I have my location on the origin or the center of my model, and mine is approximately in the center of my model. The left side of where I should be able to move my character is left plus half the character width, and that will make it so the left side can't go past the left edge of the screen. Similarly, I make the maximum, the right-hand side minus half-width, and I hand in the location I'm trying to move in, it makes sure it stays between these bounds and I put that into Location.Y. I do something similar with Z, except that you'll see I'm using bottom plus half-height plus vertical offset, and top minus half-height, minus vertical offset. Once we've clamped Y and Z to be within the screen, we set the actor location. But why do I need this vertical offset thing? Let me change it to zero, and I'll show you what happens after I compile, of course. When I run my game, my character follows the mouse around. The character clamps properly on the left and right. But if you look carefully, I can actually move part of her hat above the top, she has black shoes on, I can move her shoes down out of the bottom. I will be honest. I don't really know why this is happening. I checked the simple collision that was imported and it seems reasonably tight around the static mesh and everything. It's not clear to me what's going on here. But I'm just going to force this to work properly by figuring out how to keep it in the screen on the top and bottom. That's a little unsatisfying to me. I will freely confess. I'd like to make this to be perfect, but since at this point anyway, I only have a single character, I can just figure out what this offset is and make it work in my game just fine. Although I strongly encourage game developers to try to figure out the cause of every problem that occurs, and fix it in the most robust and elegant way possible, you've got to understand that there are certainly places in games where you decide that the time or the cost or time is money, so the time in cost of chasing down a problem isn't worth it. You just say, well, I'm going to fudge it and make it, so it works fine. Obviously, horizontally it still works fine, but vertically she hits the very top of the screen and the very bottom of the screen as well. Well, I don't encourage people to just put those fudge factors or kludges into their games sometimes. To recap, in this lecture, you learned how to clamp the pawn's location so it stays in the screen.
