Match name/label

[tranthor]

Hi,
I’m developing a real-time multiplayer game and I’m using:

• C++ & cocos2d-x 3.17.2
• Nakama Server 2.12.0
• Nakama Cocos2d API 2.3.0

The question is: how can I configure the room’s name (or label) when I create a new match?

These are the features I’m trying to do in my game:

1. A player could create a new room/match with a custom name.
2. A player could see all the rooms created currently in the server, and what players are playing in each room.

For make the second point, I’m using the method listMatches:

/**
 * Fetch a list of matches active on the server.
 *
 * @param session The session of the user.
 * @param min_size The minimum number of match participants.
 * @param max_size The maximum number of match participants.
 * @param limit The number of matches to list.
 * @param label The label to filter the match list on.
 * @param authoritative <c>true</c> to include authoritative matches.
 */
virtual void listMatches(
    NSessionPtr session,
    const opt::optional<int32_t>& min_size = opt::nullopt,
    const opt::optional<int32_t>& max_size = opt::nullopt,
    const opt::optional<int32_t>& limit = opt::nullopt,
    const opt::optional<std::string>& label = opt::nullopt,
    const opt::optional<bool>& authoritative = opt::nullopt,
    std::function<void(NMatchListPtr)> successCallback = nullptr,
    ErrorCallback errorCallback = nullptr
) = 0;

It works.
About the first point, I don’t know how can I configure a room’s name/label, because I can’t send the name in the method createMatch:

/**
 * Create a multiplayer match on the server.
*/
virtual void createMatch(
    std::function<void(const NMatch&)> successCallback,
    RtErrorCallback errorCallback = nullptr
) = 0;

Also, I can’t edit the label in the callback:

 auto successCallback = [](const NMatch& match)
 {
     //match.label here is empty and I can't edit it, it's a const.
 };

So, the problem is, when I use listMatches, all matches/rooms names are empty (""). So I can’t make a window showing a matchs list in the server (I don’t want to show matchs ids, I would like to do it friendly… showing match’s names).

Maybe there’s a solution from the server side: https://heroiclabs.com/docs/gameplay-multiplayer-server-multiplayer/

But I want to make it from the client side.
Are there any chance to make an improve in the method createMatch ? It would be nice if I can send the label. I’m not asking for a huge feature… it’s very simple. I just want to show all the current matchs lists with their names (friendly).

@zyro
@Dimon4eg

Is very common in a real-time multiplayer game, create a room with a custom name and see the currents rooms lists. So for example, I can create the room “tranthor game!” and I tell my friend to connect to my room called “tranthor game!”.

[zyro]

Relayed multiplayer matches like you’re creating by calling createMatch from the client cannot have labels. They don’t have any server-side state at all aside from the server’s own internal routing and match wiring, which you cannot control.

If you want to set a label and use it to look up matches you should look at authoritative multiplayer matches instead. You say you want a client-side solution but there’s no reason authoritative matches can’t be created using some amount of client-specified data. Just pass this through to your authoritative match creation RPC function and thread it through match creation on the server.

(Also please don’t tag specific people when you open a thread. Ask your questions and give the right info, we always do our best to reply to everyone.)

[tranthor]

@zyro

If you want to set a label and use it to look up matches you should look at [authoritative multiplayer matches] instead

That’s not exactly I’m trying to do. I don’t want to set a label to “look up matches” with that label.
I want to see all the current matches in the server and see if there’re any match available with enough players where I could join and play.
For example, if I see a match with just 1 player inside, I could join because that player is waiting for some player to join to the match and start playing.

The concept is ROOM. Not MATCH. I think room is a better word in this case. Like the behaviour when a game has different servers. But in this case, it is N rooms with 1 server.

I want to have a button called “Room list” that shows all the current rooms in the server. It should be a table like this:

So in this case, I can join to Tranthor room or zyro room because these rooms aren’t full. But I can’t join to Player room because that room is full.

My current problem is: I can see all the rooms in the server using the method listMatches. Also I can get the current players connected in each room, using the variable NMatch.size. But I can’t get the room’s names because when I created a new room (using the method createMatch) I couldn’t set a label / name of my room.

Do you understand better my problem now? Your solution is still to use “authoritative matches” ? I was looking for an easy solution like send the room name when I create a new match. Example, set the label from the client side, in this structure:

struct NAKAMA_API NMatch
{
    std::string matchId;                     ///< The ID of the match, can be used to join.
    bool authoritative = false;              ///< True if it's an server-managed authoritative match, false otherwise.
    std::string label;                       ///< Match label, if any.
    int32_t size = 0;                        ///< Current number of users in the match.
    std::vector<NUserPresence> presences;    ///< The users currently in the match.
    NUserPresence self;                      ///< A reference to the current user's presence in the match.
};

Please, let me know what do you think.
Thanks.

[BeLuckyDaf]

As a workaround, you could create an rpc function like RegisterMatchRpc, and save your match name and matchId in the storage.

Then when you want a list of rooms, just retrieve this info from the storage.

