Gameplay Framework

AActor / APawn / APlayerController / AGameMode / AGameState / UActorComponent / USubsystem — стандартный gameplay-каркас UE.

IT Abyss

Gameplay Framework — кто чем владеет в Unreal

Когда говорят «игрок в Unreal», на самом деле имеют в виду связку из шести-семи объектов, у каждого из которых своя роль. AActor — базовый объект мира, всё остальное — его потомки. APawn — это AActor, который может быть захвачен контроллером (Possess). ACharacter — это APawn, к которому уже прикручены CapsuleComponent, SkeletalMeshComponent и UCharacterMovementComponent. APlayerController — это «мозг» игрока: ввод, камера, HUD. APlayerState — реплицируемая идентичность игрока: счёт, имя, команда. AGameMode — правила матча, существует только на сервере. AGameState — реплицируемое состояние матча, видимое всем клиентам.

Это разделение ролей — не академическая красота, а сетевой контракт. AGameMode не реплицируется, потому что правила игры — это серверная вещь; клиент не должен иметь возможность «решить, что он выиграл». APlayerState реплицируется, потому что счёт нужен всем для таблицы лидеров. APlayerController существует на сервере и только у владельца на клиенте — другие игроки не видят ваш ввод. APawn реплицируется как видимое тело. Перепутать, кто где живёт, — мгновенный fail на сетевом собеседовании.

Параллельно с этой иерархией наследования Unreal активно использует composition over inheritance через UActorComponent. Здоровье, инвентарь, способности, движение — всё это компоненты, прикрепляемые к AActor. А поверх всей этой системы стоят USubsystem — синглтоны разной длительности жизни (GameInstance, World, LocalPlayer, Editor), которые заменяют классический паттерн «менеджер-всего».

Карта темы

Actor Fundamentals — AActor, жизненный цикл (BeginPlay → Tick → EndPlay → Destroy), SpawnActor, FActorSpawnParameters.
Pawn Control — APawn vs ACharacter, possession, OnPossess/OnUnPossess, SetupPlayerInputComponent.
Player Controller — APlayerController, ввод, камера, HUD, переживает Pawn между respawn.
Player State — APlayerState, реплицируемая идентичность, CopyProperties при seamless travel.
GameMode (Authority) — AGameMode/AGameModeBase, server-only, правила матча, default classes.
GameState (Shared) — AGameState/AGameStateBase, реплицируется всем, общее состояние матча.
Character Movement — UCharacterMovementComponent, режимы движения, репликация, client-side prediction.
Component Composition — actor как набор компонентов, AttachToComponent, scene-иерархия.
Component Reuse — переиспользование компонентов между классами, ClassGroup, BlueprintSpawnableComponent.
Health Component — канонический паттерн health, репликация, OnDamage-делегат.
Damage System — TakeDamage, DamageType, UGameplayStatics::ApplyDamage, модификаторы урона.
Ability Cooldown — паттерны перезарядки: timestamp, GAS, FTimerManager.
Subsystems — UGameInstanceSubsystem, UWorldSubsystem, ULocalPlayerSubsystem, UEditorSubsystem.

Частые ошибки и ловушки

