Steam lists Sephiria online co-op for up to four players. A co-op build therefore needs a communication job as well as a combat job. One player may create space, another may provide dependable damage, another may test setup, and a fourth may remain flexible. These are player-facing roles rather than confirmed classes. The group should be able to recover when a teammate is late, disconnected, or using a different weapon.
Define the party objective
Choose whether the session is learning a chapter, testing a build, clearing a boss, or pursuing an achievement. The objective determines how much setup risk is acceptable. A first-clear group should value readable actions and recovery. An optimization group can test a tighter layout but must label the result as coordinated and version-specific.
The Multiplayer hub explains communication and party size. The Builds hub explains how to write the job sentence. Combine them before selecting a reward; “this supports our control player” is more useful than “this looks rare.”
Build roles with overlap
Avoid a party in which one player is the only source of survival or damage. A primary role can have a secondary action: a damage player should still have a safe retreat, and a control player should still contribute when the room is calm. Overlap keeps the group functional when enemy attention shifts or a reward does not appear.
Record the party size and the version. A two-player setup may have more room than a four-player run, while a four-player group can create a safe window that a solo player cannot. Do not transfer a co-op result to solo without a separate test.
Share inventory decisions
An Artifact or Tablet layout can support one player’s job while consuming space or a reward that another player needs. Agree on the test before picking. If the effect depends on proximity, target focus, or a timing call, write that condition beside the build. The Artifact Synergies and Layout pages can hold the detailed observation.
Boss and recovery plan
Before a boss, choose a caller and a reset direction. The Co-op Bosses page handles encounter-specific notes. The party should know when to stop attacking, where to regroup, and which player can continue if the primary setup fails. A plan that succeeds only on a perfect run is an experiment, not a stable public build.
A party build worksheet
Before the run, write one line for each player: primary job, safe fallback, reserved inventory question, and the signal that changes the job. The worksheet does not need item names when the group is learning. It needs enough information for the team to stop a fragile setup and return to a safe action. After the run, record which line was actually used and which assumption failed.
Use the worksheet to compare party sizes. A two-player test may show whether the interaction works with limited coverage. A four-player test may reveal crowding or an easier boss opening. Keep both results labeled. The Roles guide can hold the communication language, while this page holds the build and reward decision.
Avoid a single point of failure
If only one player can create space, call the build assisted rather than stable. Add a secondary control or a retreat rule that another player can perform. If only one inventory interaction completes the objective, keep a simpler reward path ready. Co-op builds are stronger when they remain understandable after an ordinary mistake.
Write that simpler path in the party notes before launching.