CayPlay confirme que le multijoueur de Waterpark Simulator 1.0 peut commencer un nouveau parc ou charger un parc existant. L’annonce de sortie ne définit pas qui possède le parc sauvegardé, ce qu’un client qui rejoint conserve, si une migration d’hôte existe ou comment une session interrompue valide les changements.
Protégez les parcs importants et testez explicitement ces questions. Cette page est un protocole de sécurité des sauvegardes, non l’affirmation qu’un modèle de propriété non vérifié s’applique.
Sauvegardez d’abord le parc de l’hôte
Fermez le jeu proprement et préservez la sauvegarde à l’aide de la procédure de chemin officiel de la page de récupération des sauvegardes. Gardez la copie de sauvegarde hors du répertoire de sauvegarde actif et étiquetez-la avec le parc, la date, la version et before-coop.
Attendez que Steam Cloud ait terminé avant de copier. La prise en charge Cloud est utile, mais peut synchroniser un changement indésirable ; elle ne remplace pas une sauvegarde manuelle intacte.
Ouvrez la copie de sauvegarde uniquement pour la récupération. La session multijoueur en direct doit utiliser la sauvegarde active ordinaire afin que votre preuve d’origine reste intacte.
Définissez les rôles de test
Nommez un hôte et au moins un client qui rejoint. Notez quel compte Steam lance le parc et s’il s’agit d’une nouvelle sauvegarde ou d’une sauvegarde existante. Demandez à chaque joueur de relever son affichage de trésorerie initial, sa position, ses outils, sa vue de recherche et toute progression personnelle ou au niveau du parc affichée.
Les notes officielles autorisent jusqu’à quatre participants, mais un test à deux personnes est plus facile à interpréter. N’ajoutez plus de clients qu’après avoir vérifié le cycle de sauvegarde de base.
Évitez les quêtes, les achats irréversibles ou les grandes constructions durant le premier test. Utilisez un seul petit changement identifiable.
Effectuez un changement de parc traçable
Demandez à l’hôte de placer ou déplacer un objet inoffensif et au client d’effectuer une autre action inoffensive. Notez qui a effectué chaque changement et ce que les deux joueurs ont vu.
Si le jeu propose une commande de sauvegarde ou un indicateur d’état, capturez-le. Ne supposez pas qu’une icône appartient à la fois à l’état local et à l’état de l’hôte. Attendez la fin de toute activité visible avant de quitter.
Utilisez un repère unique pouvant être vérifié après le rechargement sans vous fier aux totaux de trésorerie ou aux compteurs susceptibles de changer pendant l’exploitation normale.
Testez un cycle de fin de session propre
Demandez au client qui rejoint de partir via le menu actuel, puis laissez l’hôte terminer ou sauvegarder selon l’interface de la version publique. Fermez le jeu et rechargez le parc en solo sur le compte de l’hôte.
Vérifiez les deux changements traçables. Leur présence démontre une persistance dans cette séquence testée ; elle ne prouve pas que le client possède une copie distincte.
Ensuite, demandez à l’ancien client de lancer le jeu sans l’hôte et d’inspecter uniquement la liste des parcs. Ne modifiez ni ne copiez de fichiers pour forcer un résultat. Notez si un parc pertinent apparaît et comment le jeu le nomme.
Testez l’interruption uniquement sur une copie jetable
Le comportement des déconnexions et des crashs peut différer d’une sortie propre. Ne le simulez pas sur l’unique version d’un parc de valeur. Restaurez une copie de test ou créez un nouveau parc, effectuez un changement repère et reproduisez une seule interruption.
Ensuite, préservez les journaux et inspectez la sauvegarde de l’hôte. Notez si le client a pu se reconnecter, quel changement a survécu et si le jeu affichait un message de récupération.
Un résultat est une preuve pour cette version et cette séquence. Il n’établit ni une persistance universelle après déconnexion ni une migration d’hôte.
N’en déduisez pas le cross-save
Les métadonnées Steam répertorient Steam Cloud pour l’AppID 3293260. Cela signifie que Steam propose une fonctionnalité Cloud pour le produit ; cela ne prouve pas le cross-save console, le transfert de parc entre comptes ou la compatibilité descendante de la Demo.
La Demo possède sa propre règle de migration à sens unique et un AppID distinct. Suivez le guide de la Demo plutôt que d’utiliser la coop comme méthode de transfert.
La coop locale, l’écran partagé, les serveurs dédiés et le cross-play ne sont pas établis par l’annonce de la 1.0. N’écrivez pas de conseils sur les sauvegardes qui dépendent de ces fonctionnalités.
Récupérez après un résultat inattendu
Arrêtez d’ouvrir le parc concerné à répétition. Copiez les fichiers et journaux actuels avant de restaurer quoi que ce soit. Comparez l’état actif avec la sauvegarde intacte antérieure à la coop et suivez l’ordre de récupération officiel de CayPlay.
Ne fusionnez pas manuellement des fichiers de sauvegarde et ne remplacez pas des fichiers internes individuels sans conseils du développeur. Une copie partielle peut créer un état que ni l’hôte ni le jeu n’ont écrit normalement.
Si vous restaurez la copie de sauvegarde, préservez séparément l’état en échec pour l’assistance. Signalez la version, les rôles d’hôte et de client, l’origine du parc, la méthode de sortie de session, l’état de Steam Cloud et le changement exact manquant.
Tenez un journal du parc multijoueur
Pour des parties de groupe récurrentes, notez l’hôte, le parc, la date de session, la version du jeu, les participants, les changements majeurs de construction, de recherche ou de quête, et si l’hôte a vérifié un rechargement solo. Gardez des sauvegardes périodiques hors du répertoire actif.
Cette routine donne au groupe un propriétaire connu pour la coordination sans prétendre à une règle technique de propriété non documentée. Elle rend aussi beaucoup plus facile le diagnostic d’un patch ultérieur ou d’une session en échec.