Ошибка	Последствие
Считать, что `APawn` — отдельная ветка от `AActor`	`APawn` наследуется от `AActor`; pawn — это actor с возможностью possession
Хранить счёт игрока на `APawn`	Pawn умирает при respawn — счёт пропадёт; место счёта — `APlayerState`
Класть ввод/камеру на `APlayerState`	PlayerState реплицируется всем, ввод — приватная вещь; ввод живёт на `APlayerController`
Хранить реплицируемое состояние в `AGameMode`	`AGameMode` существует только на сервере — клиенты его не видят; общее состояние — в `AGameState`
Применять урон через прямое вычитание `Health -= Damage`	Минует `TakeDamage`, `DamageType`, `OnDamage` — никаких модификаторов, никаких событий
Отсчитывать cooldown в `Tick`	Дрейфует с FPS; используйте `GetWorld()->GetTimeSeconds()` как timestamp
Считать `AIController` и `APlayerController` взаимозаменяемыми	Это разные потомки `AController`, у них разная роль и разный жизненный цикл
Делать `NewObject<AActor>()` вместо `SpawnActor`	Actor не зарегистрируется в мире, не получит `BeginPlay`, не будет тикать
Привязывать вход в конструкторе вместо `SetupPlayerInputComponent`	Привязки до старта игры отбрасываются; обработчики не вызываются
Доверять урону, который шлёт клиент числом	Любой клиент пришлёт «миллион»; клиент шлёт намерение, сервер вычисляет
Считать `AGameInstance` и `AGameMode` одним и тем же	`AGameInstance` живёт всё время процесса (даже между уровнями), `AGameMode` пересоздаётся на каждый match
Полагать, что Subsystem нужно вручную создавать и регистрировать	Движок сам создаёт и владеет subsystems; вы только наследуетесь от нужного базового класса

Значение для собеседований

Gameplay Framework — это базовый middle-вопрос на любом UE5-собеседовании на gameplay-программиста. На junior+ проверяют:

Иерархию: AActor → APawn → ACharacter; что pawn — это actor с possession.
Разделение Controller vs Pawn: контроллер думает, pawn выражает.
Где живёт счёт игрока: APlayerState, не Pawn.
Что AGameMode существует только на сервере, а AGameState реплицируется.
Что APlayerController переживает Pawn (respawn-логика).

На middle/senior проверяют:

CopyProperties для миграции APlayerState через seamless travel.
Почему урон маршрутизируется через ApplyDamage/TakeDamage, а не через прямое вычитание.
Серверную валидацию урона (клиент шлёт намерение, не число).
Composition: когда выносить логику в компонент, когда оставлять на actor.
Subsystems: почему они заменяют синглтон-менеджеры, и какой scope для какой задачи.

Типичный неверный ответ: «Я храню счёт на Pawn, потому что Pawn — это игрок». Реальный ответ — Pawn умирает при respawn, и счёт умирает вместе с ним. Pawn — это тело, а не игрок. Игрок — это связка PlayerController + PlayerState; счёт принадлежит PlayerState.

intermediate

Gameplay Framework

AActor / APawn / APlayerController / AGameMode / AGameState / UActorComponent / USubsystem — the standard UE gameplay skeleton.

ue-gameplay-framework

Practice: 23 questions · 4 tasks →

Sections

Contents

Detailed explanation

Gameplay Framework — who owns what in Unreal

When people say "the player in Unreal", they really mean a cluster of six or seven objects, each with its own role. AActor is the base world object; everything else descends from it. APawn is an AActor that can be possessed by a controller (Possess). ACharacter is an APawn with a CapsuleComponent, SkeletalMeshComponent, and UCharacterMovementComponent already wired in. APlayerController is the player's "brain": input, camera, HUD. APlayerState is the player's replicated identity: score, name, team. AGameMode is the match rules and exists only on the server. AGameState is the replicated match state, visible to every client.

This role split isn't academic — it's the network contract. AGameMode doesn't replicate because rules are a server concern; a client must never be able to "decide it won". APlayerState replicates because score has to drive the scoreboard for everyone. APlayerController exists on the server and on the owning client only — other players don't see your input. APawn replicates as the visible body. Mixing those up is an instant fail on a networking interview.

Alongside this inheritance hierarchy, Unreal leans heavily on composition over inheritance via UActorComponent. Health, inventory, abilities, movement — all of those are components attached to an AActor. And sitting above all of this are USubsystems — singletons with explicit lifetimes (GameInstance, World, LocalPlayer, Editor) that replace the classic "manager of everything" pattern.

Topic map

