Out of the box support for large concurrent playerbases on a single world.

Hi, I am looking at building a large open-world sandbox style game, inspired by MMORPGs of the early 2000s era.

We’re currently discussing engine options, and one of the big factors we’re looking at right now is the degree to which the existing server implementations support large numbers of concurrent players in a single “world”.

Put simply my question is: What is Lumberyard + Gamelift capable of, without writing an entirely custom server solution. We want to keep the amount of “repeating ourselves” to a minimum, as we are a small team. Our hope though is to be able to have a few hundred people on a single world if possible, before we need to begin load-balancing over shards.

We are in the same boat as well. I’m glad someone has asked this question, we are trying to develop an MMORPG-type game, but definitely want to go MVP, just to get a hundred players or so for development. We want to understand Lumberyard/Gamelift capabilities as well.

Hey @Storakatten, Welcome to the Lumberyard Community!

My apologies for the delayed response – let me get some clear answers for ya from the team :slight_smile:

Thank you very much. If the answer feels on the low side, I wouldn’t mind being pointed in the right direction to what the network protocol is should I need to implement my own server solution from scratch.

Consider starting with this doc: https://docs.aws.amazon.com/lumberyard/latest/developerguide/network-interest-manager-large-scale-worlds.html

There is a way to do that but it’s currently an advanced feature. On GDC 2017 LY networking had a demo where two separate GridMate sessions were used to achieve what you are describing. I can’t find a public link for it but here is what was implemented for that demo.

Session 1: GridMate in a client-server configuration to handle all the players with a single connecting server.

Session 2: GridMate in a peer-to-peer configuration among several servers to split the load on the server.

On the server that had both S1 and S2, hooks were added to manually connect S1 and S2 in order to transmit Replica updates.

Hey, I’m just getting started on a multiplayer game project as well. Thanks for the link, it appears that GridMate uses the Interest Manager to reduce bandwidth costs on sessions with a large number of players who don’t need to sync 100% of the world.

This sounds great, but it seems like given enough players my game session could still grow too large for a single server to handle and I might need to split it up and use multiple servers to handle the load. Or I might want to allow a large/unlimited number of users to spectate a single game session through their game clients, potentially on a delay (similar to Source TV).

Does GridMate support this sort of managed and distributed session handling? If not, would it be practical to create a ‘Session Manager’ to accomplish this on top of the existing GridMate code?

What do you mean when you say this is an advanced feature? In the Session 2 Peer to Peer example, is this something that is explicitly supported or is this describing a workaround to address the need to expand beyond a single server? If a workaround, are there specific plans (and schedule?) to provide this as a standard feature using GridMate within LumberYard?