Sega 500 Mario Sunshine Camera …in UT2k3 Jeff “Ezeikeil” Giles

Right… So yesterday we covered the basics of how to break the camera away from the player and have some fun with it.

Today We’re going to create new functionality for our camera and bind it to the layer in a manner that could be considered morally wrong. Don’t panic…I’m not talking something as drastic as turning UT into a Tetris emulator …But…

Mario Sunshine

OK…shocking I know… But I’m not talking about the game here. Just the Camera.

The Mario Cam This game has a sweet camera system that lags behind the player and has some functionality built in to allow a “snap” to view from a new location.

The Mario Cam In other words, real time camera transitions between 2 points.

The Mario Cam For those o you who have not seen it, the Mario Cam is not bound to a specific location relative to the player (e.g. always behind) But a relative distance.

The Mario Cam Think of it like this. It’s like you’ve tied the camera to a string and are dragging behind you. When you stop and move towards the camera, the string goes slack until you reach it’s length and start dragging it in a new direction.

The Mario Cam For want of a better analogy, the camera is “tethered” to the player.

Mario Cam…in UT Fundamentally, this is exactly what we are going to do…

Mario Cam…in UT So lets get started… First off I created my own gametype which just allowed me to implement a new HUD and Playercontroller class.

Mario Cam…in UT No functionality. Just setting up some defaults. DefaultProperties { PlayerControllerClassName="Eze.MarioCam" HUDType="Eze.MarioHUD" CountDown=0 }

Mario Cam…in UT Hey, whoa the Nelly! We talked about controllers some yesterday and build one…so just a quick reminder as to exactly what are they?

Mario Cam…in UT Well, look at the headers and fin out…here’s the good bits: Controllers are non-physical actors that can be attached to a pawn to control its actions. PlayerControllers are used by human players to control pawns, while AIControFllers implement the artificial intelligence for the pawns they control.

Mario Cam…in UT In effect, they’re nothing more than mechanise which controls the pawns in the game Human players have a specific one called a PlayerController.

Mario Cam…in UT So, in our gametype, we simple specify which Playercontroller we want to use… PlayerControllerClassName="Eze.MarioCam"

Mario Cam…in UT You guessed it…that means we have to build one… Simply derive from xPlayer.

Mario Cam…in UT As we talked about yesterday, it in the controller where all the view calculations take place. Hence, once again, we are going to over ride the PlayerCalcView function so that we can work our magic.

