Add game packets #126
Add game packets #126
Conversation
|
Would a way to opt into game packets make sense? |
| |:--------------:|:----------:|:----------------------------------------------------------------| | ||
| | game_type_id | Identifier | The identifier of the game type. | | ||
| | game_type_name | Text | The name of the game type. | | ||
| | game_id | Identifier | The identifier of the game. | |
There was a problem hiding this comment.
On second thought, I'm not sure if this should be included in the packet. Relying on game ids is never a good idea.
There was a problem hiding this comment.
Is there any specific reason why packet consumers should not be able to have access to the game ID?
To be more specific, providing game type IDs (which I am not sure whether you are against as well) would allow packet consumers to distinguish between game types for icons, and providing game IDs would allow packet consumers to differentiate by individual game as well.
There was a problem hiding this comment.
They can’t and shouldn’t be relied on by anything. Games don’t have an ID- hence the rename to source. It’s just where the game was loaded from, and that might not even be present in the case of an anonymously created game.
There was a problem hiding this comment.
Packet consumers would be required to handle anonymous games, then. If the identifier was removed, packet consumers would just end up relying on text, which is worse. After all, games can have no text as well (though, this just falls back rather than being null).
There was a problem hiding this comment.
They should probably rather be passed all the game custom values.
There was a problem hiding this comment.
Would that custom value not just be the same as the game ID? In addition, would all anonymous games have that custom value as well? It would duplicate the existing game ID for not much benefit.
There was a problem hiding this comment.
No- it would provide whatever values are needed directly. Anonymous games are an example of where things would not have a game id, but really the motivation in this case is they can't be considered to be stable. A new game config can be added, or a config can be moved around- but then you have to update the map within the tracker to consider that.
There was a problem hiding this comment.
The game ID is the thing that this map would need, and for the problem the tracker aims to solve, there is no way around it; any attempts at providing a custom value replacement would just duplicate the ID.
I think packet consumers can handle the task of recognizing that the given game IDs are not stable and may not exist. The tracker would ignore games without IDs and treat games with changed IDs as entirely separate games, unless the user chooses to merge two game IDs.
There was a problem hiding this comment.
The point is to not have the map in the first place, but rather the values within the map provided within the game. What do you imagine this map would be used to store? I suspect I am misunderstanding something and causing us to not get anywhere 😄
There was a problem hiding this comment.
The map would store play counts for each game.
There was a problem hiding this comment.
plasmid:game/player_add needs to be split:
plasmid:game/self_add would contain the same fields as the current packet but without player_uuid
The new plasmid:game/player_add would be trimmed down (be gone all the fields starting with game_)
plasmid:game/player_remove would only contain player_count and player_uuid (all data would be cached by the clients when joining a game anyway)
same with plasmid:game/close (the game_ can be dropped here)
only the reason field is needed.
This pull request adds a simple set of custom payload packets that are sent to clients when a player is added or removed from a game space, or a game space is closed.