The Guild System is a multiplayer-friendly extension of the Team framework that allows players to create persistent named groups, manage membership, share a guild inventory, progress through rank stages, and gate actions through permissions. In the shown implementation, guild logic is authoritative on the Game State and the player-facing UI/input layer is handled on the Player Controller.

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 Guild Manager-specific setup, runtime behavior, extension points, and integration notes.

At a high level, the system combines inherited team behavior with guild-specific state. Each guild stores branding, privacy state, owner information, member tracking, join requests, rank progression data, a shared inventory reference, and an active announcement. The result is a system that can support public guilds, private application-only guilds, rank-gated progression, and world interactions such as guild-only chests or doors.

The provided demo world makes the intended use case very clear: players can open the Guild Browser, create a new guild, submit join requests to private guilds, use globally linked guild chests, and interact with permission-gated locations only when their guild membership allows it.

Extends the existing Team Manager approach rather than replacing it.

• Stores live guild state on the Game State so all players see one authoritative version.
• Uses the Player Controller component for input, local UI, and client-to-server requests.
• Supports public joining and private join-request workflows.
• Tracks per-member contribution and last-seen data.
• Provides shared guild inventory containers that are automatically linked back to each guild.
• Supports rank gates, completion events, and perks through event-driven requirements.
• Applies permission checks to actions such as join-request review, information editing, and guild-restricted interactions.

Demo world overview showing the high-level system board, the Guild Browser/create flow, the shared guild inventory setup, and the permission-gated guild door.

Adding the Guild System to the Project

The shown implementation is intentionally split across several owners. That split is important because it keeps authority, replication, local UI, and world interaction responsibilities in the correct place.

Why split the system across multiple owners?

The Game State is the right place for guild arrays, guild-owned inventory references, and shared replicated state because that data belongs to the match/world rather than to one player.

The Player Controller is the right place for input, local widgets, menu open/close behavior, and client request wrappers because those are player-specific concerns.

The Player State / team extension is a good place for member-level rule overrides that sit close to inherited Team logic.

World interaction actors should stay focused on interaction and presentation. They should ask the guild managers for the correct container instead of owning guild data themselves.

Details Panel / Important Variables

The screenshots show a small set of important configuration and runtime variables that drive the Guild System. Some belong to the manager itself and some are runtime references maintained by the guild inventory or player controller layer.

Structures Explained

The Guild System is built around a compact set of data structures. Together they describe the guild itself, the members inside it, rank-gated progression rules, and join requests submitted by players.

E_Guild_Ranks

This enum defines the visible progression ladder for guild development. In the shown data it moves from an entry-level guild to a late-game or prestige guild.

F_Guild_Instance

This is the core live guild data struct. Each entry in the Guild Info array represents one guild and stores its identity, ownership, member list, shared inventory reference, and progression state.

F_Guild_Member

This struct stores guild-member-specific runtime information that sits alongside the inherited team membership list.

F_Guild_StageGate

This struct defines one rank stage configuration entry. It is the bridge between a visible guild rank and the rules required to reach it.

F_Join_Request

This struct stores the application data submitted when a player requests to join a private guild.

Data Tables / Configuration Explained

The shown Guild System appears to rely more on configuration arrays and permission/group data than on a large number of standalone guild-specific data tables. That means most of the design flexibility comes from the values stored on the manager and from the inherited Team/Permission systems it plugs into.

Guild rank configuration

Guild rank progression is driven by the Guild Rank Info configuration. Each entry is an F_Guild_StageGate that links one enum rank to a set of requirements, completion events, and perks. When the system checks whether a guild can rank up, it pulls the next matching stage entry, triggers each requirement against the Event Manager, and only proceeds if the requirements pass.

• Use this configuration to control which rank comes next.
• Use requirement triggers to enforce items, achievements, event flags, or any other event-driven condition.
• Use completion events to fire follow-up rewards or state changes when a rank is reached.
• Use the Perks map to expose passive bonuses or unlock data to other systems.

Permission and group configuration

Guild permissions are not hardcoded directly inside every guild function. Instead, the shown implementation queries a permission communicator/manager and checks named permissions before allowing an action to proceed. The Initial Member Group setting and the add/remove permission binding graph suggest that guild members are assigned permission groups through the permission system rather than through bespoke guild-only logic.

The first member added to a newly created guild is treated as the leader and receives the leader group.

