You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My own reason for wanting to get this done: While Agones is clearly designed towards supporting lobby style matchmaking-based managed game server operator, but I want to have a stable, sorted ordinal that scales well with traditional game servers -- the one that is open to the public for hosting and usually community-backed, for example CS2, Rust (the game, I do both Rust the language and Rust the game, how's the irony), TF2 and Squad dedicated servers, and there's more, and the market for those games are still pretty high, yet often neglected in Agones anyway.
Because the players hosted their own community servers, other players get to choose which server to play from since you don't have a matchmaker, so if the users want to join the servers with their friends, it is not easy to do so.
Right now, how I partially remediate this problem, is to read the Agones API and generate a server name suffix from it -- given that I use hash to make a small enough string like 5 random English characters and the chance of collision should be small and the players use this suffix code to find the right server -- while it works it is often quite confusing to them and if the server name is too long, then it is possible to spill out and the user couldn't see the server suffix or need to wait for the server name to roll like a carousel. Both problems can be addressed if we could just have a linear system that progressively rollout the game servers in a stable and ordinal way.
As such, why can't we just have it roll out like StatefulSet in Kubernetes that could generate a stable ordinal number so the players can easily recognize with.
Oh, it can also serve as an indicator of how well the server scales as well.
The text was updated successfully, but these errors were encountered:
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
Previous discussion: #2286
My own reason for wanting to get this done: While Agones is clearly designed towards supporting lobby style matchmaking-based managed game server operator, but I want to have a stable, sorted ordinal that scales well with traditional game servers -- the one that is open to the public for hosting and usually community-backed, for example CS2, Rust
(the game, I do both Rust the language and Rust the game, how's the irony), TF2 and Squad dedicated servers, and there's more, and the market for those games are still pretty high, yet often neglected in Agones anyway.Because the players hosted their own community servers, other players get to choose which server to play from since you don't have a matchmaker, so if the users want to join the servers with their friends, it is not easy to do so.
Right now, how I partially remediate this problem, is to read the Agones API and generate a server name suffix from it -- given that I use hash to make a small enough string like 5 random English characters and the chance of collision should be small and the players use this suffix code to find the right server -- while it works it is often quite confusing to them and if the server name is too long, then it is possible to spill out and the user couldn't see the server suffix or need to wait for the server name to roll like a carousel. Both problems can be addressed if we could just have a linear system that progressively rollout the game servers in a stable and ordinal way.
As such, why can't we just have it roll out like StatefulSet in Kubernetes that could generate a stable ordinal number so the players can easily recognize with.
Oh, it can also serve as an indicator of how well the server scales as well.
The text was updated successfully, but these errors were encountered: