Questions about the plausibility of using nakama runtime for multiple aws gamelift fleets
After going through documentation and codebase it looks like its not possible to have nakama runtime support multiple aws gamelift fleets.
we need support for aws multiple gamelift fleets for the following reasons 1. To enable QA to test multiple unreal server builds faster 2. To support multiple unreal server versions compatible with specific app version for players
After looking on AWS side, although its possible to have multiple gamelift fleets/alias in a single sqs resource, the nakama seems tied to the alias id and there is no flexibility to order requests to specific alias other than the predefined one by aws(cost, latency, destination and location), which are not suitable for our usecase for supporting different app versions(please correct me if my understanding is wrong here)
I would like to understand if there is any way to support multiple gamelift fleets in nakama runtime(by extending the nakama gamelift plugin only with/without changing the runtime code perhaps ? from the codebase it looks plausible but i would like your expertise to guide us on pitfalls/plausibility/efforts required etc)
Thanks and Regards
Harish Kumar Datla
Hi @harishkumar,
You’re correct, the current FleetManager implementation assumes a single GameLift fleet.
My opinion is that it would be easier to have a separate QA Nakama deployment with a dedicated Fleet.
Otherwise, what you ask should be possible - there’s nothing preventing you from forking: GitHub - heroiclabs/nakama-gamelift: Nakama Fleet Manager and AWS GameLift adapter., but be warned that this may cause incompatibility with Nakama Enterprise, should you consider to use Heroic Cloud in the future. You could pass the fleet as part of the Create metadata, and then change the implementation in your fork to target a specific fleet. You should be able to setup your GameLift so that the queue receives placement updates from either fleet.
Best,
Simon
Hey Sesposito,
Thanks for your reply and time. Sorry in advance for pestering you with more questions after holidays.
Does this mean, In nakama enterprise we wouldn’t have the option to support multiple gamelift fleets out of the box ? or its provided in enterprise and hence our custom solution is not portable and we have to ditch once we move?
If heroic cloud doesn’t provide the support for multiple gamelift fleets, please have a look at the question below. otherwise you can ignore.
The team thinks supporting multiple unreal server versions in production a necessity, hence the need for multiple gamelift fleets.
So I’m wondering what’s stopping this usecase ? i’m assuming heroic cloud should support custom modules written from our side? Since adding new modules is fairly different from the clustering support(and more) that heroic cloud provides which is more on the nakama runtime side ? If our logic is foolproof and nakama enterprise distributes the requests among many ec2 servers appropriately and our custom matchmaking hook logic with our custom forked plugin treats this unique matchmaking request and distributes the requests among the appropriate fleets should ideally work i’m assuming ?
Please let us know about the limitations.
As always thank you for your patience, the answers to these questions will help us on evaluating heroic cloud offerings which is currently in pipeline and helps us plan ahead.
Thanks and Regards,
Harish Kumar
No worries, we’re here to help.
No, this is not supported out-of-the-box either in Nakama OSS or Nakama Enterprise (NE) at the moment. I only mentioned NE because the Callback Handler (you’ll see it in the nakama-gamelift implementation) needs to be cluster aware (to clarify: a Nakama cluster), so depending on your fork logic, it may not be suitable for being accepted upstream. The forked plugin would certainly be loaded by NE, but the callback handling logic may or may not behave correctly depending on your changes.
We’ll create an internal ticket to assess adding multiple FleetManager support on Nakama, but we likely won’t get around to it before the new year.
If you’d like to expedite this, I think the more flexible and easier implementation would be to allow Nakama to register multiple FleetManager implementations that are namespaced instead of a single one. This would require changing: nakama-common/runtime/runtime.go at v1.43.1 · heroiclabs/nakama-common · GitHub to support an additional namespace param, same for GetFleetManager. Another PR would be required on Nakama OSS to support this interface change, and finally nakama-gamelift may have to be updated, but changes should be minimal (or just dependency bump).
If you do open a PR, and would like us to take a look, please reach out via hello@heroiclabs.com.
Best.