How to avoid circular dependencies between Player and World?

Question

I'm working on a 2D game where you can move up, down, left and right. I have essentially two game logic objects:

• Player: Has a position relative to the world
• World: Draws the map and the player

So far, World depends on Player (i.e. has a reference to it), needing its position to figure out where to draw the player character, and which portion of the map to draw.

Now I want to add collision detection to make it impossible for the player to move through walls.

The simplest way I can think of is to have the Player ask the World if the intended movement is possible. But that would introduce a circular dependency between Player and World (i.e. each holds a reference to the other), which seems worth avoiding. The only way I came up with is to have the World move the Player, but I find that somewhat unintuitive.

What is my best option? Or is avoiding a circular dependency not worth it?

Answer 1

The World should not draw itself; the Renderer should draw the World. The Player should not draw itself; the Renderer should draw the Player relative to the World.

The Player should ask the World about collision detection; or perhaps collisions should be handled by a separate class which would check collision detection not only against the static world but also against other actors.

I think the World should probably not be aware of the Player at all; it should be a low-level primitive not a god-object. The Player will probably need to invoke some World methods, perhaps indirectly (collision detection, or checking for interactive objects, etc).

Answer 2

Here is how a typical rendering engine handles these things:

There's a fundamental distinction between where an object is in space and how the object is drawn.

1. Drawing an object

   You typically have a Renderer class that does this. It simply takes an object ( Model ) and draws in on the screen. It can have methods like drawSprite( Sprite ), drawLine(..), drawModel( Model ), whatever you feel like needing. It's a Renderer so it's supposed to do all these things. It also uses any API you have underneath so you can have for instance a renderer that uses OpenGL and one that uses DirectX. If you want to port your game to another platform, you simply write a new renderer and use that one. It's "that" easy.

2. Moving an object

   Each object is attached to something we like to refer to as a SceneNode. You achieve this through composition. A SceneNode contains an object. That's it. What's a SceneNode? It's a simple class containg all the transformations ( position, rotation, scale ) of an object ( usually relative to another SceneNode ) together with the actual object.

3. Managing the objects

   How are SceneNodes managed? Through a SceneManager. This class creates and keeps track of every SceneNode in your scene. You can ask it for a specific SceneNode ( usually identified by a string name like "Player" or "Table" ) or a list of all the nodes.

4. Drawing the world

   This should be pretty obvious by now. Simply walk through every SceneNode in the scene and have the Renderer draw it in the right place. You can draw it in the right place by having the renderer store the transformations of an object before rendering it.

5. Collision Detection

   This isn't always trivial. Usually you can query the scene about what object is at a certain point in space, or what objects will a ray intersect. This way you can create a ray from your player in the direction of the movement and ask the scene manager what's the first object that ray intersects. You can then choose to move the player to the new position, move him by a smaller amount ( to get him next to the colliding object ) or not move him at all. Make sure to have these queries handled by separate classes. They should ask the SceneManager for a list of SceneNodes, but it's another task to determine whether that SceneNode covers a point in space or intersects with a ray. Remember that the SceneManager only creates and stores nodes.

So, what is the player, and what is the world?

The Player could be a class containing a SceneNode, which in turn contains the model to be rendered. You move the player by changing the position of the scene node. The world is simply an instance of the SceneManager. It contains all the objects ( through SceneNodes ). You handle collision detection by making queries on the current state of the scene.

This is far from being a complete or accurate description of what happens inside most engines, but it should help you understand the fundamentals and why it's important to respect the OOP principles underlined by SOLID. Don't resign yourself to the idea that it's too hard to restructure your code or that it won't really help you. You will win a lot more in the future by carefully designing your code.

Answer 3

Why would you want to avoid that? Circular dependencies should be avoided if you want to make a reusable class. But the Player is no class that needs to be reusable at all. Would you ever want to use the Player without a world? Probably not.

