Soulframe co-op needs a world that remembers.

Playing together should feel good.

Soulframe looks beautiful. Its landscapes and atmosphere give us a world we want to spend time in. But playing with friends still feels unreliable, and that takes away from the experience.

We want to explore with friends, help each other, and share discoveries. When joining or leaving a group pulls us out of what we were doing, the world stops feeling like a place we can share.

We are concerned that visuals and monetization are getting too much attention while networking and co-op problems remain unresolved. We do not know how Digital Extremes sets its internal priorities, but from a player’s perspective, the balance feels wrong. We want playing together to feel as good as the game looks.

Session protection should not punish ordinary play.

We worry that a networking and inventory model associated with Warframe may not fit the way Soulframe is played. Friends can join or leave while others are already exploring and progressing. Those transitions need to preserve the state of the world.

Since the attempt to address session manipulation, co-op has felt much worse. Being moved to a login site when a session changes is especially frustrating. It pulls players away from where they were and interrupts whatever the group was doing.

Session manipulation and repeated loot claims need to be addressed. But if the fix routinely disrupts legitimate play, the system needs a better way to remember what happened.

A session identity and a rolling interaction ledger.

We propose giving each world a session identity that persists when players join or leave, along with a record of loot-bearing interactions. This is a proposal for DE to evaluate; it is not a specification or a description of the current implementation.

1. Give the world a session ID. A host's world has a unique session ID. When a client joins that host, the client participates in the same session and sees the same session identity.
2. Give each loot-bearing source a stable ID. Interactables with assigned drop tables have identifiers that distinguish them within the world. Combining a source ID with the session ID produces a session-specific interaction identity. The same source in the same session must resolve to the same identity.
3. Keep the session ID sticky when a player leaves. A client who leaves the host keeps the original session ID for the continuing world. Leaving the group therefore does not create a fresh identity for the same sources or reset their eligibility to grant loot.
4. Change the session at a meaningful world transition. Generate a new session ID when a loading-screen transition creates or updates the relevant world instance. The old instance and its remaining loot are left behind; joining or leaving alone should not silently regenerate it.
5. Record loot interactions. Store a rolling history of the last 50 interaction IDs with the player's inventory or account data, with a client copy available for continuity. The server checks claims against trusted session and interaction information.

Once eligible session members have received a source’s reward, leaving, rejoining, or continuing alone should not make that source claimable again for them.

What happens when a friend leaves?

Imagine a host exploring with a friend. The host's world has session ID S, and a particular loot source has source ID A. Their combination identifies the interaction as S + A.

The friend opens that source. The server validates the interaction and grants the applicable reward to every eligible player in the session; each grant is recorded. Later, the friend leaves the group and continues in the same world state, retaining session ID S. Source A is still the same session-specific interaction, so the group split does not make it claimable again for players who already received its reward.

A loading transition that creates a new instance can give that instance a new session ID, with its own sources and eligibility. Leaving a friend’s group alone would not change the session.

One shared encounter, individual progress.

Here are the situations we want to improve and how shared sessions and interaction records could help. Rewards and progression would still be recorded for each player.

Playing together should feel stronger.

Fixing sessions and shared rewards would remove major barriers to playing together. Combat and progression also need attention. Co-op should let friends feel stronger as a group, while solo players remain able to enjoy and progress through the game.

Right now, co-op often feels punishing. Meaningful shared progression is missing, and combat feels significantly harder and slower when more players join. If each member of a four-player group ends up fighting a separate enemy, each fight can feel like taking on an enemy with four times the health. Instead of working through encounters together, players spend longer wearing down individual targets.

That example describes how scaling feels in play, not a verified statement of the game’s health multiplier. The underlying problem is the experience: adding friends should open up opportunities to combine abilities, help each other, and have fun in the same world. It should not make ordinary encounters drag.

We ask DE to revisit co-op scaling with real encounters in mind, including situations where the group splits its attention across several enemies. Shared progression should recognize the players who take part, and difficulty should account for the advantages of a group without making solo play feel like a lesser option.

Make Blessed Meetings worth finding.

The ledger does not solve Blessed Meetings. Searching for them in their current form is not fun for us. The spawn pool can also encourage manipulation: players can create alternate accounts with only Tuvalkane unlocked to try to narrow the pool of possible meetings.

We suggest bringing Blessed Meetings to the Nightfold, perhaps in the Gardens, with encounters appearing in varied locations. That could make them easier to find while making fixed-location automation harder. Random locations alone would not stop automation, so DE would need to consider other safeguards.

We also suggest revisiting the loot pools of the most sought-after meetings. The rewards and effort involved should make the system worth engaging with, without pushing players toward account manipulation or repetitive searching.

The record must be more than a client-side list.

The server should have final authority over every ledger transaction: clients can request an interaction, but the server must verify the session, source, eligibility, and applicable state before granting rewards or starting cooldowns. A rolling list of 50 interactions is useful as a compact recent history, but it cannot on its own prevent replay of an older claim after that entry rotates out. A modified client could also alter a locally stored list. The server therefore needs authoritative, durable claim or world-state information for as long as a session can be revisited, and it must check and commit a reward atomically so simultaneous requests cannot grant it twice.

Unexpected or invalid requests should be rejected and can be logged or flagged for investigation. Repeated or clearly malicious activity may warrant enforcement under DE’s policies, but a single unexpected request can also result from a network error, stale state, or a bug; it should not automatically mean an instant ban.

The session ID can act as a namespace or input to deterministic generation, but an ID or salt is not proof that a reward is legitimate. Server-side validation and, where appropriate, cryptographic signatures or message authentication can help protect records; encryption alone does not establish that a client is entitled to a reward. The exact storage, retention, and trust model belongs to the developers.

Deterministic identity also does not automatically make every aspect of a world deterministic. The implementation would need to define what is generated from the session, how source IDs stay stable, how loot is assigned, and what happens when game updates alter the world or drop tables.

Put a dependable shared world first.

• Prioritize co-op reliability and continuity alongside visual development and monetization.
• Revisit the session-manipulation protections that disrupt legitimate players, including repositioning at a login site.
• Evaluate persistent session identities and authoritative loot-interaction records as a way to prevent repeat claims without resetting the world on ordinary group changes.
• Make loot-bearing interactions grant rewards and applicable cooldowns to all eligible session members, and let players share boss encounters, votives, and quest milestones while recording individual outcomes.
• Give Soulframe room to develop systems suited to its own identity and style of play when shared Warframe technology falls short.
• Rebalance co-op encounters and support shared progression so groups feel effective without leaving solo players behind.
• Revisit Blessed Meetings separately: consider Nightfold or Garden encounters, varied locations, and reward pools that make the system enjoyable without encouraging spawn-pool manipulation.
• Explain the intended behavior for joining, leaving, reconnecting, host migration, and loading into a new instance, then test those paths with real groups.
• Share the tradeoffs and progress with the community so players can understand what is being addressed and provide useful feedback.

We care about Soulframe and want to be able to enjoy its world together. We hope DE will address these co-op problems and share its plans with the community.