However, in this case you’ll need to somehow clean up the storage since when the match is over, those records you make won’t be deleted.

I don’t think it’s the best solution, but I guess it’ll work.

[tranthor]

@BeLuckyDaf thanks for your suggestion. I’m going to consider it.
But my question is: why Nakama don’t make it easy? I’ve the same question with the room passwords. I can’t set a match password easily.

Why don’t improve the method createMatch adding the chance to send matchName and matchPassword ? Currently I can’t set settings in a match when I create it. The method createMatch only accepts the callback functions.

I mean, these are basic things in a real-time multiplayer game.
I’m not asking for a huge or strange feature. We’re talking about simple things like name and password.
Name: for identify friendly a room.
Password: if I want to have a private match with a friend.
And maybe also MaxSize, if I want to create a room with a number of max users allowed. Concept of room full. (I know, we’ve NMatch.size with the current number of users, but what about if I want to create N rooms with N different max sizes?, I would need to set this configuration in each match when I create it).

I really like Nakama and I want to use this framework, but I don’t understand some things like these.
I know: maybe I can do it. But why not more easily?
Is more easy send new parameters to createMatch than create an RPC functions, manage storage table, and other things… think in developers.

[zyro]

@tranthor You can use the concept of matches and your “rooms” interchangeably, everything you’ve described fits what a match is in Nakama.

There are various architectural reasons for the restrictions with relayed multiplayer matches but the bottom line is if you want more flexibility use authoritative multiplayer matches instead. Everything you want (labels/names, passwords, size limits, mix of types/sizes, restrict who is allowed to create matches and when etc) is easily achievable with authoritative matches.

It’s very hard to provide infinite flexibility in a pre-built API so we’ve provided authoritative multiplayer as a way for devs to define exactly the behaviour they want.

In fact the example match handler in the documentation completely replicates the logic of relayed multiplayer but also sets a label, which is exactly what you initially asked for. If you remove the example log statements it’s barely 40 lines of code including all the boilerplate. Adding password protection for matches is as simple as a string comparison in the match join attempt hook. Max size is a presence count comparison in the same hook.

We always think of developers first and I think we’ve been fairly successful considering the feedback and success stories we’ve received.

[tranthor]

@zyro

It’s very hard to provide infinite flexibility in a pre-built API so we’ve provided authoritative multiplayer as a way for devs to define exactly the behaviour they want.

Perfect. Is good to know that Nakama made the “authoritative matches” to provide flexibility.
But, I’m talking about simple things:

• matchName
• matchPassword
• matchMaxSize

I would create a module from the server side and I’d made my customisations if I’ve to make something complex specifically for my game.

But that’s not the case. We’re talking about simple and basic things. Plus, nakama is forcing me to code in Go or Lua (I don’t have knowledges of that languages, I’m a C++ developer!). Why should I do that effort just for a simple thing like a match name?

I respect your opinion but I’m not agree with you zyro (I don’t tag you because you don’t like this ). This encourages me to think about other frameworks that help me better with these type of things. I’m still thinking what to do.

Thanks for your suggestions.

[BeLuckyDaf]

I don’t want to be rude, but no one is forcing you to use Nakama if it doesn’t serve your needs. You can use any of other solutions which there are plenty.

I am a C/C++ developer myself, but Go and Lua are two very simple yet powerful languages, it’s never useful to have just one language in your toolkit. I don’t know.

[novabyte]

I am in agreement with @BeLuckyDaf and @zyro. We’re always open to feedback and I’ll discuss with the team on what features could be made more flexible in the game server but I don’t like your characterization of easy and hard things.

We’ve worked hard to thoughtfully develop the technology to make it possible to build many different kinds of games which work at massive scale. If its all so easy for you to do but you’re afraid of a small amount of Lua or Go code I suggest you find another technology or actually contribute to the open-source code in Nakama.

[tranthor]

@novabyte

We’re always open to feedback and I’ll discuss with the team on what features could be made more flexible in the game server but I don’t like your characterization of easy and hard things.

I’m not saying that it’s easy to add this feature to Nakama. I’m trying to say that’s a simple thing from the user or developer side. A match’s name or match’s password is something simple and basic. I’m not talking about a complex feature.

However I’ve no idea how much complex it’s for Nakama devs to add this to the framework. Hope you can understand me and sorry if I offended you!

Hope too that Nakama team hear developers. It’s just a constructive criticism.

[zyro]

I think this topic has run its course. The original question has been answered in a way that’s accessible to everyone, achievable today, does not scale solely with Nakama core developer time (no need to wait for us to make it happen), and will meet the requirement in its entirety plus be flexible to new features like have surfaced during the discussion.

@tranthor

I don’t tag you because you don’t like this

I’m not sure exactly why you specifically called this out, but let me clarify: I generally suggest not tagging individual developers on new topics because it looks like trying to pull them in for a faster answer. This forum is a free community resource - give everyone a chance to participate, rather than expect certain individuals to answer you.

[tranthor]

Ok thanks @zyro !!