Remember that classes are nothing more than collections of functionality. The question is just how one does divide the functionality. Do whatever you need to do. If you need a circular decadency, then so be it. (Same goes for any OOP features by the way. Code things in a way that it serves a purpose, don't just follow paradigms blindly.)

Edit
Okay, to answer the question: you can avoid that the Player needs to know the World for collision checks by using callbacks:

World::checkForCollisions()
{
  [...]
  foreach(entityA in entityList)
    foreach(entityB in entityList)
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
}

Player::onCollision(other)
{
  [... react on the collision ...]
}

The kind of physics you have described in the question can be handled by the world if you expose the velocity of the entities:

World::calculatePhysics()
{ 
  foreach(entityA in entityList)
    foreach(entityB in entityList)
    {
      [... move entityA according to its velocity as far as possible ...]
      if([... entityA has collided with the world ...])
         entityA.onWorldCollision();
      [... calculate the movement of entityB in order to know if A has collided with B ...]
      if([... entityA and entityB have collided ...])
         entityA.onCollision(entityB);
    }
}

However note that you probably will need a dependency on the world sooner or later, that is whenever you need functionality of the World: you want to know where the nearest enemy is? You want to know how far the next ledge is away? Dependency it is.

Answer 4

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.

Answer 5

The Player should ask the World about stuff like collision detection. The way to avoid the circular dependency is not to have the World have a dependency on Player. The World needs to know where it's drawing itself: you probably want that abstracted further away, perhaps with a reference to a Camera object which can in turn hold a reference to some Entity to track.

What you want to avoid in terms of circular references is not so much holding references to each other, but rather referring to each other explicitly in code.

Answer 6

Whenever two different types of objects can ask each other. They will depend on each other as they need to hold a reference to the other one to call its methods.

You can avoid circular dependency by having the World ask the Player, but Player cannot ask the World, or vice versa. In this way the World has references to the Players but players don't need reference to World. Or vice versa. But this won't solve the problem, because the World would need to ask the players whether they have something to ask, and tell them in the next call...

So you cannot really work around this "problem" and I think there is no need to worry about that. Keep the design stupid simple as long as you can.

Answer 7

Stripping out the details about player and world, you have a simple case of not wanting to introduce a circular dependency between two objects (which depending on your language may not even matter, see the link in Fuhrmanator's comment ). There are at least two very simple structural solutions that would apply to this and similar problems:

1) Introduce the singleton pattern into your world class. This will allow the player (and every other object) to easily find the world object without expensive searches or permanently held links. The gist of this pattern is just that the class has a static reference to the only instance of that class, which is set upon the object's instantiation and cleared upon it's deletion.

Depending on your development language and the complexity you want you could easily implement this as a superclass or interface and reuse it for many major classes you don't expect to have more than one of in your project.

2) If the language you're developing in supports it (many do), use a Weak Reference. This is a reference that does not affect things like garbage collection. It is usefull in exactly these cases, just be sure to not make any assumptions about whether the object you're weak referencing still exists.

In your particular case, your Player(s) could hold a weak reference to the world. The benefit of this (as with the singleton) is that you don't need to go searching for the world object somehow each frame, or have a permanent reference that will hamper processes affected by circular references such as garbage collection.

Answer 8

As the others have said, I think your World is doing one thing too many: it is trying to both contain the game Map (which should be a distinct entity) and be a Renderer at the same time.

So create a new object (called GameMap, possibly), and store the map level data in it. Write functions in it that interact with the current map.

Then you also need a Renderer object. You could make this Renderer object the thing that both contains GameMap and Player (as well as Enemies), and also draws them.

Answer 9

You can avoid circular dependencies by not adding the variables as members. Use a static CurrentWorld() function for the player or something like that. Do not invent an interface different from the one implemented in World already though, this is completely unnecessary.

It is also possible to destroy the reference before/while destroying the player object to effectively stop the problems caused by circular references.