Waterpark Simulator mises à jour

Waterpark Simulator est entré en Early Access le 22 août 2025 et a atteint la version 1.0 le 31 juillet 2026. Ces dates établissent la limite pour cette construction en langue par défaut. Les pages du wiki décrivent le jeu de l'ère 1.0 et étiquettent leur date de vérification afin que les lecteurs ultérieurs puissent distinguer une référence actuelle d'un guide non daté écrit pendant l'Early Access.

L'identité principale reste un simulateur de gestion à la première personne développé et édité par CayPlay. Les joueurs construisent des toboggans et des piscines, vendent des billets et de la nourriture, effectuent des sauvetages, des réparations et du nettoyage, embauchent du personnel et travaillent pour des visiteurs plus heureux. La note du parc reflète la propreté, le plaisir des toboggans, la qualité de la nourriture et le bonheur des clients, tandis que la version 1.0 fixe l'objectif de progression : construire un parc cinq étoiles.

Une chronologie ne remplace pas une archive complète des correctifs. Cette page ne recense que les jalons et les systèmes nommés pris en charge par la transmission. Elle ne prétend pas avoir capturé tous les ajustements d'équilibrage, corrections de bugs, changements d'interface ou valeurs cachées de la transition vers la version 1.0. Utilisez l'annonce officielle liée pour le contexte de publication original daté.

L'annonce de la version 1.0 prend en charge les sessions multijoueur où un hôte peut jouer avec jusqu'à trois amis ou inconnus, soit quatre joueurs au total. Un chat vocal de proximité optionnel fait partie du format annoncé. Cela change la façon dont une session de parc peut être organisée : les joueurs peuvent répartir la construction, le service aux visiteurs, le nettoyage, les réparations, les sauvetages et la supervision du personnel tout en partageant le même objectif d'exploitation.

L'annonce ne fournit pas de modèle de synchronisation vérifié, de règle de migration de l'hôte, de matrice d'autorisations ou d'attribution de rôles universelle. Le guide multijoueur traite donc l'hôte comme le point d'ancrage de la session et recommande une communication explicite plutôt que de présenter des garanties techniques non étayées. Le chat vocal de proximité est optionnel, donc un groupe doit décider comment il communiquera avant de se répartir dans le parc.

Le multijoueur élargit le format de jeu sans remplacer les systèmes principaux. Le parc a toujours besoin de toboggans et de piscines cohérents, de billets et de nourriture, de travail de réponse directe, de personnel et d'attention aux entrées de la note. Un groupe plus large peut couvrir plus d'espace, mais le matériel source n'établit pas de multiplicateur d'efficacité numérique. Jugez la valeur d'une répartition des rôles à partir de la session en direct plutôt que de tableaux de productivité inventés.

Version 1.0 ajoute la carte Plage. L'annonce officielle indique que les joueurs doivent créer un nouveau parc car les agencements ne sont pas transférés. C'est le fait central de planification : Plage n'est pas un skin visuel appliqué à un agencement existant. Traitez-le comme une construction séparée avec ses propres décisions de toboggans, piscines, chemins et opérations, et conservez le parc d'origine sans supposer que la nouvelle carte héritera de sa structure.

La même mise à jour nomme les thèmes Aztec, Sea et Pirate. Ceux-ci appartiennent à l'expansion de recherche décrite via le Musée, et non à une liste confirmée de cartes séparées. La transmission ne fournit pas de coûts de déverrouillage exacts, d'ordre de branches ou de bonus de performance pour les thèmes, donc les pages Cartes et Recherche maintiennent séparées l'identité de la carte et la progression des thèmes.

Cette distinction est importante lors de la planification du contenu et des sauvegardes. « Carte » répond à l'endroit où le parc est construit ; « thème » répond en partie à la façon dont le contenu recherché peut façonner sa direction visuelle. Combiner les termes en une liste de cartes non étayée déformerait l'annonce de la version 1.0. Utilisez la référence Plage pour l'exigence de nouveau parc et la référence Recherche pour les trois thèmes nommés.

Version 1.0 prend en charge la personnalisation des personnages avec jusqu'à cinq emplacements sauvegardés. Cela donne à un joueur ou à un groupe multijoueur un moyen documenté de conserver plusieurs apparences, mais l'annonce n'établit pas de bonus de jeu pour les choix d'apparence. La page Personnages traite la personnalisation comme une présentation et la maintient séparée des fonctions du personnel.