When a player is removed from a guild, their guild-related permissions are revoked.

Permission examples shown in the implementation include management of information and management of requests.

This lets UI actions and world interactions stay generic: they ask “does this member have the required permission?” instead of duplicating rule logic everywhere.

Functions to Use

The system exposes a practical set of functions across the Game State managers, player controller layer, and world interaction logic. The most important ones are the public entry points that create/remove guilds, manage membership, resolve join requests, and open the correct guild inventory.

Core guild management functions

Member management / join flow

Rank progression / utility

Replication / change handling

Client to server wrappers

Event Dispatchers

The Guild System broadcasts a concise set of guild-level events that the UI and related systems can bind to without tightly coupling themselves to manager internals.

Guild Browser, Inventory, and Permissions

Guild browser / creation flow

The demo world explicitly shows that pressing G opens the Guild Browser. AC_PC_Guild links the local input mapping, pre-creates the widget hidden, and toggles it only when menu inputs are not blocked. On create, the client gathers the entered guild information and forwards it to the server-side guild manager. Once created, the guild becomes visible in the browser because the authoritative guild array has changed and the relevant add/change events have been broadcast.

The UI is created locally and hidden until needed.

The toggle flow swaps between Game and UI input modes and shows or hides the mouse cursor appropriately.

Create Guild starts the guild at the first configured rank and seeds the owner/member entry immediately.

Join requests and private guilds

The Private flag on F_Guild_Instance controls whether a player can join directly. Public guilds can be joined through the normal inherited team path, assuming the guild is joinable and not full. Private guilds instead prompt the player for a motivation/application message. AC_PC_Guild also captures the player’s current level and includes it in the join request, which gives guild leaders more context when reviewing applications.

Private guilds do not auto-join; they route the player into a request flow.

Each request stores player name, motivation, level, and submission time.

Only members with the correct request-management permission can resolve applications.

Shared guild inventory

AC_GS_Guild_Inventory keeps one shared inventory container per guild and writes the created container reference back into the matching F_Guild_Instance. In the world, BP_Interact_Location_GuildInventory only allows the player to open the one container linked to their current guild. That means two players can interact with the same physical chest actor while still being shown their own guild’s shared inventory.

Guild containers are created and removed in response to guild add/remove events.

Saved container references are refreshed back into guild structs on startup.

Inventory add/remove/has-item requests are overridden so they always target the interacting player’s own guild inventory.

The world interaction actor temporarily transfers ownership to the interacting player where required for UI/replication, then clears it on close.

Permission-gated interactions

Permissions are used at both UI and world-interaction level. The demo world shows a guild-only door that can only be opened by the specific guild it is configured for. The Blueprint-side guild/team extensions also use permission checks before allowing description edits, join-request review, kicking members, or announcement changes.

Information-management permission gates guild description and announcement editing.

Request-management permission gates application approval/rejection.

Leader/admin style group assignment happens automatically when guild membership changes.

World interactions can simply check guild membership or permission state instead of owning guild logic themselves.

Rank Progression and Requirements

Rank progression is driven by the current guild rank and the next available F_Guild_StageGate entry. The manager determines the next stage, runs each requirement through the Event Manager, tracks success per requirement, and only progresses when the required checks pass. On a successful rank-up, the guild’s Current Rank is updated, any completion events are triggered, the rank perks are applied, and the guild change dispatcher is called.

New guilds start at the first rank entry shown in the enum/configuration.

Can Rank Up is the safe read/check path for UI or preview use.

Try Rank Up is the commit/apply path and should only be called when the request is authoritative.

Perks are attached during the same rank-up flow so other systems can query the updated guild state immediately after progression.

Hooking Guild Into Other Systems

The Guild System is strongest when treated as a service layer rather than a standalone menu feature. The provided implementation already demonstrates good cross-system integration points.

Adding Your Own Guild

Create a guild through the browser flow or expose the same data through your own UI. The minimum shown inputs are guild name, owner identity, branding/logo data, and privacy state.

When the authoritative Create Guild call is made, the system will seed the first rank, create the initial member record for the owner, and broadcast the add event so the browser and inventory layers can react.

1. Make sure AC_GS_GuildManager is present on the Game State.
2. Make sure AC_PC_Guild is present on the Player Controller and its widget/input setup is valid.
3. Call the create request from the local UI or your own wrapper.
4. Pass guild name, logo/branding, owner, and privacy state.
5. Confirm the guild appears in Guild Info and in the Guild Browser after replication/event refresh.

