The Player Manager System centralizes player-related runtime management for multiplayer sessions. It tracks connected and banned players, broadcasts join/leave and combat events, exposes player management actions such as kick, ban, timeout, and freeze, and supports scoreboard and kick-popup UI through the player-side component.

For shared setup guidance, see the Migration Guide and Integration Guide. Use the System Atlas to look up functions, variables, events, components, and ownership references. Use this page for Player Manager-specific setup, integration points, and extension guidance.

Related Video

Version note: some videos may have been recorded before V4. The same principles still apply, but asset names, component names, and folder locations may differ. Use this written documentation and the current V4 names as the source of truth.

• Play

What the Player Manager Provides

The system is split between a GameState component and a PlayerController component.

Key features:

• Central player hub for connected players, banned players, and player status queries.
• Join, drop, rejoin, death, kill, kick, ban, timeout, and AFK-related event dispatchers.
• Host-side actions for kicking, banning, timing out, freezing, and unfreezing players.
• Scoreboard support through the PlayerController component.
• Kick popup support through Game Instance communication.
• Integration points for Team Manager, Score Manager, Game Mode System, and optional Level Manager data.

Prerequisites

Session Manager is required. Player Manager works inside hosted/joined sessions; Session Manager owns the session flow, while Player Manager tracks the players inside those sessions.

1. Set up Session Manager first.
2. Add and configure Player Manager after the session workflow exists.

Without Session Manager, the project cannot host sessions with players, so the player tracking and management features do not have the expected session context.

Setup

GameState

Add AC_PlayerManager to the GameState. It should be the bottom-most custom component in the component list.

Correct order example:

1. AC_SessionManager
2. AC_GS_TeamManager
3. AC_GS_ScoreManager
4. AC_PlayerManager

This order matters because other GameState components need to bind to Player Manager events before Player Manager initializes and broadcasts existing player events. If AC_PlayerManager initializes too early, systems such as Team Manager or Score Manager can miss initial join events.

PlayerController

Add AC_PC_Player to the PlayerController. This component handles per-player UI and communication, including scoreboard creation and kick-popup display.

Test Checklist

1. Host a session.
2. Join with a second player.
3. Confirm Player Manager detects the join.
4. Confirm Team Manager assigns the player if Team Manager is present.
5. Confirm the scoreboard shows both players if the scoreboard requirements are met.
6. Disconnect the second player.
7. Confirm Player Manager broadcasts the drop event and dependent systems update.

Player Lifecycle

1. Player joins: Session Manager handles the connection, PlayerState is created, Player Manager reads the player name, adds it to the connected list, checks ban status, and broadcasts the join event.
2. Player is active: Player Manager tracks status, exposes utility functions, broadcasts gameplay events, and provides data for related systems.
3. Player actions occur: host or gameplay systems can kick, ban, timeout, freeze, or unfreeze the player through Player Manager functions.
4. Player leaves: Player Manager removes the player from the connected list and broadcasts the dropped event so Team Manager, Score Manager, and UI can update.

Stored Player Data

Player names come from PlayerState->GetPlayerName(). Depending on the online subsystem, this can be a Steam display name, Epic Online Services display name, or local/offline player name.

Player Manager stores player names and player management state. Other systems remain responsible for their own data: PlayerState for player state data, Score Manager for kills/deaths/assists, Team Manager for team assignment, and Level Manager for progression data when present.

Events and Utility Functions

Player Manager acts as the event source for systems that need to react to player changes.

Common utility functions include:

• GetAllPlayers()
• GetBannedPlayers()
• GetAFKPlayers() (placeholder)
• GetFrozenPlayers()
• KickPlayer()
• BanPlayer()
• UnbanPlayer()
• TimeoutPlayer()
• FreezePlayer()
• UnfreezePlayer()

Player Management Features

Kick

KickPlayer() removes a player from the current session without adding them to the banned player list. Use this for immediate removal when the player is allowed to rejoin later.

Ban

BanPlayer() removes the player and adds their player name to the banned player list. If Save Game persistence is connected, this can be persisted beyond the current session; otherwise it is session-based.

Timeout