Actor Fundamentals — AActor, lifecycle (BeginPlay → Tick → EndPlay → Destroy), SpawnActor, FActorSpawnParameters.
Pawn Control — APawn vs ACharacter, possession, OnPossess/OnUnPossess, SetupPlayerInputComponent.
Player Controller — APlayerController, input, camera, HUD, outliving the Pawn across respawn.
Player State — APlayerState, replicated identity, CopyProperties across seamless travel.
GameMode (Authority) — AGameMode/AGameModeBase, server-only, match rules, default classes.
GameState (Shared) — AGameState/AGameStateBase, replicated to everyone, shared match state.
Character Movement — UCharacterMovementComponent, movement modes, replication, client-side prediction.
Component Composition — actor as a set of components, AttachToComponent, scene hierarchy.
Component Reuse — reusing components across classes, ClassGroup, BlueprintSpawnableComponent.
Health Component — canonical health component pattern, replication, OnDamage delegate.
Damage System — TakeDamage, DamageType, UGameplayStatics::ApplyDamage, damage modifiers.
Ability Cooldown — cooldown patterns: timestamp, GAS, FTimerManager.
Subsystems — UGameInstanceSubsystem, UWorldSubsystem, ULocalPlayerSubsystem, UEditorSubsystem.

Common traps

Mistake	Consequence
Believing `APawn` sits on a branch separate from `AActor`	`APawn` derives from `AActor`; a pawn is an actor with the possession capability
Storing the player's score on `APawn`	The pawn dies on respawn — the score dies with it; score belongs on `APlayerState`
Putting input/camera on `APlayerState`	PlayerState replicates to everyone; input is private and belongs on `APlayerController`
Storing replicated state in `AGameMode`	`AGameMode` exists only on the server — clients can't see it; shared state belongs in `AGameState`
Applying damage by direct subtraction `Health -= Damage`	Bypasses `TakeDamage`, `DamageType`, `OnDamage` — no modifiers, no events
Counting cooldown inside `Tick`	Drifts with FPS; use `GetWorld()->GetTimeSeconds()` as a timestamp
Treating `AIController` and `APlayerController` as interchangeable	Both descend from `AController`, but their roles and lifetimes are different
Using `NewObject<AActor>()` instead of `SpawnActor`	The actor isn't registered with the world, no `BeginPlay`, no tick
Binding input in a constructor instead of `SetupPlayerInputComponent`	Bindings created before play starts are discarded; handlers never fire
Trusting damage that the client sends as a number	Any client will send "a million"; the client sends intent, the server computes
Treating `AGameInstance` and `AGameMode` as the same thing	`AGameInstance` lives for the whole process (across levels); `AGameMode` is recreated per match
Thinking you must manually create and register a Subsystem	The engine creates and owns subsystems; you only derive from the right base class

Interview relevance

The Gameplay Framework is a baseline middle-level question for any UE5 gameplay-programmer interview. At junior+ they check:

The hierarchy: AActor → APawn → ACharacter; that a pawn is an actor with possession.
The Controller vs Pawn split: the controller thinks, the pawn expresses.
Where the player's score lives: APlayerState, not the pawn.
That AGameMode is server-only and AGameState replicates.
That APlayerController outlives the pawn (respawn logic).

At middle/senior they go further:

CopyProperties for migrating APlayerState across seamless travel.
Why damage is routed through ApplyDamage/TakeDamage instead of direct subtraction.
Server-side damage validation (the client sends intent, never a damage number).
Composition: when to extract a component vs leave logic on the actor.
Subsystems: why they replace singleton-managers, and which scope fits which job.

Common wrong answer: "I store score on the Pawn because the Pawn is the player." The real answer is that the Pawn dies on respawn, and the score dies with it. The Pawn is the body, not the player. The player is the PlayerController + PlayerState cluster; the score belongs to the PlayerState.

Why it matters

The Gameplay Framework is not one giant "player" class — it's **a system of roles**. Who owns the data, who makes decisions, who expresses them on the stage, what is replicated, what stays server-only. People who confuse these roles put score on the Pawn, input on the GameMode, and replicated state on the PlayerController. Then they wonder why score vanishes on respawn and clients "see no data".

