Startup, GameMode, Controller, And Input¶
The startup path is the chain that turns a level into a playable pawn with input.
In the current vertical slice the runtime chain is:
L_SalvageBay_Prototype
-> BP_SalvageBayGameMode
-> BP_PlayerController
-> BP_PlayerCharacter
-> IMC_Player
-> IA_Move / IA_MouseLook / IA_Interact / IA_Jump
-> C++ input handlers
The exact asset names are editor-owned, but the architecture is C++-owned.
GameMode¶
AAndromedaGameMode is intentionally light. The C++ class exists so the project has an Andromeda-specific game mode type, but the current slice does not need complicated game rules there yet.
The Blueprint subclass BP_SalvageBayGameMode selects the actual pawn and controller classes. This is normal Unreal practice:
C++ AAndromedaGameMode = project-specific game mode type
Blueprint BP_SalvageBay... = configured defaults for this playable slice
Level World Settings = chooses the game mode for the map
This keeps the map playable while leaving room for future differences, such as a menu mode, tutorial mode, or simulation/test map mode.
PlayerController And Mapping Contexts¶
AAndromedaPlayerController owns the Enhanced Input mapping-context setup. On BeginPlay, Unreal calls the controller's BeginPlay as part of actor startup. Our override then adds configured mapping contexts to the local player's Enhanced Input subsystem.
The important mental model is:
Input Action = a semantic action, such as Move or Interact
Input Mapping Context = a mapping from physical keys/devices to actions
Controller BeginPlay = adds active mapping contexts for this player
Character binding = binds actions to C++ methods
So when W moves the player, W itself is not hardcoded in AAndromedaCharacter. The key lives in IMC_Player. The character only cares about MoveAction.
Character Input Slots¶
AAndromedaCharacter declares fields such as:
TObjectPtr<UInputAction> JumpAction;
TObjectPtr<UInputAction> MoveAction;
TObjectPtr<UInputAction> MouseLookAction;
TObjectPtr<UInputAction> InteractAction;
These are configured in BP_PlayerCharacter.
At runtime, Unreal calls:
That is where the character casts the component to UEnhancedInputComponent and binds actions:
EnhancedInputComponent->BindAction(
InteractAction,
ETriggerEvent::Started,
this,
&AAndromedaCharacter::InteractInput);
Coming from Java or Go, think of this as registering callbacks with a framework. Unreal owns the event loop. The character registers which methods should be called when input actions fire.
Movement Flow¶
The W key path is:
W key
-> IMC_Player maps W into IA_Move
-> Enhanced Input evaluates action value
-> AAndromedaCharacter::MoveInput
-> AAndromedaCharacter::DoMove
-> AddMovementInput
-> CharacterMovementComponent moves pawn
FInputActionValue is a generic value container from Enhanced Input. For move input it is read as a FVector2D:
const FVector2D MovementVector = Value.Get<FVector2D>();
DoMove(MovementVector.X, MovementVector.Y);
DoMove calls Unreal's movement API:
The character does not manually update its position. It provides movement intent to Unreal's character movement system.
Mouse Look¶
Mouse look follows the same pattern:
Mouse movement
-> IA_MouseLook
-> MouseLookInput
-> DoAim
-> AddControllerYawInput / AddControllerPitchInput
The camera uses pawn control rotation:
That means controller rotation drives the first-person camera.
Contextual Interact¶
There is no separate drop input now. E is contextual:
If focused on a valid interactable:
E interacts with it.
Else if carrying an item:
E drops the held item in front of the player.
This keeps the control scheme simple and matches the current work-sim flow. The player mostly uses one verb: interact with the thing in front of them. Dropping is the fallback when there is no usable thing in front of them.