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.