Improve `RobotPool` encapsulation for command limit
Opened this issue · 1 comments
Having a public method for RobotPool::AddRobotCtrl seems to break encapsulation. This sort of detail should be made private.
It would seem to make sense to do any such check inside RobotPool::insertRobotIntoTable.
Additionally, we probably want to add a hard check on the robot limit to the start of RobotPool::insertRobotIntoTable before allowing an active robot to be placed on the map.
The command limit is on the number of active robots. Any additional robots would sit in storage, provided there is storage space available. Robots beyond the command limit, and with no storage to hold them, would be destroyed and removed from the game.
Related Issue: #1311
More deeply, having the RobotTileTable owned by MapViewState rather than by RobotPool also seems to break encapsulation.
It seems RobotPool is used to managed both the pool of robots sitting in storage, and the actively deployed and operating robots. For RobotPool to accurately track active robot deployments, and limit deployments to the current active cap, we should probably transfer ownership of the RobotTileTable to RobotPool.