• View
• Edit
• History
• Print

PlayerIds

This site describes the idea of changing the current scheme of PlayerIds in Boson.

UPDATE: This site still described the old situation. The "current situation" described below is the way it worked before. We now use the PlayerId Scheme Proposal that is presented below.

The current situation

Right now we use the ID of KPlayer::id() as Boson PlayerIds. These IDs are also used by KGame internally which means that the client ID is encoded in the player ID: if you have two players on client A, they'll probably have IDs 1025 and 1026, but if these players are on clients A and B, then they'll probably have IDs 1025 and 2049. Therefore the fileformats (.bpf/.bsg files) cannot store the actual game ID: when starting a game, the IDs might have changed compared to when they were saved. This is why we use the "index" of the player in the playerlist as a PlayerId in the file formats. On startup this "dummy" ID is replaced by the real PlayerId (by BosonStarting::fixPlayerIds()).

Why change anything?

The current PlayerId scheme is flawed. It has caused a lot of trouble in the past - these issues have been fixed meanwhile, but I can already foresee future problems:

• Conditions need to be able to explicitly provide no PlayerId at all. Therefore the ID "0" should be used (which is invalid in-game), but BosonStarting::fixPlayerIds() would replace a "0" by the PlayerId of the first player (as the files save the index, not the IDs currently)
• "Choosing a side" is tricky with the current scheme. BosonStarting::fixPlayerIds() must replace the player index by the _desired_ PlayerId
• Some things simply cannot be stored at all, without special code. For example imagine an event "PlayerKilledPlayer" that is emitted when Player A kills player B. Of course the IDs of both, player A and B must be provided: but BoEvent provides only one "playerId()" field, so "Data1" must be used for a PlayerId. But BosonStarting::fixPlayerIds() won't catch this field, so when loading the event (keep in mind that events are also used in conditions, so loading them is important), it might be broken (depending on whether the players use the same IDs as when the event was saved).

All of these are "fixable", but require additional code and some work. None of these is an issue right now: none of our current features depends on these. But all of them will turn out to be an issue later. These are the main issues of the current scheme (IIRC), though I have already noticed a few other issues that will cause us headache one day.

By fixing the problems described above, we would merely be fixing the symptoms. We really should go for fixing the problem and we should go for it now.

PlayerId? Scheme Proposal

Instead of using KPlayer::id(), we should use KPlayer::userId(). userId() is not touched by KGame, so we can use free IDs in the way we want to. Some properties:

• The IDs get assigned to the players when starting a game
• The IDs match exactly those in the .bpf/.bsg files. The player might be allowed to pick the side to play on, i.e. the player on the map.

ID assignment:

• < 0 is invalid and must be completely unused. No player is ever allowed to use such an ID, not even for initialization purposes.
• 0 is invalid. Always. This will never change.
• 1-127 is invalid currently. This is unlikely to ever change, but it is not forbidden.

• 128-255 are actual player IDs. These IDs represent players that might be playable in some way (however a map may forbid to take control of certain players). At the moment this means all players except of the netural player use these IDs.
• 256-511 IDs of players that are unplayable and will always be. 256 is reserved for the "neutral" player.

• 512-unlimited is unused. This may change in the future, i.e. these IDs are "reserved for future use".

Additional notes:

• "Invalid" IDs mean that no player that takes actually part of the game is allowed to use these IDs. Players that watch the game only, but do not control any units or anything else are allowed to use these IDs.
• Map files (.bpf/.bsg files) must never use invalid IDs.
• At any time a PlayerId must be unique, that is no game-player may use the same ID as another player. Multiple players with the same invalid ID might be allowed. This is undecided yet.