I have a component that holds a spatial. this is for my PhysicsAppstate. I’m using Bulletphysics.
If this is incorrect. How would I go about using BulletPhysics with ZayES properl?
I did the very same to use jmonkey brains 
needed the spatial only to get out the position and not to display something
The view should reflect the model and not the other way around. Storing a spatial in a component (even if ‘just to get the position’) is like storing a text field in your database ‘just to get the string’.
The physics app state will keep its list of physics-specific stuff… rigid bodies, spatials, whatever… associated with the entity that has the components that it’s paying attention to (whatever those are). Hard to comment further without more details. A spatial is just part of the book-keeping that a system might have to do… it’s not something to put in a component.
In my SiO2 library, I have a standard entity container class I use because the pattern of ‘book-keeping object associated with entity’ happens quite often. You can find it here if it gives you ideas:
Generally you extend it to create and update some kind of object associated with an entity. Like in a ModelState you might have it create Spatials. In a PhysicsSystem, you might have it pull the values from some physical object and apply them to the entity… or pull Velocity or Acceleration components and apply them to the physical object.
Note: if you haven’t already looked at Asteroid Panic it might be one to check as that’s my own ES example.
Ah right I used the spatiial outside the componet system to sync the Position component. But even that is like use a truck to transport a letter.
Yeah I get it in that respect. Those are custom phyiscs. I am using BulletPhysics. Which requires rigidbodies, no?
Does it really hurt having a component to hold a spatial? Only 1 component will do this. It makes creating useful appstates so easy.
Or is this really bad once I get further into my game?
Better question: How would I go about delivering a physics control to my bullet appstate? Which will be attached to the players spatial. or should there be no control and just an appstate
I think what Paul mean is that you should use spatials but only for book keeping but it is separated from the entity. And yes it is bad having a spatial in the component, it is not a clean separation of data and representation. Physics is something which should just influence your position component (location, rotation), to be honest I do not know how, I would maybe use a spatial to get the position and would then update my position component. But maybe there is a simpler way?!
About book-keeping the visual app state I wrote for the invader is a good sample, the book keeping is done with that hash map of entity id to spatial thing… You should do somehow the same with the physic stuff. But as I said, I have no clue how.
So I store the spatial in my visualapp. and access it from other apps using the EntityId?
Would it be wrong to attach controls to that spatial?
Ok then I do not understand why you want to access it from other systems as it is only to display it. It sounds like you still think in terms of old fashon OO programming and not ES. It is a different approach and you better let go OO ideas on that level of abstraction. You can have OO objects but outside ES that is most important.
Having controls on that spatials for book keeping does not sound wrong, but it really depends what you want to achive with those controls.
Because I need that spatial to attach the physics bullet rigidbody. Without attaching my character control to it Bulletphysics is useless. Unless I’m doing it wrong
A RigidBody and a Spatial are really two different things. JME’s bullet integration turns a rigid body into a control and adds it to a Spatial for convenience… because it doesn’t have an ES to manage those updates.
You could have a system that just manages spatials per entity that displays anything visual. And another system that manages RigidBodies for anything physical. These two sets of things are not the same thing. When a rigid body moves it updates the entity. The visual system then moves the spatial.
This separates the code into core concerns that don’t care about each other. It means if you add some visual thing later you don’t have to change any code… just create an entity and give it the proper components. It also means you can do the same thing with physical stuff. Or move entities in non-physical ways. Or have entities that only exist physically and not visually. Or exist as physics and as sound but not spatials.
In the end, that’s kind of the point of an ES.
Yeah thanks. I just can’t figure out completely yet. I’m playing around with it at the moment. I’ll get it eventually.
So I would have a RigidBody component. And that rigidbody updates the entities position component? How would I detect changes in the RIgidBody?
Nah, probably you’d have things like a Mass component and a CollisionShapeType component or something. Your physics system would create the rigid bodies from components.
A RigidBody is a book keeping artifact of the physics system. It’s not a component or data in a component.
Ohhhhh. Okay it’s starting to make MUCH more sense. It just feels so unnatural.
Yes… until it doesn’t. 
For those of us who have been developing for a looong time, I had so many ‘best practice’ habits I had to drop or relearn for an ES. Now all of my games are ES based because I can’t see doing it the old harder ways anymore.
Here’s another thing I can’t understand. I’ve created a component CollisionShape. That constructs with a CollisionShapeType (this is an enum). What is the proper way to pass in the shapes specifications? Like in a capsule has radius and height. Is not the same as a Sphere’s specifications, which is just radius.
Would I pass in an array of floats? I feel like I’m using ecs very incorrectly that’s why I am asking so much
EDIT: I ended up just adding the CollisionShape in the component constructor.
CollisionShapes are kind of just data… so it’s probably ok to put them in the component.
I generally try to be more abstract than that but it’s only preference by that point.
I think I would store the model data (collision shape, model) in a json and operate entierly with the model component. In my invader example it is jist the j3o file name. But I guess your way is not that wrong.
I have in the physicsystem a mehcanism that kinda does
here is entity give me physicshape for or null
eg.
@Override
public CollisionShape provideIfPossible(final IEntity entity, final PhysicObject physicObject) {
final Model model = entity.get(Model.class);
final MultiAxisVehicle vehicle = entity.get(MultiAxisVehicle.class);
if (vehicle != null && model != null) {
return this.ressourceDb.loadHullShape(model);
}
return null;
}
and
public CollisionShape create(final IBaseEntity matched, final PhysicObject physicObject) {
CollisionFactory.LOGGER.debug("Request for {}", physicObject);
CollisionShape rv = null;
for (final ICollisionShapeProvider provider : this.customPhysicProvider) {
final CollisionShape canProvide = provider.provideIfPossible((IEntity) matched, physicObject);
if (canProvide != null) {
assert rv == null : "Multiple providers for " + matched + " found";
CollisionFactory.LOGGER.trace("Shape provided by " + provider.getClass().getName());
rv = canProvide;
} else {
CollisionFactory.LOGGER.trace("Shape not provided by " + provider.getClass().getName());
}
}
return rv;
}
note i use a own es, but it is pretty similar to zay from the concepts
Physicobject contains actual data, like
mass
friction
inertia
type (kinematic, static, ghost, dynamic)
The shapes are all build based on the actual data in the entities as shown above.
Only the physicsystem knows about that, it basically contains a hashmap
uuid to rigidbody
since the physicspaces are a component in my case as well, each physical object is attached to the parents physicspace, allowing me to nest physicpspaces. Eg a spaceship has internal physic (for walkin inside) and external (for flying getting hit ect)
And yes, I kinda required a lot of time before I fully understood what es meant as well, it felt really unnatural at first, but now it is really great and already allows great flexibility. (for example you can store almost all in game objects, based on the mass and volume in containers without further manual logic required)
1 Like
The beauty of ES comes when using. For example I needed kind of a entity follow entity and wrote a system for it. Then I wanted a light follow my entity and I had that with nearly no additional code it was just already there. Same for my camera follow my hero entity nearly no additional code, just a few lines.
I had to learn think the ES way, was basically the most difficult thing beside having a visual starting point. But now that feels much more natural to me. I even start think the ES way in my daily work which is not game releated at all
Yeah, likewise. Data oriented approaches have many applications as it turns out.