Adding Your Own Guild Rank

Guild rank progression is configured through Guild Rank Info using F_Guild_StageGate entries. Each new entry should represent one visible rank and the rules for reaching it.

1. Add or update the desired E_Guild_Ranks enum value if the rank itself is new.
2. Create or update the matching F_Guild_StageGate entry in Guild Rank Info.
3. Set the Rank field to the enum value you want this entry to represent.
4. Add Stage Gate Requirements for anything that must be checked before progression.
5. Add Stage Completed Events for anything that should fire when the rank is achieved.
6. Add perk values to the Perks map if other systems should gain unlocks/bonuses.
7. Test Can Rank Up and Try Rank Up from a guild already at the previous rank.

Adding Your Own Guild Inventory Location

A world guild chest/location should stay lightweight. It does not need to know full guild data; it only needs to ask the guild inventory manager for the correct guild-linked container and then open that one container in the inventory UI.

1. Use or duplicate the BP_Interact_Location_GuildInventory pattern.
2. On interact, confirm the player is actually in a guild.
3. Query the player’s team/guild info and ask AC_GS_Guild_Inventory for the matching container.
4. Push only that one container into the inventory UI/open flow.
5. If your setup needs ownership for replicated UI behavior, transfer it to the interacting player and clear it again on close.
6. Test with two different guilds to confirm the same world actor opens different shared inventories correctly.

Adding a Permission-gated Guild Door

The demo world shows a simple but useful pattern: a door only opens when the interacting player belongs to the required guild or passes the required guild/permission check.

1. Add a guild-aware interaction check to the door or interaction component.
2. Get the interacting player’s current guild/team index through the communicator/manager.
3. Compare that against the required guild or required permission condition.
4. Only allow the open/interaction branch when the check succeeds.
5. Optionally show a prompt when access is denied so players understand why the interaction failed.

Example Flows

Creating a guild

A player opens the Guild Browser, fills in the create form, and submits the request. The client wrapper forwards the data to the Game State guild manager. The manager creates the inherited team entry, seeds the guild struct at the first rank, assigns the owner as the first member, and broadcasts On Guild Added Or Removed. The guild inventory manager reacts by creating the shared container and linking it back into the guild data.

Result: the new guild appears in the browser and immediately has a shared inventory backing object.

Requesting to join a private guild

A player selects a private guild. Instead of joining directly, the system opens a join-request prompt. The player enters motivation text and the controller also captures the current player level. The manager stores or updates the F_Join_Request entry and multicasts the request event. A guild leader/admin reviews the request later and resolves it if they have the correct permission.

Result: private guilds stay application-based instead of open-join.

Opening a guild chest

A player interacts with a guild inventory location in the world. The actor confirms the player is in a guild, resolves the linked guild ID, asks the Game State inventory manager for the correct shared container, and pushes only that one container into the inventory UI. If needed, ownership is temporarily transferred for replicated client behavior, then reset when the interaction closes.

Result: the same physical chest can serve different guilds without exposing the wrong inventory.

Ranking up a guild

A guild leader or other valid caller attempts a rank up. The manager finds the next rank entry, triggers each requirement check, records success per requirement, and only proceeds when the requirements pass. On success, the guild’s current rank changes, completion events are triggered, perks are applied, and On Guild Info Changed is broadcast.

Result: progression is controlled, data-driven, and visible to UI and other systems.

Summary

The Hyper Guild System shown in the provided screenshots is a clear extension of the Team framework rather than a separate isolated feature. AC_GS_GuildManager owns the authoritative guild state, AC_GS_Guild_Inventory gives each guild a shared storage layer, AC_PC_Guild handles local UI/input and client requests, AC_PS_Team_Guild applies member-side permission rules, and world interaction actors such as BP_Interact_Location_GuildInventory keep the physical interaction layer simple.

Because guilds combine replicated shared state, rank gates, join requests, permissions, and shared inventory, the system scales well for multiplayer projects that want persistent social grouping without scattering logic across unrelated actors. Once the managers are placed correctly and the permission/rank configuration is set, the rest of the project can treat the Guild System as a reusable service for browser UI, shared storage, gated progression, and guild-only world interactions.