0

I'm currently reading "Game Programming Patterns by Robert Nystrom". The book explains why you should "un-couple" the different components of a piece of software, in my case a game.

Unfortunately, I already started hacking together a little game, and in there I have a Physics-Class which holds all the game-objects (Ranging from static things like... rocks, to other things like the player and the enemies) and applies physics to them on each update-tick. I then have a render-loop in my Main-Class, which loops through the objects present in the physics-world and renders them on the screen.

So here comes my question: How can I change my code in order to "de-couple" my Physics-Class from the Rendering-Part of my Main-Class? Should I maybe create two different objects for each game-object (I mean, that would complicate everything, so I don't think this is the right thing to do)?

Kind regards

Fly
  • 810
  • 2
  • 9
  • 28
  • This is really a broad question, so I will make a broad suggestion. Your physics engine should deal only with interfaces. Have each concrete object expose an interface that the physics engine cares about, and pull them out of the physic engine. – dbugger Dec 25 '14 at 01:29
  • @dbugger Thanks for the answer! But, that way, all of mine components will still be coupled, since the objects are stored someplace, and the components access it from there? In my example, the Objects were stored in the Physics Engine and the Render-Component accessed them from there; If I get your idea right, it's just the other way around: Objects stored in, let's say, the Render-Component and the Physics-Engine accesses them from there? Or did I misunderstood something? – Fly Dec 25 '14 at 11:22
  • make a third assembly that has the objects – dbugger Dec 25 '14 at 16:12

0 Answers0