intermediate

Gameplay Framework

AActor / APawn / APlayerController / AGameMode / AGameState / UActorComponent / USubsystem — the standard UE gameplay skeleton.

ue-gameplay-framework

Practice: 23 questions · 4 tasks →

Sections

Contents

Detailed explanation

Gameplay Framework — who owns what in Unreal

Topic map

Actor Fundamentals — AActor, lifecycle (BeginPlay → Tick → EndPlay → Destroy), SpawnActor, FActorSpawnParameters.
Pawn Control — APawn vs ACharacter, possession, OnPossess/OnUnPossess, SetupPlayerInputComponent.
Player Controller — APlayerController, input, camera, HUD, outliving the Pawn across respawn.
Player State — APlayerState, replicated identity, CopyProperties across seamless travel.
GameMode (Authority) — AGameMode/AGameModeBase, server-only, match rules, default classes.
GameState (Shared) — AGameState/AGameStateBase, replicated to everyone, shared match state.
Character Movement — UCharacterMovementComponent, movement modes, replication, client-side prediction.
Component Composition — actor as a set of components, AttachToComponent, scene hierarchy.
Component Reuse — reusing components across classes, ClassGroup, BlueprintSpawnableComponent.
Health Component — canonical health component pattern, replication, OnDamage delegate.
Damage System — TakeDamage, DamageType, UGameplayStatics::ApplyDamage, damage modifiers.
Ability Cooldown — cooldown patterns: timestamp, GAS, FTimerManager.
Subsystems — UGameInstanceSubsystem, UWorldSubsystem, ULocalPlayerSubsystem, UEditorSubsystem.

Common traps

Mistake	Consequence
Believing `APawn` sits on a branch separate from `AActor`	`APawn` derives from `AActor`; a pawn is an actor with the possession capability
Storing the player's score on `APawn`	The pawn dies on respawn — the score dies with it; score belongs on `APlayerState`
Putting input/camera on `APlayerState`	PlayerState replicates to everyone; input is private and belongs on `APlayerController`
Storing replicated state in `AGameMode`	`AGameMode` exists only on the server — clients can't see it; shared state belongs in `AGameState`
Applying damage by direct subtraction `Health -= Damage`	Bypasses `TakeDamage`, `DamageType`, `OnDamage` — no modifiers, no events
Counting cooldown inside `Tick`	Drifts with FPS; use `GetWorld()->GetTimeSeconds()` as a timestamp
Treating `AIController` and `APlayerController` as interchangeable	Both descend from `AController`, but their roles and lifetimes are different
Using `NewObject<AActor>()` instead of `SpawnActor`	The actor isn't registered with the world, no `BeginPlay`, no tick
Binding input in a constructor instead of `SetupPlayerInputComponent`	Bindings created before play starts are discarded; handlers never fire
Trusting damage that the client sends as a number	Any client will send "a million"; the client sends intent, the server computes
Treating `AGameInstance` and `AGameMode` as the same thing	`AGameInstance` lives for the whole process (across levels); `AGameMode` is recreated per match
Thinking you must manually create and register a Subsystem	The engine creates and owns subsystems; you only derive from the right base class

Interview relevance

The Gameplay Framework is a baseline middle-level question for any UE5 gameplay-programmer interview. At junior+ they check:

The hierarchy: AActor → APawn → ACharacter; that a pawn is an actor with possession.
The Controller vs Pawn split: the controller thinks, the pawn expresses.
Where the player's score lives: APlayerState, not the pawn.
That AGameMode is server-only and AGameState replicates.
That APlayerController outlives the pawn (respawn logic).

At middle/senior they go further:

CopyProperties for migrating APlayerState across seamless travel.
Why damage is routed through ApplyDamage/TakeDamage instead of direct subtraction.
Server-side damage validation (the client sends intent, never a damage number).
Composition: when to extract a component vs leave logic on the actor.
Subsystems: why they replace singleton-managers, and which scope fits which job.

Why it matters