Multiplayer Guide: Play Online, Shared Ships & Recurring Trade

Multiplayer coordinates how players share a single FOUNDRY game world: who can join, what they can control, how persistence and synchronization work, and the tools for dividing duties between participants. This page covers joining and hosting, player roles and permissions, shared resources and automation that affect multiple players, and best practices for stable cooperative play.

Overview and purpose

Multiplayer allows multiple human players to inhabit the same Foundry instance so they can cooperate (or compete) in the same persistent world. Proper configuration avoids conflicts, preserves progression, and enables convenient shared automation such as recurring trade orders and remote ship tasks.

Hosting and joining

• One player runs (hosts) the game instance; others join as clients. The host is authoritative for world state and must remain connected for many multiplayer modes that use active session authority.
• Sessions may persist on a dedicated server or a host player's machine. Dedicated hosting is recommended for long-lived games and when you want guaranteed uptime.

Player accounts, roles, and permissions

• Players are identified by their account/username in the game server.
• Hosts can assign permissions and roles to players to limit or delegate control. Typical permissions include:
  • Build/modify structures and bases
  • Issue ship and vehicle commands
  • Access trading and economy interfaces
  • Configure automation and recurring tasks
• Grant only necessary permissions to avoid accidental interference with base infrastructure.

Shared resources and storage

• All players in the same world share the same global storage and resource pools. Actions by one player immediately affect available resources for everyone.
• When configuring automated purchases or transfers, factor in that "Min to keep" values on recurring trade orders prevent a purchase if your shared storage is below that threshold.

Automation and recurring tasks

• Recurring trade orders can be configured to automatically execute when their conditions are met. They are useful in multiplayer for maintaining shared resource levels without constant micromanagement.
• For a ship to execute recurring trade orders:
  • The ship must be idle (no current task assigned).
  • The ship must be allowed to execute recurring trade orders (this permission is toggled on the ship overview).
• Set reasonable "Min to keep" thresholds so automated purchases do not deplete shared storage needed by other players.

Ships, task assignment, and coordination

• Ships and other mobile assets are shared entities; only one player’s commands should be active at a time to avoid conflicting orders.
• To ensure an automated ship can act:
  • Make sure the ship has no manual task assigned by any player.
  • Enable recurring execution for that ship if it should act on the trade or task automation.
• Communication between players is required to avoid races where multiple players attempt to give different orders to the same ship.

Stability and desync prevention

• Use a dedicated server or a reliable host with good bandwidth and low latency.
• Limit simultaneous high-frequency actions (mass construction, rapid edits to the same area or entity) from multiple clients; serialize major changes between players when possible.
• When automations interact with player actions (for example, a recurring order that triggers a ship), coordinate times to minimize contention.

Best practices for cooperative play

• Define roles (e.g., logistics/trading, base builder, defense) and give permissions accordingly.
• Centralize automation configuration (one player responsible for trade orders and ship automation) to avoid conflicting triggers.
• Use conservative "Min to keep" values on automated purchases to preserve emergency stock for all players.
• Communicate before sending major assets (ships, vehicles) on long trips or before repurposing shared infrastructure.

Admin tools and moderation

• Hosts should keep the ability to revoke permissions or kick players in case of griefing or accidental destructive actions.
• Regular backups or server snapshots are recommended for persistent multiplayer worlds to recover from mistakes or crashes.

Summary

Multiplayer in FOUNDRY is about shared control of one persistent world. Success depends on setting clear permissions, coordinating automation (notably recurring trade orders and ship tasks), and using a stable host environment. Apply role discipline and conservative automation thresholds to keep the shared game stable and enjoyable for all players.