What is UCharacterMovementComponent?

Development Character & Animation
, , , ,
1

I’m doing a lot of my game logic in C++, and I wanted to try and design things in a component based manner. From looking as some examples, it seems like most people move their player by calling a function on the character called AddMovementInput(), but it doesn’t look like this function is in any way tied to UCharacterMovementComponent.

The UCharacterMovementComponent looks huge… one script that handles how the character move on ground, water, and air. Am I understanding that correctly?

Anyways, let me try to break my confusion down into questions:

  • Does the Character class have a
    UCharacterMovementComponent attached
    to it by default?
  • What types of
    actors should I use
    UCharacterMovementComponent on?
  • If I want to create custom components for movement, what class should I extend? UPawnMovementComponent class?

Lastly, since I’m going the route of components, does it make sense to make components audio, vfx, etc? Say, for example, my character swings a sword. If I create multicast events, i could have all of my components hook into the event, and when a button it pressed (in this example, the button is tied to swinging a sword), all of the components are notified of the actions. audio plays a sound. vfx plays effects. etc.

I’m not too sure how to approach the component based programming. I feel as if my pawn class (be it a character, plane, or whatever) should add all of the components it cares about, the components initialize and hook into the pawn’s events. Then everything just works… hopefully.

Thanks to everyone who has read my looooong question, and more thanks to the ones who attempt to answer :slight_smile: I truly appreciate it.

  • Austin
2

Hi, Austin. You actually got most of the things right.

AddMovementInput does not rely on CharacterMovementComponent, but rather on its parent, PawnMovementComponent. These classes are based on UMovementComponent, which has a nice self description:

/**
 * MovementComponent is an abstract component class that defines functionality for moving a PrimitiveComponent (our UpdatedComponent) each tick.
 * Base functionality includes:
 *    - Restricting movement to a plane or axis.
 *    - Utility functions for special handling of collision results (SlideAlongSurface(), ComputeSlideVector(), TwoWallAdjust()).
 *    - Utility functions for moving when there may be initial penetration (SafeMoveUpdatedComponent(), ResolvePenetration()).
 *    - Automatically registering the component tick and finding a component to move on the owning Actor.
 * Normally the root component of the owning actor is moved, however another component may be selected (see SetUpdatedComponent()).
 */

It is a fairly generic movement helper class which is used on all sorts of actors. This class is also used as a parent for ProjectileMovementComponent, for example. I suggest you to look through the source of this class to get an idea of how other movement components work - it’s fairly simple, yet functional. There are a number of similar ones built for specific purposes, and that should not confuse you. PawnMovement is the easiest to use, perhaps - it’s intended to be used with vehicles and similar AI-enabled things which can move at their own will (expressed in BehaviorTree, for example).

All Characters do indeed have CharacterMovementComponent by default, as defined in Character.h:

/** Movement component used for movement logic in various movement modes (walking, falling, etc), containing relevant settings and functions to control movement. */
UPROPERTY(Category = Character, VisibleAnywhere, BlueprintReadOnly, meta = (AllowPrivateAccess = "true"))
class UCharacterMovementComponent* CharacterMovement;

This component has a lot of hooks for the skeletal mesh of the host, and implements different movement modes, such as walking, flying or swimming. It also supports custom modes as well (I’m not familiar with this, however). Skeletal mesh support enables easy integration with AnimBlueprints, so component type is very well suited for heavily animated assets, such as characters. In fact, as stated by the manual,

it is specific to Characters and
cannot be implemented by any other
class

Our approach to component event notification is hard-wiring the corresponding controller/player events to the components by hand. We do this because it’s very flexible, as it allows us disable unwanted automatic component behavior at any time. As far as I can tell, nothing stops you from automatically hooking to host delegates from its components’ initialization code. I haven’t tested it myself, so you might have to try for yourself. Having a bunch of components (like audio) bound your actor is totally normal. There is even a tutorial which makes use of audio and particle emitters just the way you have described.

I hope I got most of the things right, but feel free to ask if you feel uncertain about anything.

3

Wow. Thanks for such a detailed answer! It feels nice to know that I had a fair idea of how to use components (audio, particles, etc. as separate components), but what you’re saying is that you prefer to hook the components to the controller/character events through the controller/character itself?

If I’m right, I can see how there is more control there. You may not want a certain type of character to send out events to a component if they’re in a certain state, and having the component check that state on their end just doesn’t seem right.

EDIT: Oh yeah… also, if I want to create a different movement component, say for a plane… should I inherit from UPawnMovementComponent ?

4

As to your last question - yes, you can only use UCharacterMovementComponent, or a component derived from it, on an ACharacter derived actor. In all other cases you must derive from UPawnMovementComponent. Unfortunately, at the moment a lot of very useful and potentially generic functionality such as network replication is within ACharacter/UCharacterMovementComponent, so if needed you would need to write this yourself when using UPawnMovementComponent.

5

Our controllers are mainly input sanitizers (you can’t shoot while running etc.), leaving this logic to the components would obscure the execution flow. Calling events on a particular component instead of invoking a big mess of callbacks provides an incapsulation, so to speak. You don’t have to inspect all components to see what’s going on. It also has a side effect of making the game much easier to debug and fix in place. I don’t think our approach will fit for more complex games, though - the controller code gets rather convoluted.
It seems like the developers of the engine assume that we should use Pawns for vehicles, but people have a hard time getting the replication right for anything but Character. I have yet to wrap my brains around Unreal’s networking system because our game is a single player :P. We have made an early design decision to inherit most of our base classes from ACharacter, though, because our game doesn’t contain much vehicle action.
For a plane, I would suggest you have a go with UFloatingPawnMovement, if you don’t mind making your own replication routines.
Edit: Here is a question about Pawn replication (quite old, but probably not outdated)