Hi Creators,

Today, we’re excited to move Server Authority from Studio Beta into Client Beta!

Client Beta means you can publish games leveraging Server Authority. This allows you to move beyond local testing so you can begin iterating with your development teams, QA staff, and community members in live environments.

Pending issues you might find and some final polishing we’re already working on, we hope to fully launch in a few weeks. In the meantime, we recommend you publish privately or publish as an Experience Beta.

Understanding the “Client Beta” Phase

First, thank you to everyone who tried Server Authority and provided feedback in Early Access and Studio Beta releases! You found some issues that we were able to fix and had some great input we were able to implement! But until now it wasn’t feasible to test with multiple concurrent players in production.

Moving to Client Beta means you can now publish experiences using Server Authority! But this is still a Beta, so please keep a few things in mind:

• APIs Locked: APIs are now locked. That said, barring strong creator feedback, some APIs may change before General Availability based on your feedback. If this happens, you will have to make updates and republish.

• Mispredictions and Performance: We are working incredibly hard behind the scenes polishing mispredictions and performance issues. You should not need to make changes to your code to benefit from future improvements.

• Known Issues: Finally, there are still a few known bugs. These are discussed below.

Because this is a Client Beta, your game will be playable by anyone, but they may experience unexpected issues. We recommend publishing your experience privately or as an “Experience Beta” to enable testing with controlled groups (QA, dedicated fans, etc) rather than releasing to a wide public audience.

What’s New Since Our Last Update

General Improvements

We’ve been working hard since launching the Studio Beta.

• Mispredictions: Dramatically lowered mispredictions across a range of gameplay scenarios.

• Performance: Improved performance of rollback and resimulation.

• Studio UI: New UI in the Studio Workspace Properties for configuration of Server Authority prerequisites. These changes allow you to easily enable server authority and its prerequisites in a single section of the Workspace Properties widget.

• Instance Stitching: Client-side predictive Instance creation is now possible directly with Instance.new(). Instances created by the same script using BindToSimulation will be stitched together for a seamless experience. For example, if a player fires a rocket, they will see it appear immediately without having to wait for server confirmation.

• Animation improvements: We have made and are continuing to make improvements for animations in server authority. We are now fully compatible with the Adaptive Animations feature, and there is a new API (Animator:GetTrackByAnimationId) to help creators keep track of playing animations in server authority.

Latest and greatest Engine features required

Server Authority integrates our latest Engine features to ensure a consistent experience for every player:

• Fixed Frequency Physics: Server Authority utilizes fixed-step physics via RunService:BindToSimulation to ensure that simulations remain deterministic and fair across different client hardware. Learn more here.

• Next Generation Replication: An opt-in new replication system, also now in Client Beta. See FAQ for more information and look for a future Dev Forum post with even more details.

• Input Action System: Server Authority uses our latest input system. In fact, we recently updated the player scripts in PlayerScriptsUseInputActionSystem to rename some actions, separate out camera actions into their own contexts, and update the priorities of these contexts. For more tips on how to use IAS, see here.

• Instance Streaming: Server Authority depends on the client simulating only what it has locally. Instance Streaming provides that on-demand subset of the world. If the client guesses wrong (e.g., an object hasn’t arrived yet), the system rolls back and corrects when the data streams in. Streaming also speeds up join times and reduces memory usage. We know this is a significant change for experiences that weren’t built with streaming in mind. We recently published a dedicated best practices guide to help you convert to streaming.

How to get started with Client Beta

Follow these steps to enable Server Authority for your live testing:

1. If converting an existing game: if you’re converting an existing game to use Server Authority, consider creating a new copy of your game while you work on the changes.

2. Open the Workspace Properties Window: In Studio, locate the Server Authority section in the Workspace Properties panel (see below).

3. Enable

   a. NextGenerationReplication: Enabled
   b. PlayerScriptsUseInputActionSystem: Enabled
   c. SignalBehavior: Deferred
   d. StreamingEnabled: Enabled
   e. UseFixedSimulation: Enabled

4. Toggle Client Beta: Change the Server Authority setting to "Server”

5. Publish your Experience: Save and publish to Roblox. Consider publishing privately or as an Experience Beta until Server Authority leaves Client Beta

Get Building - Best Practices

The first thing you should try is simply getting your character Server Authoritative. If you followed the steps above for turning Server Authority on and you use the default character, then you should already have this; there’s nothing more to do! Your character is immune to physics-based exploits!!

To quickly test and see this working, run your game in Studio and increase the walking speed of your character via the console. You should see your character snap back as you try, but fail to move at a speed the server considers invalid.

Then, consider your core game loop and what is most important to keep safe from cheaters. For example, you may want to focus on a ball in a sports game, or that game’s current score. We recommend using the patterns in your game logic to convert your game to server authority:

• Use shared code: Put your predicted core game logic in a ModuleScript in ReplicatedStorage. Connect your update loop to RunService:BindToSimulation on both the client and the server to keep them in sync.

• Handle input: Use InputActions cloned under each player for all player inputs (like movement or abilities) that affect the core game simulation. These are synchronized and forwarded to the server, and they are the only client data that the server trusts.

• Use attributes for game state: Game state, such as health or ammo, should be stored in attributes on predicted Instances. This will ensure that this state is rolled back when there has been a misprediction. Luau variables in scripts are not rolled back, so make sure you use attributes for synchronized game data.

Check out our Server Authority documentation here for in-depth details on how to get started, best practices, and advanced techniques.

Next Steps and Feedback

Our goal is to move out of Client Beta and into a general release as soon as we can. To help us get there, keep providing feedback as comments to this post.

Thank you, we’re almost there!
The Server Authority Team