Correct way to use Farseer Physics in XNA

Question

I am using Farseer Physics for my 2D sidescroller game and I'm not sure how to proceed with it. I currently have a Sprite class (handles nothing but graphics), a GameObject class (contains specific object info like hit points), a World object which contains the list of Bodies, and a Level object which contains all of these objects.

Originally I was trying to keep track of the Sprites, GameObjects, and Bodies separately because I felt that would provide loose coupling but it quickly became a headache.

So my new idea was to add a Sprite member to the GameObject class but I'm still not sure how to maintain the Bodies because they have to communicate with GameObject.

Specifically, my issue is this: The position of the Body is used to draw the Sprite inside of the Level. In order to do that I would have to maintain a link between GameObjects and Bodies. Is this correct or is there a better way to architect my game?

If any of this is unclear please ask and I'll try to clarify. Thank you in advance for any help.

Answer 1

What I do is add a Texture2D directly to my game objects. I have another class called an AnimationController which manages my source rectangle/frames/timing for drawing animations from the texture. I suppose this would be similar to what your Sprite class does.

If my game object will have a physics body (i.e. players, enemies, etc.), I add a Body property to it as well. If my game object doesn't have a physics body, then it will just have a regular Vector2 Position property (in world units).

Now, my game objects usually have Update and Draw methods. If it has a physics body, I draw the texture at the Body.Position or otherwise at this.Position using the source rect from my AnimationController. In the Update I update the AnimationController so it can switch frames and whatnot and then do whatever else for the object.

So, I would say add Sprite and Body fields/properties to your game objects that need them and let the game objects decide how to use them.

Remember, you can always go back and refactor the code later. You don't want to get stuck in a rut where you're spending more time thinking about programming your game than actually programming it.