Setting up input handling, within player controller, causes a nullptr exception

[Shmoopy1701]

@ryanleslie

Regarding the general advice - I’ve done it both ways. I started with my movement input controls in the Character class. After reading the documentation, though, it seems to suggest more of a model where the Controller handles the input, but calls functions on the Character so the Character still ends up performing the logic but the Controller sets up the bindings.

Does this sound normal or is it more common for the bindings to go into the Character, too?

I guess it would depend on the needs of the game? If different Character classes can have different bindings?

What you outline here is good IMHO. I’ve shipped 3 projects in which the player can at-will possess multiple pawns throughout every game mode:

PlayerController: represents the player’s will, key bindings are here to generalized functions like MoveLeft(), MoveRight(), etc. Always has a reference to the Pawn currently being controlled. A MoveLeft() command to the PlayerController relays a MoveLeft() command to the currently possessed Pawn.

Character: each Character/Pawn has its own implementation MoveLeft(), MoveRight(), etc. extending from a base class (or interface). So the player can control a soldier, tank, or UAV and the commands to the pawn are always the same interface.
Result: key bindings are conveniently all in one place and you can control any type of pawn.