Waterpark Simulator updates

Waterpark Simulator entered Early Access on August 22, 2025 and reached version 1.0 on July 31, 2026. Those dates establish the boundary for this default-language build. Pages on the wiki describe the 1.0-era game and label their verification date so later readers can distinguish a current reference from an undated guide written during Early Access.

The core identity remains a first-person management simulator from developer and publisher CayPlay. Players build slides and pools, sell tickets and food, perform rescues, repairs, and cleaning, hire staff, and work toward happier guests. Park rating reflects cleanliness, slide fun, food quality, and guest happiness, while the 1.0 release frames the progression goal as building a diamond five-star park.

A timeline is not a substitute for a full patch archive. This page records only the milestones and named systems supported by the handoff. It does not claim that every balance adjustment, bug fix, interface change, or hidden value from the transition to 1.0 has been captured. Use the linked first-party announcement for the original dated release context.

The 1.0 announcement supports multiplayer sessions in which a host can play with up to three friends or strangers, for four players total. Optional proximity voice is part of the announced format. This changes how a park session can be organized: players can divide construction, guest-facing service, cleaning, repairs, rescues, and staff oversight while sharing the same operating goal.

The announcement does not provide a verified synchronization model, host-migration rule, permission matrix, or universal role assignment. The Multiplayer guide therefore treats the host as the session anchor and recommends explicit communication rather than presenting unsupported technical guarantees. Proximity voice is optional, so a group should decide how it will communicate before splitting across the park.

Multiplayer expands the operating format without replacing the core systems. The park still needs coherent slides and pools, tickets and food, direct response work, staff, and attention to rating inputs. A larger group can cover more space, but the source material does not establish a numeric efficiency multiplier. Judge the value of a role split from the live session rather than from invented productivity tables.

Version 1.0 adds the Beach map. The official announcement states that players need to start a new park because layouts do not transfer. That is the central planning fact: Beach is not a visual skin applied to an existing layout. Treat it as a separate build with its own slide, pool, path, and operating decisions, and preserve the original park rather than assuming the new map will inherit its structure.

The same update names Aztec, Sea, and Pirate themes. These belong to the research expansion described through the Museum, not to a confirmed list of separate maps. The handoff does not provide exact unlock costs, branch order, or performance bonuses for the themes, so the Maps and Research pages keep map identity and theme progression separate.

This distinction matters when planning content and saves. “Map” answers where the park is built; “theme” answers part of how researched content can shape its visual direction. Combining the terms into an unsupported map list would misstate the 1.0 announcement. Use the Beach reference for the new-park requirement and the Research reference for the three named themes.

Version 1.0 supports character customization with up to five saved slots. That gives a player or multiplayer group a documented way to retain multiple looks, but the announcement does not establish gameplay bonuses for appearance choices. The Characters page treats customization as presentation and keeps it separate from staff functions.

The named staff additions have distinct confirmed roles. Security removes bad visitors. Mascots increase amusement and happiness. Star Staff are hireable team-member characters. Those statements are the reliable boundary; precise efficiencies, wages, schedules, and unlock thresholds are not provided in the sealed evidence. A management plan should use each role for its described purpose and verify live values in the current game interface.

Research is organized through a Museum with three quest NPCs, three currencies, and three research branches. The 1.0 announcement also names Aztec, Sea, and Pirate themes. The handoff does not expose the complete branch tree or exact quest requirements, so this wiki presents the structure without fabricating node order. That leaves the live Museum interface as the authority for the player’s current progression state.

• Character customization: up to five saved slots.
• Security: removes bad visitors.
• Mascots: increase amusement and happiness.
• Star Staff: hireable team-member characters.
• Museum research: three quest NPCs, three currencies, and three branches.
• Named research themes: Aztec, Sea, and Pirate.

The 1.0 announcement identifies two broader operating modifiers. Night operation affects employee pay and cheater behavior. Weather can supply bonuses or penalties. These facts are important because the same park layout can face different operating conditions, but the sealed source set does not provide a complete numeric table for every time or weather state.

Use the modifiers as reasons to reassess staffing, direct player attention, and guest-facing service. A night session may change the labor and bad-visitor context, while weather can change the balance of advantages and disadvantages around the park. Keep one eye on cleanliness, slide fun, food quality, and guest happiness rather than assuming that a visual condition changes only one rating input.

The Park Management guide carries the practical review order. This update page records that the systems are part of version 1.0 and preserves the evidence boundary. It does not rank weather types, publish unsupported wage values, or claim a guaranteed response that applies to every park.

For any later update, record the publication date and version first. Then separate new content from changes to existing systems. Finally, identify which wiki routes depend on the changed fact. This small discipline prevents a new map, theme, staff role, or achievement count from being copied into unrelated pages without context.

Prefer a first-party announcement, store page, or official site for factual changes. Keep interface observations version-bound and do not convert a screenshot into an exact value unless the source clearly presents it as such. When a statement is no longer current, update the relevant page’s verification date and preserve enough timeline context that a reader can understand why older guidance differs.

The current snapshot is intentionally narrow: Early Access on August 22, 2025, version 1.0 on July 31, 2026, and the named systems above. That makes the page maintainable. A future Stage60 content update can extend the timeline without rebuilding the route architecture or rewriting unverified non-default language game pages.

1. Record the update date and version from a first-party source.
2. Separate new content, changed systems, and fixes before editing wiki claims.
3. Map each verified change to the smallest relevant route set.
4. Update verification dates and source links without erasing useful timeline context.
5. Leave unsupported values and mechanics out until version-bound evidence exists.