Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sega 500 More on Possession and Using Stuff Jeff “Ezeikeil” Giles

Similar presentations


Presentation on theme: "Sega 500 More on Possession and Using Stuff Jeff “Ezeikeil” Giles"— Presentation transcript:

1 Sega 500 More on Possession and Using Stuff Jeff “Ezeikeil” Giles jgiles@artschool.com http://gamestudies.cdis.org/~jgiles

2 Review So yesterday we covered the basics of how possession works and looked at how the Redeemer and the Bulldog do their thing. We also created our own pawn class for our mortar and set it up so that our pawn can take possession of it.

3 Today We’re going to finish off the basic functionality for our mortar and then expand on this functionality. Hopefully leaving nothing but a few tweeking and polish issues.

4 The Goal Were going to set up our mortar so that the player can do the following The player freely possess and unpossess it at will. Fire shells Rotate the pawn with the mortar If the players original pawn dies, the player restarts.

5 Building on Yesterday We’ve covered the basics of the set up, got the mortar in with it’s “sensor” trigger and we can possess it just fine. But we can’t ever unpossess it. We’re locked in. So lets fix that first.

6 Building on Yesterday Logic has it that if we created a function to swap our possession over to the new pawn (mortar) that we should be able to simply repeat the process for our old pawn. Well…yeah….fundamentally, that’s what we do.

7 Building on Yesterday So if we just do the following: userPC.bBehindView=false; userPC.UnPossess(); userPC.Possess(userPawn); userPC.GotoState('PlayerWalking'); userPawn=none; Repossess our old pawn Return the controller to walking Reset the user pawn, no one is using the mortar

8 Building on Yesterday And yeah! This will work…that’s not the odd thing. But let me ask you…where do we call this from?

9 Building on Yesterday Well, can’t we just use the same function name that the driving state uses?

10 Building on Yesterday In theory, yes. In practice, nope, afraid not. That functionality is specific to vehicles and done with all sorts of flags. Have a look in state playerdriving for the exit command.

11 Building on Yesterday How the vehicle knows to toss the player our and reset the controllers. // check for 'jump' to throw the driver out. if(InJump && Role == ROLE_Authority) { DrivenVehicle.bGetOut = true; return; }

12 Building on Yesterday On the surface, this looks like a bad thing…but really it’s not. Actually, it gives us a really good hint on what needs to be done. Remember, that code snippet came from the playerdriving state in player controller.

13 Building on Yesterday These vehicle flags are all set from the player controller in the driving state and these tell the vehicle what actions to perform. In other words, we need a new controller to deal with our states which are specific to the mortar.

14 A New Controller Fundamentally, what we want to do here is create a new controller which will play nice with our new object. So we create one off of xPlayer class ArtyPC extends xPlayer;

15 A New Controller And now inside here, we have the option of creating new functionality for our player… However the game has to know about it first.

16 A New Controller Thus, we are now limited to three options for telling the game to use our controller as opposed to the default xPlayer. Via Mutator, game type or mortar itself.

17 A New Controller Starting with the game type, which should be review, it’s simple a matter of redefining which player controller to use in our game. PlayerControllerClassname="Rnl.ArtyPC"

18 A New Controller Got to love the one liners. This will of course require the appropriate *.int file so that the player can select the new game type.

19 A New Controller Personally, I feel that this case warrants a new game type as it has a considerable impact on the game play. Not to mention the fact that we are introducing new items into a level which will only function with the appropriate controller.

20 A New Controller Now, as we mentioned, it’s also possible to change the controller that the game uses via a mutator. This is not hard and may well be appropriate in some cases. Say for example if the mortar is deployable as opposed to static.

21 A New Controller So we derive a new mutator class off of Mutator: And, this one is not much harder to implement either… class MortMut extends Mutator;

22 A New Controller Set the new controller via PreBeginPlay. event PreBeginPlay() { super.PreBeginPlay(); Level.Game.PlayerControllerClassName="Rnl.ArtyPC"; }