Mario Cam…in UT Our basic function is: function PlayerCalcView(out actor ViewActor, out vector CameraLocation, out rotator CameraRotation ) { bBehindView=true; ViewActor = ViewTarget; CameraLocation=cloc; CameraLocation.z+=elevation; //force look at our pawn CameraRotation=rotator( ViewActor.Location -CameraLocation); }

Mario Cam…in UT Most of this should be quite familiar to you as we’ve only added 2 variables. Vector cloc: which is what we will be using to set our camera location. Float Elevation: simply how high above the pawn we are. Here I initialized it to 128.

Mario Cam…in UT But first! Just to make sue we start the game with a good view into the world, we need to do some initializations before we start the game.

Mario Cam…in UT The PostBeginPlay function gets called just before the player enters the game. Note: we can’t access the pawns location here as the controller doesn’t yet have a pawn. function PostBeginPlay() { super.PostBeginPlay(); cloc =Location; cloc.y-=elevation; //better start POV cloc.Z+=elevation; }

Mario Cam…in UT And this is enough to run… Notice that we are fixed to look at the pawn and our camera is also fixed in space…just like that security camera…

Mario Cam…in UT The only interesting thing at this point is that this line, by coercing some math to work in our favour, forces the camera to always look at the pawn. CameraRotation=rotator( ViewActor.Location -CameraLocation);

Mario Cam…in UT Right, so I guess its time to go about tethering the camera to the pawn. But first… … A debugging trick.

A debugging trick of the trade… Ok, working with the camera is funky enough that this is worth the sojourn. So far we’ve talked about using the log() function call to write information out to file, and as mentioned, this was really the *only* way for the old version of UT.

A debugging trick of the trade… However, being control freaks…but mostly because it just makes life so much easier, we’re going to throw I at the HUD so we can watch it change in real time. But the hard part can be getting this information to the HUD.

A debugging trick of the trade… Now, if it were as simple as calling the HUD or the canvas object from the controller class, we wouldn’t be talking about this. And frankly, the fact of the matter is, you can’t see the either of these from here… not even through the pawn object (as it gets set to none when your spitting or dead).

A debugging trick of the trade… So, I’m thinking that you can now see how this can be a bit of a problem… 9/10ths of the battle with UT is figuring out how to get access to stuff from where you are.

A debugging trick of the trade… So here is one way… As I’ve mentioned before, we can see the game object from just about anywhere. Thus making this a prime candidate to be middleman.

A debugging trick of the trade… So I went a created a string inside the Mario Cam controller which is what will hold our debug information So I can do something like this: Debugstr= cameralocation

A debugging trick of the trade… One of the joys of working with string is that they have an automatic type conversion for nearly all of the default types in UT. Here, we stuff in a vector so we can see our camera location.

A debugging trick of the trade… Nextly, we create a new HUD class so that we can display this information to the screen. And it’s nothing fancy.

A debugging trick of the trade… Just remember to tell the game type to use the new HUD with the calls to the debug information. HUD Type="Eze.MarioHUD"

A debugging trick of the trade… class MarioHUD extends HudBTeamDeathMatch; function Postrender(Canvas c) { super.PostRender(C); bCrosshairShow=false; //debug block if(mariocam(PlayerOwner).flag) { c.SetPos(100,100); Info"); }

A debugging trick of the trade… And it’s this line that does the work. Some typecasting to get at the information and toss it to the screen. Info");

A debugging trick of the trade… And Voila, our debug information

A debugging trick of the trade… Now if you got real clever, you could wrap this up into a function inside the controller for the HUD to call…thus localizing you information.

A debugging trick of the trade… Now I show you this because the impulse for most seasoned programmers is to call the specific class and provided it the information. As opposed to have that class call us and access it. But sometimes you just have to bit the bullet.

A debugging trick of the trade… If nothing else, I’m hoping this trick will save you some time.

Tethering the camera… Right….back to the task at hand. Surprisingly enough, it not overly difficult either…we just need a few more pieces.

Tethering the camera… Float Maxdistance: The max distance the camera is allowed to be from the camera Vector step: If the Maxdistance is exceeded, this number is used to calculate the new furthest allowable position from the pawn.

Tethering the camera… The new functionality: function PlayerCalcView(out actor ViewActor, out vector CameraLocation, out rotator CameraRotation ) { local vector step; bBehindView=true; ViewActor = ViewTarget; step = vector(Normalize(rotator(ViewActor.Location-cloc ))) * maxdistance; if( vsize(ViewActor.Location-cloc ) > maxdistance) { //slide adjust cloc= ViewActor.Location-step; }

Tethering the camera… With this line we figure out just how far away the camera can be… I could place this calculation inside the if condition, but I’m planning on using is again in a bit… step = vector(Normalize(rotator(ViewActor.Location-cloc ))) * maxdistance;

Tethering the camera… P When our camera exceeds the maxdistance the step valued is used to find a new location for the camera at the furthest radius from the player. Player movement step cloc

Tethering the camera… P This has the effect of causing the camera to “slide” into its new position behind the player. Note: in a direction 180 degrees opposite the pawns movement vector. Player movement Old cloc New cloc

Tethering the camera… That being said, it’s this if condition that does the magic: In short, by using the vsize function, if our camera gets a to be at a greater distance than out max distance, set the camera to it’s new location. if( vsize(ViewActor.Location-cloc ) > maxdistance) cloc= ViewActor.Location-step;

Tethering the camera… And what-da-ya know…that works really quite well. Follows me around just like it’s on a string

Snap to behind… Well…cool! But unfortunately, you can sometimes find the camera in locations that are not great for game play.

Snap to behind… So the account for this, we’re going to create some functionality to have the camera slide in behind the player at the push of a button.

Snap to behind… So, first thing is first. We need to figure out where behind the player is…sounds simple I know…but there is some vector math involved.

Snap to behind… It’s really quite simple. All we have to do is figure out or pawns rotation, get vector for the max distance (this resulting vector will be local to the pawn) and then subtract it from the current pawns location….and voila….instant 6 o’clock fire position. Life is good.

Tethering the camera… P When our camera exceeds the maxdistance the step valued is used to find a new location for the camera at the furthest radius from the player. Player movement step cloc

Snap to behind… In code: Which looks really similar to what we had above. behindloc = vector(Normalize(pawn.rotation )) * maxdistance;

Snap to behind… So, lets start with a simple snap to position first off. Hence the code will be as simple as: if(snap)// snapping to 6 oclock { behindloc = vector(Normalize(pawn.rotation )) * maxdistance; //straigh snap to snap=false; cloc= ViewActor.Location-behindloc;

Snap to behind… So, somehow we need to trap a key input to set our Boolean flag to true. Well, we talked about this in class. We’re going to over ride and exec function call.

Snap to behind… An Exec function is one that can be executed from in game via key press or console command. We’ll set on up from scratch tomorrow for now, well just over ride an existing one. Fortunately the player controller has a bunch built in.

Snap to behind… I’m just going to use the altfire() for now. Yup….that’s it. exec function AltFire( optional float F ) { snap=true; }

Snap to behind… Note that for some reason the alt fire will still cause the player to fire his weapon…but for now…this is fine.

Snap to behind… And POOF…instant snapage. Just don’t forget to add a condition here. if( vsize(ViewActor.Location-cloc ) > maxdistance )&& !snap)

Snap to behind… ….meh! That’ ok…but you know what would be cooler? A slide into position.

Snap to behind… You got it, a camera interpolation between 2 points. To get this to work, well need another vector which well use to update the camera while its moving to behind. Local vector cinterpolation

Snap to behind… By doing something like this, well close the camera in on its new position behind the player. But we need to catch it when we get to that location. cinterpolation=ViewActor.Location-cloc-behindloc; cloc+=cinterpolation/snapSpeed;

Snap to behind… This got the be a bit tricky for a while….then I did something radical….I grew a brain. At first, I was trying all sorts of angle and equivalency tests to try and catch it when it for close with no luck.

Snap to behind… Then in a caffeine deprived haze it struck me…if the distance between these 2 get to zero…well…they must be near the same point in space. Hello VSize…

Snap to behind… Simply, if the distance gets small, stop interpolating a new position. The whole code block reads here: if( vsize(step-behindloc)<1) snap=false;

Snap to behind… else if(snap)// snapping to 6 oclock { behindloc = vector(Normalize(pawn.rotation )) * maxdistance; if( vsize(step-behindloc)<1) snap=false; else { //zero out to relative player coords and not absolute world coords cinterpolation=ViewActor.Location-cloc-behindloc; cloc+=cinterpolation/snapSpeed; }

Snap to behind… And it smoooooothly slides in behind the player at the correct location….regardless of it orientation or position in space. However, there is on small thing to note:

Snap to behind… If the pawn continues to turn, the camera will continue to interpolate a new position until it catches up to the pawn.

Mario Cam…in UT I know, I know….morally wrong…but I hope you found it fun. That’s a wrap for today.