To play ArcheAge Chronicles in a group, choose the same server before creating characters, then keep the party together in the same channel and coordinate the activity you want to complete. Early Access has been announced without character transfers or cross-server play, so server selection is the first requirement rather than a problem a party invitation can solve afterward.
Dungeons are described as instanced for a solo player or a party of up to four, with shared quest progress inside. The October 29 launch-preparation update also describes better invitations across Peace and Conflict Channels, direct movement to the party leader's channel, and more dungeon sections open to groups. On November 2, those are Early Access preparations, while Steam still lists the game as coming soon.
Agree on the server before character creation
Start the conversation outside the game if possible. Confirm which exact server everyone will use, rather than agreeing only on a broad region. The announced cross-server rule is explicit: players on different servers cannot play together.
This is especially relevant when a location appears under an unexpected category. The announced Brazil server was temporarily listed under NA despite being physically in Brazil. A player choosing by category alone could misunderstand what a friend means by a regional option. Compare the exact selection before committing a character.
Character transfers will not be available during Early Access. A possible future review of transfers is not a service your group can rely on now. If friends already have characters elsewhere, resolve whether you will start together on one server before you plan a shared evening around characters that cannot meet.
A short pre-creation check avoids a much larger problem later:
- Confirm everyone has access to the same current release or test.
- Agree on one exact server.
- Compare the selection each player sees.
- Create the characters intended for the shared session there.
- Keep that server decision separate from later party-channel choices.
Channel alignment does not remove the separate same-server requirement.
Distinguish a server from a channel
A server is the shared choice that determines whether your characters can play together at all. A channel is a further part of organizing where your party is within that supported environment. Treating those as interchangeable can lead you to repeat invitations when the underlying problem is actually a different server.
For launch, the team described parties staying together across Peace and Conflict Channels and invitations working across both. It also described an option to move directly to the party leader's channel. These changes address the situation in which members are in the same game environment but fail to find one another in the same channel.
They do not establish cross-server matchmaking. If two characters were created on different servers, a feature named around the party leader's channel should not be assumed to bypass that restriction. Check server identity first, channel alignment second, and then the individual activity state.
No exact invitation-button label or universal keyboard shortcut is established by those announcements. Use the current party interface rather than following an invented control sequence. The useful procedure is the order of the checks and the announced ability to align with the leader, not a guessed menu path.
Pick the activity before organizing roles
A group can mean exploring a point of interest, following a story objective, entering a dungeon, or choosing a PvP environment. Each creates a different immediate objective. Decide which one you are doing before assigning everyone a broad role.
For a dungeon, the supported party size is up to four. A group larger than that should not assume every member can enter the same instance together. Do not substitute an older raid announcement for the stated dungeon-party limit; those refer to different kinds of content.
For open-world exploration, compare the destination and what each person needs there. One player may be looking for a progression object while another is following a quest. Sharing the same location does not necessarily mean every character has the same immediate objective.
| Situation | First useful check | Why it matters |
|---|---|---|
| Friends cannot join at all | Exact server selection | Cross-server play is unavailable |
| Party members cannot find one another | Current channel and leader alignment | Same server does not by itself identify a channel |
| Entering a dungeon | Party size of up to four | Dungeon instances have a stated group limit |
| Different quest outcomes | Each character's current objective | Shared play should be checked against actual progress |
| One player disconnects | Re-entry and retained instance state | Launch changes describe progress surviving disconnects |
Understand what shared quest progress establishes
Quest sharing for party members was among the improvements made for the Next Fest demo. The progression explanation also states that quest progress is shared inside dungeons. Those are meaningful support for playing together, rather than evidence that all progression everywhere is automatically identical.
Before starting a quest sequence, compare what each member currently sees. Confirm the destination, the immediate objective, and whether anyone is at an earlier stage. That comparison is a practical coordination step; it does not assume an undocumented system for skipping prerequisites.
After completing an activity, let each player check the result before the group leaves. If one character still has an unfinished objective, identify the exact difference while the location and encounter are fresh. Repeating the entire route without first checking the objective can obscure a simpler mismatch.
Exploration also includes objects that can be opened once per character. That avoids a race in which only the first player to a discovered chest can benefit, but it is distinct from a party-wide quest completion. Give each person time to inspect the objects relevant to their own character rather than assuming one interaction completes every kind of reward for everyone.
Use dungeon cooperation without assuming a mandatory composition
Dungeons are described as playable alone or in a party of up to four. That means group play is supported, but it does not establish one compulsory tank, healer, and damage composition for every dungeon.
Instead, discuss what your current characters can actually do. Agree on who initiates an encounter, where the group intends to stand, and when to stop advancing. These are coordination decisions that remain useful without inventing a role requirement the game has not specified.
When a fight fails, compare the cause before changing the entire group. Several people taking the same avoidable hit is different from failing to reach an opening or separating from one another. Recognizing that difference helps the next attempt test one adjustment rather than four unrelated changes.
The party aggro system was still a subject for further work in the October 29 update. Do not build your plan around an assumed permanent threat lock or an undocumented taunt formula. Pay attention to what the encounter is doing, and coordinate reactions to its current target rather than relying on a borrowed MMO rule.
Keep the party together through Peace and Conflict Channels
The demo exposed problems with parties that could not find one another, invitations, and channel transitions. The launch-preparation changes were aimed at keeping parties together across Peace and Conflict Channels and allowing direct movement to the leader's channel.
Before moving into a different environment, tell the group what you are changing. A player who follows a destination without noticing the channel change can appear absent even when the server choice is correct. Have the leader's intended channel agreed upon before the transition, then check that everyone has arrived.
Also agree on the kind of session everyone wants. Someone expecting cooperative exploration should know before the group chooses a setting involving PvP. The demo's unusually early PvP entry was a demonstration-specific arrangement, so do not assume its shortcut is the universal release unlock condition.
If an invitation fails, check the basic sequence: same server, intended channel, and current activity state. A failure at one of those boundaries should not immediately be described as a cross-server issue or a general inability to play cooperatively.
Coordinate channel changes with the party; changing channels does not provide cross-server play.
Handle a disconnect as a recovery problem
The October 29 update describes dungeon and instance progress surviving a disconnect in every Early Access region. That is relevant to groups because losing one connection should not automatically be treated as proof that the entire instance must be abandoned.
Pause advancement where practical and establish what happened. A disconnected player, an application crash, and a deliberate exit are different events; the stated improvement concerns disconnect recovery. No exact rejoin timer or recovery menu sequence is established here.
When the player returns, check both where they are and what the rest of the party can see. Confirm channel alignment and the current dungeon state before pushing into another encounter. If recovery does not work as expected, record the server, activity, and point of interruption while the details are available.
That information is more useful for a support report than simply saying that co-op is broken. It identifies whether the problem happened during login, an invitation, a channel move, or an instance recovery, each of which was addressed separately in launch preparations.
Plan a first session with one shared objective
For your first group session, choose a clear destination or activity instead of trying to complete everyone's unrelated goals at once. Confirm the server before characters are created, align the party's channel, compare current objectives, and agree on when you will check progress.
Within a dungeon, stay within the supported four-player limit and use the shared-progress design while allowing each person to verify their own result. In the open world, give members time to collect their own per-character discoveries. Before any channel change, explain where the leader is going and why.
The practical goal is a party that can meet, remain together, and know what completion looks like. The announced launch features support that goal, while the no-transfer and no-cross-server rules define its first boundary. Start with those decisions and you avoid turning a simple server mismatch into an evening of unsuccessful invitations.