---
title: Architecture
description: "gw2cc consists of two primary elements: the proprietary **core** and the publicly accessible **client** layer. The core component is a [Godot](https://godotengine.org/)module written in C++, responsible for transforming GW2 assets into a format that Godot can process, and managing network communications.…"
url: "https://gw2cc.eu/docs/architecture-physics-2/"
updated: "2025-06-30"
category: Developer Guide
---

# Architecture

gw2cc consists of two primary elements: the proprietary **core** and the publicly accessible **client** layer. The core component is a [Godot](https://godotengine.org/)module written in C++, responsible for transforming GW2 assets into a format that Godot can process, and managing network communications. The client  layer operates as a typical "game" within the Godot engine, leveraging the core module's functionality to simulate the GW2 game client. Plugins and bots are developed on top of the client layer.

# Core

The core module is loosely mimicking the design of the official game client with some changes to better fit in with the rest of the Godot game engine. Functionality is distributed among various Manager classes reflecting the grouping of network messages, where each group is typically managed by an individual Manager. Although much of GW2's in-game functionality aligns well with its network structure, there are times when functionality is distributed across Managers, particularly for features that operate over server boundaries.

Owing to the direct interface of the core layer with GW2's proprietary code, it requires consistent updates concurrent with those of GW2 to accommodate any slight adjustments in the networking protocol. The majority of these updates are managed automatically by our auto updater scrutinizing each GW2 patch to identify modifications and apply them correspondingly to the core module.

## ClientSession

The ClientSession class is an extension of the godot [SceneTree](https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree), serving as the pivotal game loop for GW2. It orchestrates and facilitates access to the multiple client-server connections within the game.

## SecureToken/Login/GameClient

These components are responsible for maintaining connections to the secure token, login, and game servers. The secure token, often called the portal server, is in charge of overall authentication for the game and manages functions that are not tied to a specific server such as friend lists, private messaging, and the trading post. The login server facilitates the selection of characters and worlds, whereas the game server oversees the majority of actions occurring post-character selection when you hit “Play.”

## Manager

The Manager singleton serves as the primary gateway to the game state. It provides access to all manager instances, which are essential for obtaining information about and engaging with the game environment. All objects derived from GameManager or StsManager are readily accessible via this singleton. It is important to note that Manager access is restricted to the main thread. Interactions with these classes should only occur within the [_process or _physics_process](https://docs.godotengine.org/en/stable/tutorials/scripting/idle_and_physics_processing.html) functions. In general access to the game state is not thread safe!

# Client

The client layer implements the actual custom client, utilizing the core module's features to connect with the GW2 game servers. It adds higher-level abstractions over the core module’s low-level interface, simplifying the creation of bots and plugins. The client layer includes a behavior tree library that aids in developing AI interactions within the game, as well as facilities for managing plugins and bots, enabling straightforward extensions of gw2cc with new capabilities. Functions not essential to the core module are usually added here, enabling contributions and updates from the community.

## gdbt

gdbt, an abbreviation for Godot Behavior Tree, provides a [behavior tree](https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control)) library. These trees are popular in game AI due to their resilience against unforeseen environmental changes. Contrary to state machines, which require defining all states and transitions, behavior trees assess the game state at each tick and set basic rules for choosing actions. This results in an overall more natural looking behavior and is as such ideal to write bots. gw2cc provides various additional building blocks in the libcc library.

## libcc

libcc is the gw2cc standard library. It mostly provides a collection of building blocks for behavior trees but also provides various useful constants, utility functions and abstractions to ease development.

# Game Loop

Given that gw2cc is built on the Godot engine, its game loop closely mirrors what you'll find in the Godot [documentation](https://docs.godotengine.org/en/stable/tutorials/scripting/scene_tree.html). With GW2's simulation running at 25 ticks each second, the `_physics_process` step occurs precisely at this rate. Network messages are typically processed and managed within the `_process` step, which runs at the maximum rate allowed by the set FPS limit. Messages that affect the physics simulation are accumulated as Commands, to be carried out during `_physics_process`.

![](https://i0.wp.com/gw2cc.eu/wp-content/uploads/image-22.png?resize=548%2C893&ssl=1)

Actions such as casting spells and moving characters should be carried out within `_physics_process`. For more precise control over when your code runs, the `AgentManager`emits `tick_begin` and `tick_end`signals. These are triggered respectively before any command in the queue is executed and after all command effects for the current tick have taken place. You can also use `AgentManager.command_started/command_completed/command_canceled` to react to individual commands.

# ECS

GW2 and gw2cc are designed with a quasi [Entity Component System](https://en.wikipedia.org/wiki/Entity_component_system). In this setting, entities are created as Agents, while the Managers act as systems, and objects such as Character, Player, and Inventory function as attachable components to an Agent. Due to certain constraints of the Godot engine in making objects available to GDScript, components in gw2cc are typically more complex than what's standard in an ECS. Despite these limitations, many benefits of the ECS model remain intact.

To determine whether an Agent possesses a specific component, one would use `Agent.has_component(<ClassName>);` for instance, `agent.has_component(Inventory)` will confirm if the Agent in question has an Inventory component. To acquire the component itself, you may invoke `Agent.get_component(<ClassName>)` or use `Agent.<class_name>`, like `agent.get_component(Inventory`) or `agent.inventory`. **Do not store references to individual components**! Both the remote inspector and the AgentPanel plugin offer ways to identify which components are connected to agents throughout the development process. Adding new components to an Agent is straightforward; simply execute `Agent.add_component(component)`. If you need to find all Agents with a particular set of components, `AgentManager.get_agents_with([<ClassName>])` does the job. Thus, executing `Manager.agent.get_agents_with([Skillbar])` will yield a list of all Agents that possess a Skillbar. **Do note that filtering agents by more than one component is much slower than filtering by a single component**.

You can create your own components by simply inheriting from the Component class. Do note that all components need to have a class_name declared. To instance your component call AgentManager.create_component(<ClassName>). **Instancing components via "new" is undefined behavior**!

# Agent

Within the game's environment, any three-dimensional entity that isn't part of the static map layout is termed an Agent. These agents fall into three primary classes: AgentChar for NPCs, player characters, and creatures; AgentKeyframed for relatively fixed items such as weapons found in the environment, sources for gathering materials, platforms, and other interactive objects; and AgentDynamic, which sees little to no use. While the official client also treats visual effects, missiles and some other objects as Agents, gw2cc treats those separately.

## AgentChar

Generally, AgentChars possess a level and a profession, and except for players, they are also defined by their species which determines shared traits. Additionally, they have both a Character and CoreStats component linked to them.

## AgentKeyframed

Agents that are keyframed generally display animations, which are defined by a sequence property determining the animation affecting the Agent at any given time. These agents frequently have an association with map objects specified by the token property. When keyframed agents aren't linked to a map object, they usually possess a predefined model that represents them within the game environment. Also, a Gadget component accompanies each AgentKeyframed to provide a more detailed description of its behavior.

# Plugins/Bots

The primary means of enhancing gw2cc's capabilities come through plugins and bots. The bulk of user-facing features are delivered through plugins. Plugins typically provide minor improvements and automations for convenience, whereas bots have comprehensive access to the client, enabling complete automation of the game. Users often utilize numerous plugins simultaneously, but only one bot can run at a time due to their exclusive nature.
