# (ASC) - PlayerState vs Character

When it comes to setting up the **`Gameplay Ability System (GAS)`** within the **`Rogue Gameplay System`**, one of the key decisions is where to place the **`AbilitySystemComponent (ASC)`**: in the **`PlayerState`** or in the **`Character`**? This choice directly impacts how the ability system behaves, especially in multiplayer games, making it essential to understand the differences to make the best decision for your project.

In this section, we will explore in detail the differences between these two approaches, highlighting the advantages, disadvantages, and how each can be applied in different game types, particularly those with multiplayer characteristics.

## Fundamental Differences: PlayerState vs Character

**1. PlayerState: Focus on State Persistence**

The **`PlayerState`** class is ideal for storing information that needs to persist throughout a player's life, even when the character may be destroyed or swapped out. This makes the **`PlayerState`** an excellent choice for multiplayer games that feature respawning, character swapping, or require consistent data synchronization between server and clients.

When the **`ASC`** is placed in the **`PlayerState`**, it provides the ability to retain abilities, buffs, and player effects, even if the player’s avatar is destroyed or changed. This scenario is common in competitive and cooperative online games, where the continuity of the player’s state needs to be guaranteed regardless of the character's lifecycle.

**Usage Example:**

* **Overwatch**: In **`Overwatch`**, players can switch heroes mid-game. By placing the **`ASC`** in the **`PlayerState`**, information about the player's status, such as achievements or special ability statuses, is maintained even after character swaps.
* **Fortnite**: In **`Fortnite`**, the **`PlayerState`** holds important information about the player, such as kills and temporary ability effects, allowing the state to persist after the character dies and respawns, making this approach ideal for battle royale games.

🔋 **Advantages of PlayerState:**

* **Persistence between characters**: Ideal for games with respawn or character swaps.
* **Synchronization in multiplayer games**: The **`PlayerState`** is automatically replicated on the server and clients, ensuring that all players see the same state.
* **Flexibility**: Allows the player's state to be maintained even when the avatar dies or is swapped.

🪫 **Disadvantages:**

* **Greater complexity for visual effects**: Since the **`ASC`** is dissociated from the character, extra work may be needed to ensure visual effects (VFX) and gameplay events are correctly applied to the active character.

**2. Character: Focus on Avatar Control**

Placing the **`ASC`** directly in the **`Character`** is a simpler and more intuitive approach, especially for games where the state of abilities and attributes is closely tied to the controlled character. This configuration is particularly useful in games where the player controls a single avatar per match and there’s no need to maintain the state of abilities between different characters or upon respawning.

If your game does not involve character swapping or frequent respawns, the **`Character`** may be the most straightforward location for storing the **`ASC`**, as visual effects and gameplay events can be directly applied to the controlled character.

**Usage Example:**

* **Dark Souls**: In **`Dark Souls`**, the player’s character has specific skills and attributes that progress throughout the game. Here, it makes more sense to place the **`ASC`** directly on the **`Character`**, as the focus is on developing the individual avatar, not the player as a whole.
* **Valorant**: In **`Valorant`**, each character (or agent) has a fixed set of abilities that are directly linked to that agent. In this case, the **`ASC`** would reside on the **`Character`**, as the abilities do not persist between different characters or matches.

🔋 **Advantages of Character:**

* **Ideal for games with fixed avatars**: When the player controls the same avatar throughout the match, the **`Character`** is the most straightforward and direct choice.

🪫 **Disadvantages:**

* **Loss of state on respawn**: If the character dies, the **`ASC`** is lost and needs to be reinitialized, meaning active effects and abilities are reset.
* **Less flexible for character swapping**: In games where the player can switch avatars, the state of abilities will not persist, which may require a more complex implementation if needed.

## **When to Use Each Approach?**

**PlayerState is more suitable when:**

* The game is multiplayer and involves respawning or character swapping.
* The player’s abilities and attributes need to persist between different characters or after death.
* You want to ensure the player's state is always synchronized between server and clients.

**Character is more suitable when:**

* The game has a single character controlled per match.
* The abilities are strongly tied to the player's avatar.
* The simplicity of directly linking abilities and effects to the character is prioritized, and persistence is not required.

## **Conclusion: Choosing the Best Approach for Your Game**

The choice between **`PlayerState`** and **`Character`** for storing the **`AbilitySystemComponent`** heavily depends on the specific needs of your game. If your game is multiplayer, involving character swapping or respawning, the **`PlayerState`** will generally be the better choice, ensuring persistence and data synchronization. However, if your game focuses on a single character controlled throughout the match, or if ability persistence is not necessary, the **`Character`** can be a simpler and more effective solution.

Regardless of the choice made, the **`Rogue Gameplay System`** is designed to offer flexibility and complete support for the **`Gameplay Ability System`**, allowing you to integrate the **`ASC`** in the location that best fits your game style.

{% content-ref url="publish-your-docs" %}
[publish-your-docs](publish-your-docs)
{% endcontent-ref %}
