Today, we’re launching the beta of Party Simulator, a plugin that lets you build, test, and debug party-based logic in Server and Clients playtests.
With the Party Simulator, you can validate any logic that depends on Player.PartyId, GetPartyAsync, or GetPlayersByPartyId without publishing or coordinating multiple devices and accounts. We’ve heard your feedback on wanting more tools to test Party integrations in Studio, so this plugin should significantly shorten iteration cycles and improve reliability for experiences that integrate the Party API.
With this new feature, we are excited to empower you to create richer, more connected experiences for parties of users to play together.
We’re working on expanding supported use cases for Party API, enabling more impactful Party integrations, and driving retention among users playing with a party. Party Simulator will exit beta later this year, with more Party API updates expected next year!
I’m always spooked using features that aren’t predictable so this is a huuuuge help for debugging!
Some time ago I was working at a studio (doesn’t exist anymore) where we spent a good chunk of time developing a party system between universes and whatnot
This is a great way to test things and build features around parties, so thank you! Can just imagine the applications beyond gameplay- QA testing suites and whatnot… thank you!
I was testing this and noticed that Player.PartyId returns the valid ID string on the server, but it’s just an empty string when checked from a client (LocalPlayer.PartyId).
Is this intended behavior (where the client isn’t supposed to see the ID) or a bug with the simulation?
This is the intended behavior. Currently, the Player.PartyId property is only accessible from the Server.
We would love to hear any use cases you have in mind that would depend on Player.PartyId being accessible from the client. Feel free to send me a message here on the DevForum.
Nice addition.
We would still need more control over party creation and invitation handling (such as pending invites, accepting/rejecting) that are not yet present in the Party API.
I agree. Having a button to switch to other player’s perspective would rather be nice than having all controlled each on a single window which can take long enough time to be initiated with developers on a low-end device
Or even, make it as a setting so that developers can switch preferences to how they’d like to test the game in a simulated amount of players
If you already have a functional party system in your game then you could be utilizing Roblox’s parties to pair players together in your game automatically. It’s not useless to have access to this information