GAMEPLAY SCENARIO:
I’ll provide my desired gameplay sequence with my known solutions in parenthesis. I am hung up on steps #4 and #5, but maybe that’s because of my choices in steps 1-3:
A player joins the starter place which is public and begins playing with random public players in the same place [ Normal Roblox using a standard starter place ]
Some players in that specific instance decide to band together and teleport to a unique instance of a non-starter place that should not be accessible to any other players outside of that specific starter place except for special gameplay circumstances determined by server logic. The particular instance of this place should be re-visitable in future play sessions. [ Classic use-case for creating a Reserved Server? ]
The adventure on the non-starter place concludes, and the band of players now decide to teleport back to their specific starter place. Other players may have remained in or joined the starter place, so it is vital that the band returns to the same starter instance, as the other players are awaiting the heroes, and the starter instance might have experienced real-time changes based on the band’s choices in #2. [ Classic use-case for TeleportToPlaceInstance(JobID)? Real-time changes between servers are communicated via MessagingService and/or DataStores]
HOWEVER, somewhere between #2 and #3, the other players in the starter place may have logged off from the starter place, possibly leaving it empty during the adventure in #2, meaning the starter place may or may not exist by #3. If a new starter place is created for the band to return to, it must be specifically reflect the band’s choices in #2. Because of this, the band cannot return to any other pre-existing starter place, as all other public starter places have different gamestate. The chances of gamestate correctly reflecting #2’s choices on a randomly joined starter place is less than 1 in 10,000. [ TeleportToPlaceInstance(JobID) could result in a failed teleport because the JobID may have shut down from being an empty server. Do I have to keep track of whether JobID has shut down (how would I do that) and if so, make a ReservedServer and use TeleportToPrivateServer? ]
The cycle repeats back at #1, where the band of players are still in the same PUBLIC starter place that contains gamestate from past adventures. The band grows larger as more random players join the fray. [ If TeleportToPlaceInstance(JobID) worked, then all is fine. If the JobID shut down, then I don’t know what to do, because I’d have to re-teleport the band of players from a reserved server to another public server which is already populated and has its own gamestate ]
I did some testing on this situation.
Two players joined the starter place, and both of them changed the gamestate (dropped parts).
Player one teleports to a different place, waits 15 seconds, and then teleports back via JobID.
Since player two is still there, player one’s experience is seamless, and he sees what he expects to see…
If instead…
Player two leaves just after player one first teleports away.
This is what Player one sees when trying to teleport back to the starter place via JobID…
Now I could store the created parts via DataStore keyed to JobID or player or something and recreate the look of the place via ReservedServer, but then Player one is permanently by himself once he rejoins his “proper” looking starter place.
Any thoughts on any of this in terms of the best ways forward with existing Roblox tools (or external tools, like HTTP requests) are very much appreciated. I would like for Universe scripts to exist as well, but for now I’d like to stick with what we know can be used in May 2020.
There’s always going to be a case where the starter server closes. The only option I see is that you store the data in a datastore specific to the starter server and update any state changes in the “adventuring” places in that same datastore. Then, when the players return to the starter server, load the data back as you’ve mentioned.
Regarding playing with random people, make a lobby place that counts down until the “real” game starts, then reserve a server and use that as your starter place. Store the initial players in a datastore pointing to the reserved server to create a whitelist (assuming that you don’t want other players to join in the campaign after it’s started, otherwise, you don’t need this lobby idea).
The upcoming ephemeral datastores and universe scripts would be sooooooo useful for this though.
From what you’ve described, it seems like you’ve got an amazing game idea with! I’m excited to see where this leads.
For as much detail as I provided, you have it right. The thing I didn’t go into so much detail though is that the public starter place isn’t just some idle hub to be discarded by Roblox. Adventure can happen there too. I’m starting to think that both places aren’t appropriate for being a starter place.
Thanks for the ideas. I think there’s nothing for it but to use Reserved Servers for the whole thing and just manage where players go myself. I’m going to hold out a little longer on this post to see if anyone else is cleverer than us before marking a solution.
And thanks for the encouragement. I’ve been working on this game concept for 9 years and have tried 6 other game engines. I’ve gotten so close with Roblox that I think it’s going to be the one who wins out. I never would’ve guessed in 2017 that in 2020 I’d be ditching Unity for Roblox!
Hey I’m gonna quickly revive this thread cause I found something that might be beneficial. I don’t know the implications of this, such as whether it can be easily exploitable but this could be used for the “hub place” that you’ve described and then saved when all the players leave.
If you choose to use this I recommend creating an alt account as every place that gets created from this is placed into your inventory which can get annoying real quick, and I suppose which is a major con to this method.
Thanks for bringing this up and reminding me about this feature. I did consider this, but this solution did not seem scalable, and as you alluded to, I’d have to make a new account with every new version of the game…
Perhaps I’m wrong, and this is the best way to go. I’m not sure how to test how well this approach would hold up under a large player load, as universe save limits don’t seem to be outlined anywhere, and community leaders have called for this feature to be deprecated.