TimeoutPlayer() is a temporary ban. The timeout duration is stored in minutes and can be used by the session logic to reject the player until the timeout expires.

Freeze / Unfreeze

FreezePlayer() and UnfreezePlayer() are used by gameplay systems such as Game Mode System to restrict or restore player movement during phases like waiting, countdown, round start, or post-game.

Scoreboard

The scoreboard is created by AC_PC_Player on the PlayerController. It is only created when a Team Manager component exists on the GameState.

Why Team Manager is required: the provided scoreboard organizes players by team. Without Team Manager, players are not assigned to team sections, so the default scoreboard layout does not have enough structure to display correctly.

The scoreboard can show player names, score information, K/D/A-style stats, ping, and optional level/progression data if Level Manager is present. It opens with the P key and can auto-open at game end when used with the Game Mode System.

For non-team games, implement a custom scoreboard layout or adapt the existing widget to display a flat player list.

Kick Popup

The kick popup explains why a player was returned to the main menu. Without this popup, the player may be disconnected and not understand what happened.

1. The server kicks the player through Player Manager.
2. The affected client receives the kick instruction.
3. Kick data is sent to the Game Instance through an interface.
4. The player returns to the main menu.
5. The new PlayerController / AC_PC_Player checks the Game Instance for kick data.
6. If kick data exists, the kick popup is shown once and the data is cleared.

Use this flow for kick reasons, timestamps, and user-facing disconnect messages that must survive the level/session transition.

Integration Points

Team Manager

Team Manager depends on Player Manager events. It binds to player joined and player dropped events, assigns players to teams, removes dropped players from teams, and can rebalance teams after changes. Player Manager does not depend on Team Manager, except that the default scoreboard requires Team Manager to exist.

Score Manager

Score Manager binds to Player Manager combat events such as player died, player killed actor, and player killed player. It updates kills, deaths, assists, and scoreboard data from those events.

Game Mode System

Game Mode System uses Player Manager to freeze or unfreeze players during match phases. It can also use connected player counts to check whether enough players have joined to start a match or countdown.

Level Manager

When Level Manager is present, the scoreboard can display level or progression data. When it is not present, the level column should fall back to a default value such as 0 or 1.

Authority and Required UI

Kick, ban, unban, and timeout actions should be treated as host/server-authoritative. Clients should not be able to remove each other directly.

The Player Manager provides the functions and events, but it does not provide a complete admin interface. Projects that need moderation tools should implement:

• Admin menu UI with kick, ban, unban, and timeout controls.
• Permission rules for host, admin, moderator, or vote-kick workflows.
• Optional vote-kick logic if players should be able to initiate removal through voting.

Implementation Examples

Binding to Player Events

PlayerManager = GetOwner()->FindComponentByClass(AC_PlayerManager)
PlayerManager->OnPlayerJoined.AddDynamic(this, &ThisClass::HandlePlayerJoined)
PlayerManager->OnPlayerDropped.AddDynamic(this, &ThisClass::HandlePlayerDropped)

Use this pattern in systems such as Team Manager or custom gameplay components that need to react when players join or leave.

Admin Menu Actions

1. Create an admin menu widget.
2. Populate it with GetAllPlayers().
3. Add kick, ban, timeout, and unban controls as needed.
4. Call KickPlayer(PlayerName), BanPlayer(PlayerName), or TimeoutPlayer(PlayerName, Duration) from host-authorized UI actions.
5. Refresh the player or banned-player list after the action completes.

Freeze All Players During Waiting Phase

AllPlayers = PlayerManager->GetAllPlayers()
for each PlayerName in AllPlayers:
    PlayerManager->FreezePlayer(PlayerName)

Use the matching UnfreezePlayer() flow when the match starts.

Troubleshooting

Summary

Player Manager is the central multiplayer player-management hub. AC_PlayerManager belongs on the GameState and should initialize after the other GameState systems that bind to its events. AC_PC_Player belongs on the PlayerController and handles player-facing UI such as the scoreboard and kick popup.

Use Player Manager as the source of truth for connected players, player moderation actions, player lifecycle events, and high-level player status. Let Team Manager, Score Manager, Game Mode System, and Level Manager consume those events instead of each system tracking players independently.