CayPlay confirms that Waterpark Simulator 1.0 multiplayer can start a new park or load an existing one. The release announcement does not define who owns the saved park, what a joining client retains, whether host migration exists, or how an interrupted session commits changes.
Protect important parks and test those questions explicitly. This page is a save-safety protocol, not a claim that one unverified ownership model applies.
Back up the host park first
Close the game cleanly and preserve the save using the official-path process on the save recovery page. Keep the backup outside the active save directory and label it with park, date, version, and before-coop.
Wait for Steam Cloud to finish before copying. Cloud support is useful but can synchronize an unwanted change; it is not a replacement for an untouched manual backup.
Open the backup only for recovery. The live multiplayer session should use the ordinary active save so your original evidence remains intact.
Define the test roles
Name one host and at least one joining client. Record which Steam account launches the park and whether it is a new or existing save. Have each player note their starting money display, position, tools, research view, and any personal or park-level progress shown.
Official notes allow up to four participants, but a two-person test is easier to interpret. Add more clients only after the basic save cycle works.
Avoid quests, irreversible purchases, or large construction during the first test. Use one small, identifiable change.
Make a traceable park change
Ask the host to place or move one harmless object and the client to perform a different harmless action. Record who performed each change and what both players saw.
If the game offers a save command or status indicator, capture it. Do not assume that an icon belongs to both local and host state. Wait for any visible activity to finish before leaving.
Use a unique landmark that can be checked after reload without relying on cash totals or counters that may change through ordinary operation.
Test a clean end-of-session cycle
Have the joining client leave through the current menu, then let the host end or save according to the public-build interface. Close the game and reload the park solo on the host account.
Check both traceable changes. Their presence demonstrates persistence in this tested sequence; it does not prove that the client owns a separate copy.
Next, have the former client start the game without the host and inspect only the park list. Do not edit or copy files to force a result. Record whether a relevant park appears and what the game calls it.
Test interruption only on a disposable copy
Disconnect and crash behavior can differ from a clean exit. Do not simulate it on the only version of a valuable park. Restore a test copy or create a new park, make one marker change, and reproduce a single interruption.
Afterward, preserve logs and inspect the host save. Record whether the client could reconnect, which change survived, and whether the game displayed a recovery message.
One outcome is evidence for that version and sequence. It does not establish universal disconnect persistence or host migration.
Do not infer cross-save
Steam metadata lists Steam Cloud for AppID 3293260. That means Steam offers cloud functionality for the product; it does not prove console cross-save, cross-account park transfer, or Demo backward compatibility.
The Demo has its own one-way migration rule and separate AppID. Follow the Demo guide rather than using co-op as a transfer method.
Local co-op, split screen, dedicated servers, and cross-play were not established by the 1.0 announcement. Do not write save advice that depends on those features.
Recover from an unexpected result
Stop opening the affected park repeatedly. Copy the current files and logs before restoring anything. Compare the active state with the untouched pre-co-op backup and follow CayPlay’s official recovery ordering.
Do not merge save files manually or replace individual internal files without developer guidance. A partial copy can create a state that neither host nor game wrote normally.
If restoring the backup, preserve the failed state separately for support. Report version, host and client roles, park origin, session exit method, Steam Cloud state, and the exact missing change.
Maintain a multiplayer park log
For recurring group play, note the host, park, session date, game version, participants, major construction, research or quest changes, and whether the host verified a solo reload. Keep periodic backups outside the active directory.
This routine gives the group a known owner for coordination without claiming an undocumented technical ownership rule. It also makes a later patch or failed session much easier to diagnose.