0

I am writing a sprint state into a custom pawn class in my UDK game. I was looking at Epic's example code for managing states and a good chunk of game logic is in the Controller class rather than the Pawn class. This seems backwards to me. I originally thought that Controllers simply handled AI and player input and now I'm not sure where to place my own state code.

For example, the PlayerController.uc file has PlayerWalking, PlayerClimbing, etc. but seems to change the Pawn's states as well:

// player is climbing ladder
    state PlayerClimbing
    {

        ignores SeePlayer, HearNoise, Bump;

            event NotifyPhysicsVolumeChange( PhysicsVolume NewVolume )
            {
                if( NewVolume.bWaterVolume )
                {
                    GotoState( Pawn.WaterMovementState );
                }
                else
                {
                    GotoState( Pawn.LandMovementState );
                }
            }
...

Since a sprinting state should negate the PlayerWalking state, should I be placing the sprinting state code in the Controller class instead of Pawn? How should that logic be handled? Thanks!

1 Answers1

0

PlayerWalking and PlayerClimbing refer to more about the physics and animation mode of the Pawns rather than actual walking vs. sprinting.

A simple way to do this that would be based off states would be to create a PlayerSprinting state that derives from PlayerWalking, then in both states, upon entering the state set your GroundSpeed to that of which you want.

An example:

state PlayerSprinting extends PlayerWalking
{
    event BeginState(Name PreviousStateName)
    {
         //coped from UTPawn
        DoubleClickDir = DCLICK_None;
        bPressedJump = false;
        GroundPitch = 0;
        if ( Pawn != None )
        {
            Pawn.ShouldCrouch(false);
            if (Pawn.Physics != PHYS_Falling && Pawn.Physics != PHYS_RigidBody) // FIXME HACK!!!
                Pawn.SetPhysics(Pawn.WalkingPhysics);
        }
        //END UTPawn

        //Ground speed modify
        GroundSpeed=SprintSpeed;
    }
}
Allar
  • 140
  • 8
  • My question is why is the physics and animation code in the Controller instead of the Pawn in the first place. Should I be putting my StartSprint, StopSprint, etc. functions and variables inside of the Controller since it already has states for moving? – GrundyTheGolem Jun 14 '12 at 00:32
  • I like to think of the PlayerController class as a means of directing input and only storing control related things that aren't fully relevant to the Pawn, things like HUDs, menus, persistent states that must be kept after death, things of that nature. As for why its done the way it is, its because sometimes Epic writes code while high on unicorn blood. – Allar Jun 14 '12 at 05:35
  • Hahaha, that made my day! I'll be putting the code in the Pawn class then since that actually makes sense! Thanks! – GrundyTheGolem Jun 14 '12 at 21:29