[JeffR]

Game Class E/C conversion rough breakdown:

Components

• Mesh Render(Done)
• Animation(Done)
• Sound Emitter(Mostly Done)
• Collision(Done)
• Item Rotation(Done)
• Camera Component(Done)
• Player Physics Controller(Done)
• Simple Physics
• Rigid Body Physics
• Vehicle Springs
• State Machine(Done)
• Damage/Destruction
• Particle Emitter

Game Classes
ShapeBase

• Mesh Render
• Collision
• Animation
• Sound Emitter
• Fade/Cloak
• Damage/Destruction

Player

• Same as Shapebase
• Player Physics Controller

Item

• Mesh
• Collision
• Animation
• Item Rotation
• Simple Physics

Vehicle

• Mesh
• Collision
• Animation
• RigidBody physics
• Vehicle springs
• Engine/Control component?

Weapon

• Mesh
• Animation
• Collision(Maybe a separate, simpler version that just raycasts to detect wall penetration?)
• State Machine

This is a rough starting list. I'll do up some of the other game classes(like turrets) next, but this should be a good block-out point. The logic for the components not yet done can be peeled out of the respective reference Game Class(like the vehicle springs being pulled from the vehicle class)

[Happenstance]

This is definitely helpful and gives me a better idea of where the E/C systems are at. @

Azaezel also provided me with a basic SoundComponent last night to look over. I think at this point I'm going to try putting a couple basic entities together just to see how everything fits together. I think eventually working my way up to a fully functioning Item object (renders a mesh, spins, reacts to collision) sounds like a reasonable goal.

[JeffR]

@ Happenstance
Hey dude, you said you had made some headway with your work towards this. Did you have 'em up on a branch or repo anywhere yet? Been itching to have a look-see

[Happenstance]

I'm out of town this week but made a note for myself to get these uploaded this weekend.

[Bloodknight]

can I just point out that my ignorance of this showed the other day when somebody popped into discord to ask about documentation/examples of how e/c works, and I didn't think this was part of the engine, only it is a big lump of an unconnected engine.

I will also note that this IMO is an example of why semi-functional WIP things should maybe not be so easily discovered.

[Happenstance]

@

JeffR - I'm back in town now and starting to look over what I was working on a few months ago. Still reviewing stuff but it looks like I made a sandbox level to test entity composition and started piecing together an Item object built from components. Also started working on a 'simple physics' component based off of the physics in the default Item class before realizing that the 'physicsBehavior' component is basically an unfinished version of that. I think I stopped there and started to question the thinking behind creating multiple physics components instead of making a generic rigidbody or kinematic component that could be used for everything.

Also made a few random notes while working on this:

1). Bugs with Mesh component:
* deleting component doesn't stop it from rendering?
* 'enabled' toggle has no effect?
* entity scale has no effect on mesh scale?
* Rotation component seems to cause it to render multiple copies - one static, one rotating?

2). Need light component. Items can emit light - support for point with animation

Not sure there's anything substantial here, just some starting points to poke & prod.

[JeffR]

Sounds like a good start.

And yeah, I've hemmed and hawed over stuff like multiple physics components as well. I think ultimately it makes sense at least to have probably 3 main ones:

PlayerController, which is basically our normal-player-tailored physics component, to best facilitate player control
SimplePhysics for items and other things that need to be able to fall, and maybe be physics impulsed, but don't need to spend the full rigidbody sim overhead on
RigidBodyPhysics for everything that should get the full rigidbody sim treatment.

Between the 3, i think it allows the most flexibility of what sort of objects you can quickly slap together without needlessly overcomplicating things. Sounds like you were largely in agreement on that, so lets go with it.

For the part with "'physicsBehavior' component is basically an unfinished version of that.", That was the start of an effort to sorta have a core common blob of component behaviors in a "component" that real components could inherit from and would reduce code duplication and simplify component lookups(ie 'get be whatever sort of physicsComponent we have'
Ultimately as I looked into systems and the like I started gravitating away from that notion.

So yeah, I think physics are probably the most specific, complex sort of component we'll have to sort out, so do we have a preference in how to organize them? Stick with the parent common component? Shift to a system style where all our logical implementations are done through a common "PhysicsSystem" and the components just dictate what/how it's run via the system? Few ways to approach that and feedback/opinions would be good.
For organization purposes, I'm kinda inclined towards the system style myself, but I'd be happy to hear your opinion with it.

Also, good spots on the mesh component stuff, I'll take a look

For a light component, I'm not opposed, just wondering if lights make the most sense as distinct object types, but can be easily mounted, or if them being a component makes the most sense.
Lights themselves are notionally a little snowflake-y so I can kinda see it going either way. If we make them components though, that lets us take the opportunity to clean up the expose fields by light type, simplifying them in the inspector, which is always good.

[Happenstance]

Having a PlayerController that mimics the existing Player class movement makes sense to me and seems in line with what other engines are doing. I could see making a case for SimplePhysics just being the RigidBody component with some options toggled off (simulating gravity & mass but disabling the advanced collision/penetration bits) just for simplicity's sake but that also runs the risk of bloating the RigidBody component. Need to think about this a bit more.

The light component is something I'm not sure of, either. On one hand I like the idea of building entities entirely out of components so that the composition and management of them is done in a standard way. Having lights be a separate object feels like a strange exception to the design rules. On the other hand the existing light objects work pretty well and I could see a good argument for not adding a layer of entity-component 'stuff' around them.