gw2cc consists of two primary elements: the proprietary core and the publicly accessible client layer. The core component is a Godot 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, 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 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 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. 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.

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. 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.