Using An ES With Physics

Articles, Presentations, etc

• How we use Box2D with Artemis - Really worth reading.
• Tom's presentation - He talks about Physics during this presentation. I think around the 2/3ds mark.
• Appropriate level of granularity for component-based architecture
• Reddit question - integrating Bullet physics with the RDBMS approach

Discussion

(Lots of questions about this… needs filling in ideas here … someone type something and delete this text)

• This is just some off-the-top-of-my-head-way-too-late-to-actually-be-thinking-about-this stuff. I use the box2d physics package. A physics "body" has quite a bit of data wrapped into it - transformation matrixes, position, velocity, rotation, size, shape(s), etc. Could you create "shadow" (i don't know if that is the right term - just making shit up) components, which would pull the specific data they needed from the physics body? Ie. we have a position component, which needs an X and Y value. Normally, these would be public attributes on the component (struct/class/DB field/whatever). However, when creating the position component, it is given the physics body, and pulls/pushes to that bodies X, Y value. This then ties the position component directly to the physics system, but allows you to work with only the position data in the Position System… Which i guess you wouldn't even really need, since the Physics system does most of what the Position System would do. Rendering (ha) most of my brilliant idea moot. Rats.
• After spending the night/day thinking about this, i'm still no clearer. Was thinking of having a PhysicsComponent, which would then have all those values a physics engine body would have. But then when it comes to the rendering system, you'd want both physics bodies and non-physics bodies. So it wouldn't be a simple collection of Renderable Components and Position Components, but you want Renderable AND (Position OR Physics) components. Not sure what the thinking is of more complex queries then the simple ANDs i've see so far. Although if we really are thinking of that data as being "in a DB", then complex ways of querying that data should be ok. Maybe.
  • I'd suggest the PhysicsComponent have the physics properties you need, like the body and then have a DummyPositionComponent that extends the default PositionComponent. This dummy will simply have a reference to the PhysicsComponent in order to return the X and Y variables of the physics body. So now, for a Physics entity you'll have a PhysicsComponent, DummyPositionComponent and RenderComponent. The Render System only cares about the DummyPositionComponent and the RenderComponent. So you let the physics engine do it's thing and just get the results whenever needed (i.e. when rendering). If you want control over the physics engine, I think you should apply forces and don't directly change the position values. But I don't have enough experience on this.

Physics done as a system I've been playing around with using Verlet integration as a simple Physics base (in AS3/Flash). I'm thinking about how to use Systems and Components to implement the physics. Having a "physics" components, which would hold the OldX and OldY values, which are required for Verlet Integration, then we'd have a Verlet System, which would take a Position component (x, y) and Verlet component (oldx, oldy) and do the simple integration. Where i start (ahahahah) to get confused/unsure is how to define the relationships between individual verlet points - to make sticks (2 points), cubes (4 points, 6 sticks), triangles (3 points, 3 sticks). Do you break systems down into very small parts? ie. have a stick-constraint system, which only deals with solving the constraints between 2 points/1 stick. You would then have some kind of Stick component, which would contain a reference (?) to another point? Or perhaps a stick component has p1x, p1y, p2x, p2y values in it… This is where a fly-weight or references would help, maybe. I'm unclear as to whether you can have "pointers"/"references" to other data in a component…

• So, can you have a component which has a reference to 2 other entities (the 2 verlet points)?
• Or, in re-reading the blog-posts, would it be possible to reference the other components themselves, rather then the entities.
• This would also allow for System based collision detection/reaction using whatever form of detection makes sense for your game. You could then, as an example, have a component which could hold the "shape" which the system would then use to check collisions against.
• Ah! I just watched Tom's presentation. He talks about Physics systems, like what i've been blathering on about, and rather then using an existing tool, writing something that works with an ER system from the get-go. Now, i'm no physics expert, but i can do Verlet pretty easily (because its pretty easy). I'm going to work on a verlet system/component, but i'd love some help/suggestions on how to partition the data. The issues i talk about above - having a position for a verlet "point", but also having to deal with constraints (creating a Verlet stick - constraint w/ 2 points), and how to pull out the data for that into components.
• In thinking about this, i'm having a really hard time figuring out the granularity of an Entity. Is a single Verlet point an entity, or is a Verlet Stick (2 points, 1 constraint) an entity? How do complex object, with lots of related data, get converted into components? Can you have more then 1 instance of a component associated with an entity?
  • You are complicating this too much. You should simply have a PhysicsComponent that has a list of points and sticks. The physics engine should handle all the simulation steps. The only thing you care is rendering that object (or adding more functionality). But try to avoid duplicating what the physics system is already doing for you. Check this out: Appropriate level of granularity for component-based architecture -pek
  • Ha - thanks for this link, I said "just do it", and went with the simplest thing that would work, which is what you have suggested. I've got a VerletPhysicsComponent, which holds a bunch of points and constraints. The VerletPhysicsSystem then uses this to do all the interesting integrations. Sometimes i do have a tendency to go towards "Architecture astronauts"-style. More experimentation will help too. Thanks again.

Links between components

I am trying to find appropriate or efficient ways to link or represent links between components.
Relevant for collisions, scenegraphes, hierarchies of entities, …

Questions

1. Relations between components:
   1. Do you not allow components from linking to other components ? To other entities ?
   2. Do you use one to one, one to many or many to many relations ?
   3. What happens when the relation is broken ?
   4. What happens when one of the components is removed/destroyed ?
   5. Do you use double links ? Or maybe some kind of link manager outside from the components ?
2. Components ownership:
   1. Can a component own other components ?
   2. Can you automatically create sub components when a component is created ?
   3. Can you automatically destroy the sub components when the owner component is removed ?
   4. Can a component have different owners ?
3. Practical problems:
   1. How do you keep in sync the position of the different sprites that compose an entity ?
   2. You have an arm made of a variable and dynamic number of specialized parts, each part can be rotated independently. How do you get/compute/store the position of all the parts ?
   3. You have multiple groups of monsters that you want to move between different positions on the map. How do you do that while keeping the monsters grouped ?
   4. How do you represent a network of roads that the cars can take ? How do you do pathfinding on it ?

Discussion

• For components ownership, see the Java Entreri and its Owner Ownable classes.
  • Doesn't it defeat the "no logic in components" rule ? - jlgrall
• Component ownership is used to automatically create/destroy component B when component A is created/destroyed. Alternative: use components events: onComponentCreated, onComponentDestroyed, … and let systems listen for specific types of components. - jlgrall