Task 1

• Make it possible to add more players to TRON easily (so 3,4,5. . . people can play at the same time each with their own uniquely coloured bike)
• Addition or removal of players should be as simple as possible, take into account the collision detection, controls configuration, rendering etc.
• Addition of player will be done offline, that is to change number of players the source of the game will be altered and the whole code recompiled. There is no need to create any kind of game menu.

Task 2

• Adapt current code to make it possible to use as much of it as possible as a generic engine for implementing other games.
• Provide a way for these new implementations to bind with the engine, e.g. interfaces that need to be implemented.
• Make the current TRON game such implementation of the engine.

Task 3

• Add the possibility to control any player by mouse (e.g. turn left or right using left and right mouse buttons respectively

Task 4

• Separate the state of the game from its graphical representation, that is have one class /package represent the Model and other the Presentation.
• The model must contain and provide access for the player bikes, events such as collision between two players happened and so forth.
• There is no dependency from Model to Presentation, only from Presentation to Model
• The model itself should not handle frame timing (Thread.sleep()), that is the responsibility of calling some update method on the model is outside of the model, preferably in the extracted engine code from previous tasks

Optional Tasks

Task 5

• Use the extracted engine to implement some other game (e.g. pong, snake,...)

Task 6

• Use git for your solution and structure your commits in a similar way to the demo/exercise,i.e. the commits represent the individual steps in the refactoring process

Hello to both of you,

I'm sorry for the feedback delay, in your group, I forgot to mention to notify me after
the dry run submission.

I checked your solution and I have the following comments:

Engine game separation

• separation of engine and the game could be better and more explicit, e.g. in separate packages, modules, etc.
• Although you have a general Game and then specific TronGame, your engine/core still depends on the TronGame and thus it's not reusable for other games.

More general abstractions of init, update, draw

• Parts of graphics initialization which can be common for multiple games (screen manager, game window etc.) should be moved to the engine.
• TronGame should contain only parts which are specific for the Tron itself. It might not be necessary to have all those different update methods, because not every game may use them all.
• If you would like to be more general, then basically all you need in the game abstraction on the highest level is init(), update() and draw() -> this could be part of some interface.
• Then you can have some abstract implementations of this interface which can add more methods if it's useful. And some of them can be just empty and some abstract.

Screen/DrawManager separation

• Screen/DrawManager should be separated on parts which are specific for the particular
  game (e.g. when it works with Player) and part which is generic and should be part of the
  engine.

Code refactoring

• Although you have class Coordinates, your Player has still centreX and centreY.
• Your detection of collisions is quite complicated. Also, basically just want to know whether one Coordinate "equals" another.

Controls

• Player itself shouldn't have anything to do with the key and mouse controls. The events, keymapping etc. is a separate responsibility and should be handled by someone else.
• It is not clear what's the purpose of the Controls interface. Also your control handlers are bit complicated now. It is not necessary to have only one handler for all the players. Additionally, the handlers can have a bit more understandable name.

Direction

• some of the responsibility related to Directions could be moved to the enum itself.
• For example, each Direction can know its right/clockwise and left/counter-clockwise direction e.g. for RIGHT, to the right is DOWN and to left is UP.
• Also each Direction can know its opposite direction. This way, the handling of direction changes and checking of the allowed direction changes would be easier.

Player state

• Player should be responsible for its state. Which means it is, for example, able to tell, whether it collides with something or it can update its state with movement.
• updateTronPlayerPositions() could be simplified

Naming

• It is better not to say explicitly whether something is an interface. For the clients of the class or in terms of dependencies, it shouldn't matter.
• Furthermore, it's better to be more specific in the naming of the interface implementations. Therefore, for example, instead of DrawingInterface, I would use the name DrawingManager and instead of DrawingManager, I would use something like TronDrawManager/DefaultDrawingManager etc.

Object passing

• In case you often get some data from the object which are then passed as arguments to some other methods, it might make sense to use the whole object as an argument.
• Additionally, if you often query the same data from the object and then you work with them, then it might be worth considering to have the object itself work with the data and then provide you the results instead.

If you have any questions, feel free to ask.

Best regards,
Stanislav