23 A New Controller And set up the defaults so that we can access it from the menus DefaultProperties { IconMaterialName="MutatorArt.nosym" ConfigMenuClassName="" GroupName="Meet Morty" FriendlyName="Meet Morty" Description="Steel rain" }

24 A New Controller And then there’s option number three. Which is to have the mortar tell the game type to use the new controller. Simple have a function in the mortar class notify the game when it’s initialized

25 A New Controller Like the mutator, this can also be done via the PreBeginPlay. event PreBeginPlay() { super.PreBeginPlay(); Level.Game.PlayerControllerClassName="Rnl.ArtyPC"; } In this case I placed the functionality in the MortTrigger class.

26 A New Controller This method is nice in the sense that the usage of a specific controller is transparent to the player / designer. If the mortar is in the level, it takes care of itself. However, this could cause problems if there are several items in need of different controllers.

27 A New Controller And from here we’re good to go. However, this method feels a bit dangerous to me. But, it seems to function just fine. Doesn’t even log any errors to file.

28 A New Controller So which ever method you choose to use to init your controller is up to you, there are valid arguments for all three. Just be aware of the pitfalls…

29 Making it Work Right, so now that our controller is in place, we can safely make our mortar do stuff. Starting with the release of the player back to it’s original pawn.

30 Making it Work So wrapping up all the previously discussed functionality into a function called: function Release() { userPC.bBehindView=false; userPC.UnPossess(); userPC.Possess(userPawn); userPC.GotoState('PlayerWalking'); userPawn=none; }

31 Making it Work We can now call this from the new controller we created. But first, we need a state to call it from. state artycontrol

32 Making it Work Inside this state, we’ll create a function that will call the release method in the mortar. For now, I’m just going to use the altfire method. exec function AltFire(optional float F) { local Mort mt; mt = Mort(Pawn); mt.Release(); return; }

33 Making it Work And TA-DA! The player can now freely get “into” and “out of” the mortar.

