Divorce SpawnLocations/Player/Playerlist from TeamColor

Teams were originally implemented around TeamColor. Usually if given either team object or team color, you can find the other, but this breaks down if two team objects have the same team color. This is a non-issue if everything uses object references since Team objects are unique, but the only place in our codebase that’s been upgraded to do so is Player.Team. There are still issues with:

  • Setting the Team property to another team of the same teamcolor does not work
  • The playerlist only shows one of the teams instead of both
  • There is no way to specify which team to use in SpawnLocations since it only has TeamColor

This is a problem because in my game I want teams of the same faction (e.g. humans, dwarves, elves vs goblins, orcs, demons) to have the same team color per faction but function as unique teams in-game.

Proposed solutions:

  • Allow Player.Team property to differentiate between two teams of the same teamcolor and be set to either of them
  • Playerlist should show all teams, even if they have the same teamcolor, and show players under the appropriate team based on the Player.Team property
  • Add SpawnLocation.Team and deprecate SpawnLocation.TeamColor in favor of SpawnLocation.Team.TeamColor
  • Deprecate Player.TeamColor in favor of Player.Team.TeamColor

Ultimately TeamColor should be a visual property of teams only and not be used in any way to identify an object’s team.

17 Likes

Did you mean to put this in #feature-requests:client-features ?

1 Like

I can’t understand why it was ever made this way. Did we not have ObjectValue properties when teams were created?

I completely agree with the fact that TeamColor should only be a visual thing. Even then though, it’s only use case post-divorce would be colors on the player list and if the developer uses the property. Teams should not operate with TeamColor as a dependency.

And I agree with the other solutions.