aLekSer
commented
3 years ago I am working on Situation: Player Transitions Between 2 World Servers While Exploring to show it with Backfill in an OM demo fasion https://open-match.dev/site/docs/getting-started/ .
Is your feature request related to a problem? Please describe. This is not related to a bug or known short-coming. It is more of a discussion on whether changes are needed in Open Match to facilitate a certain use case.
Describe the solution you'd like I'd like to come to a conclusion on whether changes are needed to Open Match to facilitate this use case.
Describe alternatives you've considered I have considered how the new backfill feature might fill this need. You can see how backfill might be used to fill this need in each of the possible solutions below.
Additional context
Description of Drop-in/out Gameplay
Customers want to be able to provide gamers the flexibility for different matchmaking and have the ability to move around between multiple zones in large open worlds that may exist on different game server, as well as different instanced game sessions that are PVE, PVP, raids, dungeons, etc. Gamers would be allowed to transition between all these worlds and casually drop-in/Drop-out of various parts of the large open world.
One example, a game would have a world with 7 zones, with up to 200 people per zone. As a gamer explores these worlds, they could explore into a PVE/PVP activity in that single game and that single game session could hold up to 2 thousand users. Imagine a world zone that is as large as a Fortnite physical zone with the capability of seamless transitions between these 7 zones. Studios would want the capability to match across these 7 zones. A player could match to a PVP world and then, if killed in PVP they would get matched back into the PVE world realm. Then players would get matched again, then shoved back into PVP if the gamer chooses to do so or they could stay in PVE but the player has the flexibility to transition in-n-out of these zones.
Specific Use Cases & Possible Solutions
Description of Drop-in/out Gameplay
Situation: Party Leaves world server for Instanced Side-Quest
Player1 & Player2 are playing an online RPG on a world server with many other players, where they explore, trade, chat, etc. Player1 and Player2 decide to become a party and go on a quest together. There is a fleet of game servers in Agones running which are able to run that quest, and there is a Match Profile and Match Function in Open Match which are trying to create matches for this quest. Player1 and Player2 submit match-making requests to Open Match for this quest and get matched into it (or the party leader sends a single request for the party). Once they are done playing their quest the whole party will return to the same type of world server they were on initially.
Possible Solution 1: Players ask World Server to Hold Their Spot & Disconnect
Prior to connecting to the quest instance server, the game clients save the connection info for the world game server they are on, send a message to the world game server asking it to save their spots for X amount of time (the average amount of time needed to complete this quest), then disconnect from the world game server and join the instance server. Once they near the end of their quest, the game clients attempt to re-connect to the world server in the background. If they can connect and join the world server, then the game client transitions the players back to that world server when they finish their quest. If they cannot connect and join the world server, the game client submits a match-making ticket to get put into another instance of world server that is of the same type as what they were originally in. If the world game server does not see the client attempt to re-connect after X amount of time, it expires the player's saved spot and removes any of its session information. The sequence diagram below shows how this solution could work. It uses a Party system where there is a single party leader who manages what servers the party should connect to.
Possible Solution 2: Players Maintain Idle Connection To World Server While on Side Quest
This solution is similar to Solution 1 in setup. It differs after the game clients find a game server to connect to. The game clients never disconnect from the original world server, they just send a message telling it that the client is going into a quest. The world server will then remove the physical presence of the player from the world server, but maintain the connection with the client. The players join the quest instance as described in Solution 1, play their quest, and then just re-use the existing connection they have to the world server when they are done with the quest. Potential Issues:
Possible Solution 3: Players Disconnect From World Server & Match-make Back Into A World Server Later
This solution is similar to Solution 1, and is for cases where clients don't need to go back to the original world servers they were on when a side quest is over. This solution differs from Solution 1 after the game clients find a game server to connect to. Once they connect to a side-quest game server, the clients disconnect from the world server without making any reservation indicating they will be back. The game clients would just disconnect from the world server once they enter a quest instance (via match-making), and once they were close to the end of their quest, they would submit a match-making request to get matched back into a world game server. The existing world game server would have backfill tickets registered in Open Match, and the players would get matched into an existing world server of the type they were originally in, although it may not be the same instance for both players, and it may not be the same server instance that they were originally connected to. Potential Downsides: If all world servers are full, it may take extra time to get a new one up and running, and have players leaving side quests connect to it If players had gotten used to the community of a world server prior to going on a side quest, they may not like being put on a world server that is different than the original after their side quest is done
Situation: Player Transitions Between 2 World Servers While Exploring
Player1 is walking toward the edge of a region in a massively multiplayer online game and they want to continue traveling in that direction, which would result in them entering a different region, which is hosted on a different type and instance of world game server. We want their transition between regions and servers to happen as quickly as possible. We also want the player to be able to quickly transition back to the previous region and server as quickly as possible if the player decides they want to exit the new region immediately after entering it.
Possible Solution 1: Match-make Into Next Region As Approaching Border
The world server that the player is currently on sends a message to the game client when they are with-in X minutes of travel (2 minutes?) of the edge of their current world. When the game client receives the message, it creates a match-making ticket in Open Match asking to be matched with any backfill requests coming from world servers of the type the player is nearing. Open Match matches the player's ticket to the world server's backfill ticket, and the player becomes assigned when the world server acknowledges its backfill. The player now has a slot reserved on the world server they are nearing. The game client gets the server connection info back from Open Match and makes a connection to the world server the player is near. If the player travels into the new region, the game client will send signals to the previous and new world servers that the player has transitioned regions. If the player does not travel back to the previous region (after X amount of time, or if they travel far enough away from the border), the game client will just disconnect from that world server and the previous world server will update its backfill requests to ask for an additional player. If the player decides to go straight back to the previous world server, the game client will again send 'transitioning regions' signal to both world servers.
Situation: Party Transitions Between 2 World Servers While Exploring
Player1 and their party are walking toward the edge of a region in a massively multiplayer online game and they want to continue traveling in that direction, which would result in them entering a different region, which is hosted on a different type and instance of world game server. We want their transition between regions and servers to happen as quickly as possible. We also want all the players to transition to the same instance of the next region. Lastly, we also want the player and their party to be able to quickly transition back to the previous region and server as quickly as possible if the players decide they want to exit the new region immediately after entering it.
Possible Solution 1: Match-make Into Next Region When Party Leader Approaches Border
Handle this in a similar fashion to the way we do single player transitions, except the party leader is the only party member being tracked. If the leader enters a bounding box at the edge of the current server's world, then everyone in the party is notified that they should begin party match-making. Match functions and Match profiles in Open Match would be setup to handle identifying the party's ticket and which backfill ticket the party should be assigned to. All party members would get the assignment info for the next server once the backfill was acknowledged by that server. One difficulty with this option is that members of the party that are non-leaders might travel toward the world boundary prior to the leader getting there. To prevent this from being an issue the game server or client would need to set up some artificial and temporary boundary to prevent those wandering party members from traveling to the edge of the map.
Possible Solution 2: Match-make Into Next Region When Any Party Member Approaches Border
Handle this in a similar fashion to the way we do single player transitions. If any party member approaches the world boundary they send out a message to their party members to start party match-making for the server that hosts the next region. Match functions and Match profiles in Open Match would be setup to handle identifying the party's ticket and which backfill ticket the party should be assigned to. All party members would get the assignment info for the next server once the backfill was acknowledged by that server. One difficulty with this option is that some party members may not know where a server's boundary is, and will accidentally enter it. To prevent this, some games may want to interrupt play and ask for the player to confirm that they want to continue traveling into the new region with their party.
Situation: Game Client Joins as Spectator, Then Becomes Player, Then Goes Back To Spectator
A player (Player1) joins an already running game as a spectator. There are many more spectators than there are actual players playing the game, and spectators just watch the game and chat. The game transitions into a phase where spectators are allowed to try and become actual players in the game. There are still a limited number of slots for actual players, but some players have left those slots, and some spectators will be able to claim those spots. Player1 claims one of the open player slots and plays in the next round. Once the round is done, Player1 opts to become a spectator again.
Possible Solution 1: Spectator Backfilled Into Player Spot
The game server issues a backfill ticket which has a player_type of 'spectator' that Open Match stores and a count of open spectator slots. There is also a Match Profile for the current game type, which has a Pool containing spectator backfill tickets, and another for players requesting spectator spots. The Match Function matches the spectator backfill tickets with the spectator request tickets. Open Match sends the server connection info to the game client when the game server acknowledges its backfill ticket, while the Director stores the player's info to the game server. The game client gets the connection info and connects to the game server as a spectator. The game server verifies the client's data against the player data it received from the Director. After some time passes, the game server decides to make some under-performing players spectators again, or maybe they decide on their own to become spectators. To do this, the game server updates any out-standing backfill tickets to now reflect fewer open spectator spots, and then sends a signal to the players that they are now spectators. The game server also updates its existing backfill ticket’s extension data to indicate there are open slots for a player_type of 'spectator_to_player_backfill'. The number of available slots for ‘spectator_to_player_backfill’ will be equal to the number of players that left or were downgraded to spectators. The backfill will also be updated with a new session ID matching the next session ID. All spectators are also presented with a choice by their game clients, asking if they want to participate in the actual game. Game clients that want to participate create match requests in Open Match with a player_type of 'spectator_to_player', and also the session ID for the game. Open Match has a Match Profile for this game type that includes a Pool for the spectator_to_player_backfill tickets, and another with the spectator_to_player request tickets. The Match Function matches the player requests with the backfill tickets, and the game clients are notified when the game server acknowledges its backfill ticket. The Director also sends the player's info to the game server, updating the existing data with the new match info indicating the player is a real player. The game server sends a message to the game client indicating that it should become a real player. The game server upgrades the player to an actual player.