34 Making it Work At this point, this is pretty much what our whole state looks like. state artycontrol { ignores SeePlayer, HearNoise, Bump; exec function AltFire(optional float F) { local Mort mt; mt = Mort(Pawn); if(mt != None) { mt = Mort(Pawn); mt.Release(); }

35 Making it Work But doing it this way is kind of lame since I could quite, realistically want to use the alt fire for something like ….well…shooting for one! Using the jump key might be just a bit more appropriate.

36 Making it Work Rooting around some of the other states, we find that PlayerMove is really common. And guess what? It handles all the player movement…Go figure?

37 Making it Work function PlayerMove( float DeltaTime ) { local Mort mt; mt = Mort(Pawn); if(mt != None) { if(bPressedJump) { mt = Mort(Pawn); mt.Release(); } If effect, we move the body of the function from the alt fire, over to this one and check it against the bPressedJump to see if the button was pressed.

38 Making it Work But there’s a method to my madness here. This is the ideal place to update the pawns rotation so that it’s the same as the mortars.

39 Making it Work function PlayerMove( float DeltaTime ) { local rotator rot; …. if(bPressedJump) { rot.Yaw = Rotation.Yaw; mt.userPawn.SetRotation(Rot); mt = Mort(Pawn); mt.Release(); } UpdateRotation(DeltaTime, 2); } All I need to do is grab the rotation of the view axis (Yaw) and stuff it into rot And update my pawn.

40 Making it Work And thus, our pawn turns with the mortar and can “jump” out of it at any time.

41 Bringing Down the Steel Rain Well, an artillery piece if not really much good if it doesn’t shoot anything. Time to blow up some stuff.

42 Bringing Down the Steel Rain The goal here is just to get it to fire in an approximatly accurate fashion. Proper alignment and velocity can be done later. Here I’m just after getting a reasonable velocity and direction.

43 Bringing Down the Steel Rain So, that being said…lets blow stuff up! As you my have guessed, we need a method for our controller to call which will allow our mortar to fire. You guessed it, done in the player controller.

44 Bringing Down the Steel Rain Nothing really new here. Same methodology, make sure our pawn is valid and call one of it’s methods. exec function Fire(optional float F) { local Mort mt; mt = Mort(Pawn); if(mt != None) { mt.Fireone(); }

45 Bringing Down the Steel Rain And actually the FireOne method is pretty simple, very little newness here. function Fireone() { local vector FireLocation, FireOffset; local flakshell R; FireLocation = Location + (FireOffset >> Rotation); PlaySound(sound'WeaponSounds.P1RocketLauncherAltFire'); R = spawn(class'xWeapons.flakshell', Instigator,, FireLocation, userPC.Rotation); //userPC.SetViewTarget(R); //uncomment for a nose cam view gotostate('reload'); }

46 Bringing Down the Steel Rain With the exception for where we fire our shell from FireLocation = Location + (FireOffset >> Rotation); Where we spawn the shell Right rotation operator

47 Bringing Down the Steel Rain This operator is kind of a handy little toy. In effect, it allows us to offset our fire location relative to our mortar.

48 Bringing Down the Steel Rain Which is to say that if I want my fire location to be offset to my right, by an absolute amount, I can use the >> operator to rotate it right around the location. For example:

49 Bringing Down the Steel Rain This will cause the shell to be spawned 128 units to my right. This spawn location then rotates around my location as I rotate. Staying a distance of 128 units. FireOffset.y=128; FireLocation = Location + (FireOffset >> Rotation);

50 Bringing Down the Steel Rain The shell spawns about here 128 units

51 Bringing Down the Steel Rain Think of this another way, if you hold a pen in your right hand and stick your arm straight out, no matter how you turn in place, that pen will be the same distance from your head. The same thing is happening here. There are also left shift operations as well.

52 Bringing Down the Steel Rain So right now, our mortar fires just fine…as quickly as you can hit the fire button as a matter of fact. That’s a little lame on the game play side of things, so taking a page from the reloading weapons, we go to state reload. gotostate('reload');

53 Bringing Down the Steel Rain Which we define as: state reload { function Fireone() {} begin: sleep(1); userPC.SetViewTarget(self); gotostate(''); } Nothing fancy. While reloading, disable FireOne wait for X amount of time to pass then return to the default state.

54 Bringing Down the Steel Rain And now we can really bring down some pain and suffering with our steel rain.

55 Bringing Down the Steel Rain So the last thing we have to do is check to see if our user pawn gets kill off. Because as it stands, we’ve transferred our “consciousness” to the mortar and, unless we check the pawn, we’re functionally immortal… until we try to leave the mortar that is.

56 Bringing Down the Steel Rain So we need to check if our pawn is still alive…frequently. And nothing gets checked more frequently than tick.

57 Bringing Down the Steel Rain So still in our mortar class, I override the tick method to check our pawn’s life status. Once your read it, it’s quite simple…

58 Bringing Down the Steel Rain function Tick(float DeltaTime) { super.Tick(DeltaTime); if(userPawn != none) { if(userpawn.Health <=0 || userPawn.IsInState('Dying')) { userPC.SetViewTarget(userPawn); Release(); userPC.gotostate('Dead'); } So what does it do?

59 Bringing Down the Steel Rain

60 Here’s the bit that does the work. if(userpawn.Health <=0 || userPawn.IsInState('Dying')) { userPC.SetViewTarget(userPawn); Release(); userPC.gotostate('Dead'); } Look at my corpse Release possession of the mortar…can’t take it with me Tell the controller to act dead Any signs of life?

61 Bringing Down the Steel Rain And there you have it! One functional fixed mortar pit that covers all the bases…just needs some polish for some of the finer details.

62 That’s a Warp There you go, your first steps towards using items in UT2003. You now have all the tools required to get started building your vehicles, security cams, static guns, psychic powers and what not.

63 That’s a Warp I hope you found this interesting and remember, it’s true for UT as it is for the legal system... Possession is 9/ 10 th of the law


Download ppt "Sega 500 More on Possession and Using Stuff Jeff “Ezeikeil” Giles"

Similar presentations


Ads by Google