Refactoring of Games.java

[RedstoneFuture]

The class Games.java is the central object for a game. However, some methods and fields can be outsourced to manager classes to keep the Games class a bit more manageable. The following is a suggestion for outsourcing:

Games.java

• NEW: method EquipmentManager()
• NEW: method TaskManager()
• DELETE: method getScoreboard() -> Using of ScoreboardManager

Moving from Game.java to Lobby.java

• method teleportToLobbySpawn()
• method teleportToAfterGameSpawn()

Moving from Game.java to Arena.java

• method teleportToArenaSpectatorSpawn()

Moving from Game.java to EquipmentManager.java

• field ItemStack customBow (+ Getter)
• field ItemStack customPickaxe (+ Getter)
• field MissileGameEquipment missileEquipment (+ Getter)
• field SpecialGameEquipment specialEquipment (+ Getter)
• method createGameItems()
• method sendGameItems()

Moving from Game.java to TaskManager.java

• field Timer timer (+ Getter)
• field BukkitTask bt (+ Getter)

[daniel-naegele]

This is definitely a good idea. I would split in this into smaller PRs, with the addition of the EquipmentManager, TaskManager each.

[RedstoneFuture]

I am not sure if moving the teleportTo methods is useful at the moment. I'm thinking about moving some player based methods (removePlayer, broadcast, startForPlayer, setPlayerAttributes, the teleport methods, ...) to a separate manager - but not yet.