"Player Location" custom session/matchmaking id
-
Hello!
I'm migrating my Mongo data and game service, and I'm hoping for the best BrainCloud (cloud api) recommendations/pointers in the right direction for the below situation:
Players are assigned a session Id represented as a ship or location in-game. Players can connect if the player shares with them the session id. The session Id should be hidden from those it is not shared, hidden from matchmaking until requirements are met.
Is this a case of simply using ProfileId as the session Id? It seems a little unsafe. Let's say we have a social hub, and you have access to other player's profile id to common shared things such as avatars nicknames etc- now you could potentially join anyone's session or location even if they haven't entered the matchmaking pool yet.
Each "location"/session which persists also progresses along with the player, so in addition to a simple key-value Id ships/sessions get upgrades, so I guess this is the case for a player-owned entity?
Location Ids (essentially a session/room at a given location, within the game server):
Q: Where is this "location" (current per-player server) id best stored?
- Can be shared with friends, and once shared the friend can re-join provided it's saved somewhere
- Player can't modify it; only cloud api changes it
- Tied to matchmaking if the player meets requirements (has no shield, is within the same region ie (CA/US) and meets the XP requirements) this id will be presented as a means to join (raid) the player's session.
Thank you for your time!
-
Hi @devsleeper ,
I think I'd recommend you model "Location" as a Custom Entity collection. You can use the "entityId" as your shareable id... and include custom attributes in the "data" section of the object - like "data.includeInMatchmaking", etc...
It would probably best be an "Owned" entity - so if the user account that owns it is deleted - it is deleted as well.
I hope that helps!
Paul.
-
@Paul-Winterhalder Thanks, I ended up going with Entities/Groups for character/location business.
Since locations are player-owned and (which I forgot to mention) can have crew members/roles groups seemed to make the most sense with the builtin invites etc, using the group Id as the shareable Id as you mentioned for entities.
For matchmaking I see we have GetRandomGroupsMatching so I think that works out great!
-
D devsleeper has marked this topic as solved
-
Ah - perfect. Yeah - that sounds like a better option given the full requirements.
Glad you found it... and welcome to brainCloud!