Les ajouts de personnel nommés ont des rôles confirmés distincts. La sécurité expulse les mauvais visiteurs. Les mascottes augmentent l'amusement et le bonheur. Les Star Staff sont des personnages membres de l'équipe embauchables. Ces déclarations sont la limite fiable ; les efficacités précises, les salaires, les horaires et les seuils de déverrouillage ne sont pas fournis dans les preuves scellées. Un plan de gestion doit utiliser chaque rôle pour son objectif décrit et vérifier les valeurs en direct dans l'interface actuelle du jeu.

La recherche est organisée via un Musée avec trois PNJ de quête, trois monnaies et trois branches de recherche. L'annonce de la version 1.0 nomme également les thèmes Aztec, Sea et Pirate. La transmission n'expose pas l'arbre de branches complet ni les exigences exactes des quêtes, donc ce wiki présente la structure sans fabriquer d'ordre de nœuds. Cela laisse l'interface en direct du Musée comme autorité pour l'état de progression actuel du joueur.

• Personnalisation des personnages : jusqu'à cinq emplacements sauvegardés.
• Sécurité : expulse les mauvais visiteurs.
• Mascottes : augmentent l'amusement et le bonheur.
• Star Staff : personnages membres de l'équipe embauchables.
• Recherche au Musée : trois PNJ de quête, trois monnaies et trois branches.
• Thèmes de recherche nommés : Aztec, Sea et Pirate.

L'annonce de la version 1.0 identifie deux modificateurs opérationnels plus larges. L'exploitation de nuit affecte la paie des employés et le comportement des tricheurs. La météo peut fournir des bonus ou des pénalités. Ces faits sont importants car un même agencement de parc peut être confronté à différentes conditions d'exploitation, mais l'ensemble des sources scellées ne fournit pas de tableau numérique complet pour chaque état temporel ou météorologique.

Utilisez les modificateurs comme raisons de réévaluer le personnel, l'attention directe du joueur et le service aux visiteurs. Une session de nuit peut changer le contexte de la main-d'œuvre et des mauvais visiteurs, tandis que la météo peut modifier l'équilibre des avantages et des inconvénients dans le parc. Gardez un œil sur la propreté, le plaisir des toboggans, la qualité de la nourriture et le bonheur des clients plutôt que de supposer qu'une condition visuelle ne modifie qu'une seule entrée de note.

Le guide de gestion du parc porte l'ordre de révision pratique. Cette page de mise à jour enregistre que les systèmes font partie de la version 1.0 et préserve la limite des preuves. Elle ne classe pas les types de météo, ne publie pas de valeurs salariales non étayées, ni ne revendique une réponse garantie applicable à tous les parcs.

Pour toute mise à jour ultérieure, enregistrez d'abord la date de publication et la version. Séparez ensuite le nouveau contenu des modifications apportées aux systèmes existants. Enfin, identifiez les routes du wiki qui dépendent du fait modifié. Cette petite discipline empêche qu'une nouvelle carte, un nouveau thème, un rôle de personnel ou un nombre de succès soit copié dans des pages sans rapport sans contexte.

Privilégiez une annonce officielle, une page de boutique ou un site officiel pour les changements factuels. Limitez les observations de l'interface à la version et ne convertissez pas une capture d'écran en valeur exacte à moins que la source ne la présente clairement comme telle. Lorsqu'une déclaration n'est plus d'actualité, mettez à jour la date de vérification de la page concernée et conservez suffisamment de contexte chronologique pour qu'un lecteur puisse comprendre pourquoi les conseils antérieurs diffèrent.

L'instantané actuel est volontairement étroit : accès anticipé le 22 août 2025, version 1.0 le 31 juillet 2026, et les systèmes nommés ci-dessus. Cela rend la page maintenable. Une future mise à jour de contenu Stage60 peut étendre la chronologie sans reconstruire l'architecture des routes ni réécrire les pages de jeu en langage non vérifié et non par défaut.

1. Enregistrez la date de mise à jour et la version à partir d'une source officielle.
2. Séparez le nouveau contenu, les systèmes modifiés et les correctifs avant de modifier les affirmations du wiki.
3. Mappez chaque changement vérifié au plus petit ensemble de routes pertinentes.
4. Mettez à jour les dates de vérification et les liens sources sans effacer le contexte chronologique utile.
5. Laissez de côté les valeurs et mécanismes non étayés jusqu'à ce qu'une preuve liée à une version existe.