Your current design seems to go against the first principle of SOLID design.

This first principle, called the "single responsibility principle", is generally a nice guideline to follow in order not to create monolithic, do-everything objects that will always hurt your design.

To concretize, your World object is responsible both for updating and holding the game state, and for drawing everything.

What if your rendering code changes / has to change? Why should you have to update both of classes that actually don't have anything to do with rendering? As Liosan has already said, you should have a Renderer.

And also, please ignore all the people who say good software design is not important. It is, and you should probably start adopting it from the start. It's a good practice, it's easier, and it is required if you ever want to upgrade your project.

Now, to answer your actual question...

There are many ways of doing this, and this is only one way of decoupling:

1. The world doesn't know what a player is.

• It does have a list of Objects in which the player is located, however, but it does not depend on the player class (use inheritance to achieve this).

2. The player is updated by some InputManager.
3. The world handles movement and collision detection, applying proper physical changes and sending updates to objects.

• For example, if object A and object B collide, the world will inform them and then they could handle it by themselves.
• The world would still handle physics (if your design is like that).
• Then, both objects could see whether the collision interests them or not. E.g., if object A was the player, and object B was a spike, then the player could apply damage to itself.
• This can be solved in other ways, though.

4. The Renderer draws all the objects.

Your current design seems to go against the first principle of SOLID design.

This first principle, called the "single responsibility principle", is generally a nice guideline to follow in order not to create monolithic, do-everything objects that will always hurt your design.

To concretize, your World object is responsible both for updating and holding the game state, and for drawing everything.

What if your rendering code changes / has to change? Why should you have to update both of classes that actually don't have anything to do with rendering? As Liosan has already said, you should have a Renderer.

Now, to answer your actual question...

There are many ways of doing this, and this is only one way of decoupling:

1. The world doesn't know what a player is.

• It does have a list of Objects in which the player is located, however, but it does not depend on the player class (use inheritance to achieve this).

2. The player is updated by some InputManager.
3. The world handles movement and collision detection, applying proper physical changes and sending updates to objects.

• For example, if object A and object B collide, the world will inform them and then they could handle it by themselves.
• The world would still handle physics (if your design is like that).
• Then, both objects could see whether the collision interests them or not. E.g., if object A was the player, and object B was a spike, then the player could apply damage to itself.
• This can be solved in other ways, though.

4. The Renderer draws all the objects.

Your current design seems to go against the first principle of SOLID design.

This first principle, called the "single responsibility principle", is generally a nice guideline to follow in order not to create monolithic, do-everything objects that will always hurt your design.

To concretize, your World object is responsible both for updating and holding the game state, and for drawing everything.

What if your rendering code changes / has to change? Why should you have to update both of classes that actually don't have anything to do with rendering? As Liosan has already said, you should have a Renderer.

And also, please ignore all the people who say good software design is not important. It is, and you should probably start adopting it from the start. It's a good practice, it's easier, and it is required if you ever want to upgrade your project.

Now, to answer your actual question...

There are many ways of doing this, and this is only one way of decoupling:

1. The world doesn't know what a player is.
2. The player is updated by some InputManager.
3. The world handles movement and collision detection, applying proper physical changes and sending updates to objects.

• For example, if object A and object B collide, the world will inform them and then they could handle it by themselves.
• The world would still handle physics (if your design is like that).
• Then, both objects could see whether the collision interests them or not. E.g., if object A was the player, and object B was a spike, then the player could apply damage to itself.
• This can be solved in other ways, though.

4. The Renderer draws all the objects.

Your current design seems to go against the first principle of SOLID design.

This first principle, called the "single responsibility principle", is generally a nice guideline to follow in order not to create monolithic, do-everything objects that will always hurt your design.

To concretize, your World object is responsible both for updating and holding the game state, and for drawing everything.

What if your rendering code changes / has to change? Why should you have to update both of classes that actually don't have anything to do with rendering? As Liosan has already said, you should have a Renderer.

And also, please ignore all the people who say good software design is not important. It is, and you should probably start adopting it from the start. It's a good practice, it's easier, and it is required if you ever want to upgrade your project.

Now, to answer your actual question...

There are many ways of doing this, and this is only one way of decoupling:

1. The world doesn't know what a player is.

• It does have a list of Objects in which the player is located, however, but it does not depend on the player class (use inheritance to achieve this).

2. The player is updated by some InputManager.
3. The world handles movement and collision detection, applying proper physical changes and sending updates to objects.

• For example, if object A and object B collide, the world will inform them and then they could handle it by themselves.
• The world would still handle physics (if your design is like that).
• Then, both objects could see whether the collision interests them or not. E.g., if object A was the player, and object B was a spike, then the player could apply damage to itself.
• This can be solved in other ways, though.

4. The Renderer draws all the objects.