Best practices to create a lobby system

Game Design
1

(sorry if bad english i’m not native)
Hello,

I wanted to ask some questions before trying out Nakama.

My friends and myself are going to develop a roguelike game which you can play online in coop.
A roguelike means ‘runs’, meaning that the game won’t have a common world for everyone, every player will be dispatched in their own ‘rooms’ in which the game will happen.

In terms of server architecture, this is how we see it:

  • a ‘lobby’ will handle request for players when they’re in the main menu
  • when a player wants to start a game, the lobby will execute a new process and attach the client to that new process. This new process would be the game room, responsible for game logic.

So the key point of our architecture here is that the lobby doesn’t do any game logic, it just manages other process and connects players to it.
(Maybe someone experienced would correct me but i’m pretty sure that is how games like LoL, Valorant, Hearthstone etc. does it, right?)

So here comes my first question.
Is Nakama suited to be instanciated multiple times as a single game room by a 'lobby' ?
Or is Nakama more suited to be a single ‘lobby’, kind of ?

We make our client in Godot.
At first we were going to do our ‘lobby’ in SpringBoot or Django (or any backend framework); and this ‘lobby’ was going to instanciate Godot servers as game rooms (we would use the high level multiplayer API of Godot). But when I discovered Nakama i thought maybe it was more suited than using godot for the server side, so here i am. Should we stick to godot or try out Nakama ?

Also, any criticise on this architecture appreciated, if any of you guys find our architecture bad for any reason and have a better solution, i’d appreciate to hear that.

My second question is a bit more simple:
Has anyone encountered serious problem using Nakama C# Client with Godot ?
I’m asking this because Nakama has a C# Client which i don’t doubt its efficiency, but with Godot i wonder if there wouldn’t be some compatibility problems or anything.

edit: Bonus question.
Which language do you prefer for your nakama server and why ? (lua, JS, Go)

Any insight greatly appreciated.

1 Like
2

Hey @Nellousan welcome :wave:

Sorry for the slow reply to your post. I’ve answered your questions inline.

Or is Nakama more suited to be a single ‘lobby’, kind of ?

I don’t think you really need a lobby for your type of game experience. Nakama can handle either of the two ways to be placed into the “new process” for the game:

  1. Use the matchmaker to find another player online who also wants to play at that moment.
  2. Have a player start a game and then use match listings for other players to find the match if you want to support a hot join model.

But when I discovered Nakama i thought maybe it was more suited than using godot for the server side, so here i am. Should we stick to godot or try out Nakama ?

I would suggest your game rooms are just Nakama match handlers as part of the authoritative multiplayer engine in the server. You can create 1000s of them on a single server and scale to multiple instances effortlessly on our cloud when you reach that level of scale. The logic would be represented as a state machine in your match handler and could be written in Go, TypeScript, or Lua (whichever you prefer).

I’m asking this because Nakama has a C# Client which i don’t doubt its efficiency, but with Godot i wonder if there wouldn’t be some compatibility problems or anything.

We have an official Godot client so you could use that (which is written in GDScript). I don’t know if anyone in the Godot community has used our .NET (C#) client with the support for it in the Godot engine but I can’t see a reason it would be problematic because its quite straightforward C# code as long as the Godot support includes the System.Threading, System.Net, and System namespaces.

Which language do you prefer for your nakama server and why ? (lua, JS, Go)

I prefer Go though I’m biased because I’m one of the engineers that works on Nakama and it is also written in Go. If that’s a language you’re not comfortable with I’d suggest you use TypeScript because you’ll get nice type inference and auto-completion in your editor and its a superset of JavaScript which most developers are familiar with.

Hope this helps.

1 Like
3

Hello @novabyte,

Thanks for the responses, really insightful !
I guess we’ll try out nakama the way you suggested, I didn’t realized but nakama’s match handler system is pretty much exactly what we need.
Go seems like a cool language that i wanted to try out for some time now but didn’t have the occasion so it’s perfect.

Again, thank you very much,
Subject closed i guess.

1 Like