Player Singleton (NetworkCommonData) to store important immutable variables (player_id, session_id)

[TheYellowArchitect]

Once a player joins, he has access to multiplayer.get_peers() to get the peer ids.
However, almost every online game requires player ids at some point. Most commonly in videogames, there is a player table, with their IDs to the left (think pressing Tab in FPS, or RTS lobbies before starting a scenario/map)
The usage of a player id should be included with netfox, and stored in a singleton, let's name it NetworkCommonData

It currently has:

var local_player_id: int

# This is for converting peer ids to player ids, either using this or a get function
# <peer_id, player_id>
var peer_ids_to_player_ids: Dictionary
var player_ids_to_peer_ids: Dictionary
var local_session_id: int

player_id is also useful in serialization and deserialization, as it's only 1 byte (may I say, half a byte, since 0-16 is the common)
compared to sending peer_id (4 bytes, u_32)

A good practical example is also sharing IDs. See #242 and its solution which requires having the player id.

session_id is useful for the server, to store replays, or save files. Personally for the replay manager I have made, I use this to store replays in the following path user://gamenamefolder/Session_ID/replaydata.replay
and I plan to implement a similar system to netfox, and session id is required.

The variable player_joined_at_tick: int is required for the replay system, and for implementing state diffs. So our above singleton now looks like this, in its final form:

var local_player_id: int
var local_session_id: int
var local_player_joined_at_tick: int
var local_avatar: Node #You can change the type, but basically you can reference your local avatar from any class

# This is for converting peer ids to player ids, either using this or a get function
# <peer_id, player_id>
var peer_ids_to_player_ids: Dictionary
var player_ids_to_peer_ids: Dictionary

var players_joined_at_tick: Dictionary #<player_id, tick>

This singleton's values are filled before/after NetworkTime.is_initial_sync_done()

[elementbound]

Ok so If I read you right, the proposed fields are:

• Player ID
• Session ID
• Joined at tick
• Avatar

I'll consider these given the way netfox is structured:

• netfox itself is the core, with features that are required for responsive multiplayer sync, that you can't live without, e.g. RollbackSynchronizer, StateSynchronizer, etc. Also provides base classes for higher-level things ( like the tick loops or interpolators )
• netfox.extras has features that can be useful for some games, like weapons. They may not be needed for every game ( in contrast to synched time for example ), but people can optionally download and use them if it makes sense for their game.

The other two addons are not important in this discussion atm.

---

Player ID

This is pretty much game specific - some games need it, some don't. For example, Forest Brawl doesn't need it either, even though it has a score board. I wouldn't include it in core, as it would introduce another concept that is barely different from what Godot already provides. If we want to refer to specific peers, Godot has the peer ID's for those.

In some form, it might make sense to be included in netfox.extras.

---

Session ID

This is extremely game specific. And even then, the server can generate a random ID and share that with peers as they join. Of course, I understand that it would be best if netfox just had everything out of the box :) But atm I don't see a session ID needed frequently enough to warrant it being implemented.

With that said, I'm happy to include it if there's considerable need from the community.

session_id is useful for the server, to store replays, or save files.

In that case, the replay system can manage the session ID :) Not sure what you mean with save files though.

---

Joined at

is required for the replay system, and for implementing state diffs

I imagine the replay system as its own, separate thing, that extracts all the data it needs from netfox's other APIs. However, I'll check your state diff PR to see how it relies on this data. Until then, consider this being considered :)

---

Avatar

Again, game-specific. Some games have avatars, some have lots of units moving around, some have things with shared control, etc. Similarly to Session ID, definitely wouldn't include in core, maybe in extras if there's need for it.

Another example for it being game specific, is that games may handle player concepts differently. For example in the game I'm currently building, I started off with an Avatar(-adjacent) concept, but eventually I'll move to Players who join games, and who have avatars. So the local avatar is not very useful, the local player is. And for that I'd prefer my own system.

This is not to say that nobody would prefer a system provided with netfox.extras, just that I have an example :) Anyway, I'm open to people commenting on this, whether this is something they'd find useful or not.

[TheYellowArchitect]

Yes, this isn't meant to be in the same level as NetworkTime and other crucial components. It's for Netfox.extras.
joined_at is unused thus far, but it was useful for my specialized use-case so I had to bring it up. Though I wouldn't suggest it in its implementation because it bloats the code a lot, so I now argue against it instead for it :P

Avatar, yes, you are right, that's why it's just 1 line in the OP 😅

---

To synopsize, basically the PR #269 to be implemented in Netfox.extras (assuming the ID thingy is settled)

[elementbound]

Closing this issue for now, I don't see enough demand to add these in addition to the justifications in my previous comment. Same for #269.

One addition to Player ID - I think clients can also determine this just by checking multiplayer.get_peers().size() upon joining, assuming that clients also get the IDs of other players.