2

I'm architecting a component-based game object architecture. In my situation, I have renderables and physics objects. A render scene contains renderables. A physics scene contains physics objects. I have a game object that has a renderable and a physics object. Each of these has absolutely zero coupling. They're even in separate libraries.

One of the more obvious pieces of data a game object needs is position and rotation. Both the renderable and physics object need to read this information and in some cases write to it. What are some efficient approaches to handling information that is specific to a game, not a component, but is needed by some components?

Sion Sheevok
  • 4,057
  • 2
  • 21
  • 37

1 Answers1

2

This seems a slightly odd architecture to me - you will be forced to do a lot of work to keep two separate scene graphs synchronised and you'll probably find it impossible to keep them completely decopuled (the situation you are describing in the question is an example, but there will be lots more.....)

I'd encourage you to think about a single game object graph. You can still have physics strategies and render strategies for each object, but I'd suggest seeing them more as "plug-ins" to the game object rather than separate object graphs. This way the game object can have a position / rotation vectors that are accessed by both physics and render components.

An alternative, if you don't fancy re-architecting to a single game object graph, would be to separate out the position / rotation information into a separate structure, e.g. a large array of vectors. Both Physics and Render objects can share access to this structure.

This would imply:

  • Both Physics and Render objects would need to know the index of their own position in the array (either by storing the index directly, or by some form of hashed lookup)
  • Both Physics and Render objects would have to be happy with the same position / rotation formats
  • You'd have to to some extra bookkeeping as objects are created / destroyed
  • You'd have to be a little careful about concurrency, e.g. what happens if new Physics objects are added while rendering is taking place?

Overall I'm not sure that this gains you much...... but it might make sense if you have some other constraint such as the design of a 3rd-party physics library.

mikera
  • 105,238
  • 25
  • 256
  • 415
  • *Nod* That's precisely my problem. I'm trying to keep render logic decoupled from physics. Allow the render logic to read from a render object which is updated by a render component that reads from an object. The object reads from and (sometimes) writes to its physics component, which reads from/writes to the physics object. I think I merely have to rephrase my thinking and separate the idea of a component from the system object. Allow the components to couple, but not the systems. I think that would get the best of both worlds, by your answer. – Sion Sheevok Dec 08 '11 at 00:40