The code we were given for this task featured a GameObject2D class, which had an ImageGO2D class inherit from it, which had a Physics2D class inherit from it, which had a Player2D class inherit from it. One of my priorities on seeing this was to modify this, such that Physics2D wasn’t a class which players inherit from, but rather a member they have.

As this is a game engine programming module this seems like a more appropriate style, as it creates more abstraction between a game object and its physics, meaning that one can be modified without creating substantial changes to the other, and creating a clearer distinction regarding whether you are calling a function on a game object or its physics component.

This was more difficult as task than I had expected, as many of the things that the physics required to work existed in the game object class, and these had to be stored separately in the physics class, which involved a great deal of finding when they are instantiated and adding them to the physics component afterwards.

Although this was a time-consuming task which had no baring on how the game ran or played, it was an important step to do early, as delaying it would have created a lot more difficulties when we eventually got around to it, and it’s an important task, as the relationship between a body and its physics should not be “Player is 2D physics” but rather “Player has 2D physics”