1 / 71

Sega 500

Sega 500. Mario Sunshine Camera …in UT2k3. Jeff “Ezeikeil” Giles jgiles@artschool.com http://gamestudies.cdis.org/~jgiles. Right… . So yesterday we covered the basics of how to break the camera away from the player and have some fun with it. Today .

adelle
Télécharger la présentation

Sega 500

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sega 500 Mario Sunshine Camera …in UT2k3 Jeff “Ezeikeil” Giles jgiles@artschool.com http://gamestudies.cdis.org/~jgiles

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

  3. 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…

  4. Mario Sunshine

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

  6. 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.

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

  8. 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.

  9. 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.

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

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

  12. 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.

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

  14. 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?

  15. 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.

  16. 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.

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

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

  19. 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.

  20. 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); }

  21. 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.

  22. 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.

  23. Mario Cam…in UT function PostBeginPlay() { super.PostBeginPlay(); cloc =Location; cloc.y-=elevation; //better start POV cloc.Z+=elevation; } • 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.

  24. 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…

  25. Mario Cam…in UT CameraRotation=rotator( ViewActor.Location -CameraLocation); • 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.

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

  27. 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.

  28. 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.

  29. 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).

  30. 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.

  31. 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.

  32. 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

  33. 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.

  34. 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.

  35. 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"

  36. 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); c.DrawText(mariocam(PlayerOwner).dbug@"<--Debug Info"); } }

  37. 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. c.DrawText(mariocam(PlayerOwner).dbug@"<--Debug Info");

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

  39. 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.

  40. 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.

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

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

  43. 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.

  44. 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; }

  45. 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;

  46. 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 cloc step

  47. 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

  48. 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;

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

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

More Related