How They Work

There are three key aspects to grasp about sessions: how the capacity of a deployment is managed, how to create and manage deployments to host sessions, and how to select the most suitable deployment for each session request.

Managing Capacity: Understanding Sessions in Deployment

Managing the capacity of a deployment depends on a core decision based on your specific needs. We manage sockets on our side, filling them up to a certain limit. You just need to indicate how you want these sockets to be filled.

We provide two options: seat-type session or match-type session. We'll help you understand the differences between these session types and choose the one that best suits your deployment capacity management needs.

Seat-Type Session

With seat-type session, each player from your sessions in your deployment occupies one socket space. For example, if your deployment has ten sockets, a solo player and a party of four players would take up five sockets out of the ten. If you delete the session of the party, the used socket count would now be one.

Match-Type Session

With match-type session, each session from your deployment occupies one socket space independently of how many players are in the session. For example, if your deployment has five sockets, you could have three games of ten players and it would count as three sockets out of the five, even if you have 30 players connected. If you delete the sessions with ten players, the used socket count would now be two.

This type can be really useful if you have a game server with high resource requirements overhead. For instance, you may need 2 vCPUs and 4 GB of RAM to load multiple assets, but once loaded, your server can handle multiple games on the same instance. This approach can save you a lot of money in the long run as you don't need to require 2 vCPUs and 4 GB of RAM for every game. Instead, you can split the cost across multiple match sessions on the same deployment.

In both cases, when you create a session request, we will ensure to choose the best deployment to host your session that has enough available sockets, based on the session type you have chosen (either "seat-type" or "match-type").

Creating and Managing Deployments for Sessions

In the previous page, we mentioned the option of automating the process of creating deployments to host your sessions. There are two ways to create deployments for your sessions.

1. Custom Backend System: You can create a system in your backend that creates deployments as needed for your sessions. This approach may be more suitable if you have specific requirements or need more control over the deployment process.

2. Autodeploy Option: Alternatively, you can activate the autodeploy option in your application version. This will automate the deployment creation process for your sessions, making it more convenient and streamlined. Each time you request a session, if there is no available deployment, the system will automatically spin up a new one in a matter of seconds, and then link your session to it. This ensures that your sessions are hosted in a timely manner, even if there are no existing deployments available at the time of your request.

This option is incredibly powerful because it enables you to rapidly deploy game servers in locations where your players need them. When activated, it distributes the load across multiple locations and balances it over time, grouping players on the most popular servers and automatically closing the least popular ones (see next section).

By automatically managing the infrastructure, you can save a lot of money in the long run without any intervention on your part. It's a fully automated game server infrastructure that can help you optimize usage and reduce costs.

When utilizing the autodeploy option, if there are no available deployments and multiple sessions are requested simultaneously, the system will create a new deployment for each session.

This happens because all sessions check for available deployments, and at that moment, the answer is negative for all of them due to the short time frame. Consequently, the autodeploy option initiates multiple deployments.

There is a third way to manage deployments for your sessions, which is via the Fleet. However, for the purpose of keeping this documentation concise, we will not delve into this topic here. You can refer to the dedicated section on Fleet for all the necessary information on this topic.

Choosing the Best Deployment for Session Requests

There are two main ways to determine which deployment will host your session.

1. Manual assignment: In this approach, your backend will be aware of the available deployments and it will choose a specific one to host your session. This gives you full control over the deployment selection process.

This can be particularly useful if you have a lobby system where players can choose the server they want to join. The sockets (capacity) system can be used to display how much space is available in each server.

1. Edgegap patented decision system: Alternatively, you can let the Edgegap decision system choose the best deployment based on the telemetry of your players. This system leverages advanced algorithms and data analytics to dynamically determine the optimal deployment for hosting your session.

Both approaches are valid and can be chosen based on your specific needs and requirements.

If you choose option 2, we prioritize grouping players in a certain geographical range over the telemetry when choosing a potential deployment for your sessions as it is generally more enjoyable to play multiplayer games with others rather than alone. This is especially relevant in the case of MMO games, where multiple servers with low player counts can be undesirable, and this is a perspective that we believe in.

If no suitable deployment is found in range, we will make a full telemetry request to choose the best location to create a deployment and host your session. It is recommended to activate the autodeploy option to avoid session failure due to the absence of available deployments.

Real Use Case Example

Let's use an example to explain this. Imagine there are three deployments without sessions, located in New-York, Washington, and Chicago. We also have a deployment with active sessions (server with the green circle), meaning there are players available to play with. Now, suppose two players want to start a new session.

At first glance, it might seem logical to host the session in the New-York deployment since it's closest to one of the players. However, we prioritize grouping players together to avoid creating mostly empty servers. So, if there's another deployment, like Washington, that is geographically well-positioned for both players, we will host the session there instead.

There are multiple ways to fine-tune the selection of deployments. One simple and commonly used method is to specify at least the continent in your session request. Additionally, in another section, we will cover the power of Selectors, where you can filter deployments using a tag system.