ECS vs. object-oriented and dynamic typing

[Pleca]

Please, let’s keep both approaches. For example, in a dungeon filled with many torches, I’d use ECS for efficiency, while for a few unique objects, I’d prefer the OOP approach for simplicity. I’m with reepblue on this one.

[Alienhead]

I'm on a plane currently and won't go into detail, but a one script system totally deprives the ability for add-ons and extensions.  Example, my player control is a solo component,  if I want to add the ability for a shotgun weapon I simply add the shotgun component to the player and he can use that ability.  I can further add more abilities to the player by assigning additional components. 

 

[Alienhead]

How is that well known engines such as Unity and others have worked around the issue you present and still allow multiple components??

[Josh]

13 hours ago, Dreikblack said:

So please do it?

Are you sure this is needed? In the last build I got rid of all virtual inheritance because it does not appear to be needed for anything, and I think you said there was no problem in your previous post.

Regarding components, one possible solution might be for the editor to detect base components and display them as if they were separate components. Here is an example of a base component and another component derived from that:

class MyBaseComponent : public Component
{
    Vec4 lower;//"Min color" COLOR
    Vec4 upper;//"Max color" COLOR
  
    void Update()
    {
      	Vec4 color;
      	color.r = Random(lower.r, upper.r);
      	color.g = Random(lower.g, upper.g);
      	color.b = Random(lower.b, upper.b);
      	color.a = Random(lower.a, upper.a);
      	GetEntity()->SetColor(color);
    }
};

class MyDerivedComponent : public MyBaseComponent
{
    Vec3 speed;//"Speed"
  
    void Update()
    {
      	GetEntity()->Turn(speed);
      	MyBaseComponent::Update();
    }
};

When you add MyDerivedComponent to an entity, tabs for MyDerivedComponent and MyBaseComponent would appear, with properties displayed in each one, as if they were two different components.

The differences would be:

• You would not be mixing and matching different components in the editor. Combination of different components would be achieved by declaring a class that inherits another.
• You can't have two properties or methods with the same name, since they would overwrite each other, since they are on one object.

This might solve several problems:

• This would retain visual separation of properties and flowgraph subobjects in the editor.
• This would retain separation of code in different files.
• Problems involving the order different component methods are executed in would go away.
• The component would just be a single object to access in code.

[Dreikblack]

14 minutes ago, Josh said:

I think you said there was no problem in your previous post.

Because i forgot to make it Object's child. As() and Self() are pretty useful. And then i would able to pass it as Object in LW5 API methods. Also i thought it would needed to GetComponent() but gladly this one works for any class. 

[Josh]

Just now, Dreikblack said:

Because i forgot to make it Object's child. As() and Self() are pretty useful. And then i would able to pass it as Object in LW5 API methods. Also i thought it would needed to GetComponent() but gladly this one works for any class. 

Okay, if you find that useful, I don't have any objection to doing this in the next build.

[Dreikblack]

51 minutes ago, Josh said:

You would not be mixing and matching different components in the editor. Combination of different components would be achieved by declaring a class that inherits another.

It's not an option at all for cases when you need different components for same entity.

53 minutes ago, Josh said:

This would retain separation of code in different files.

And again it will not since you don't do deriving for totally different components and sane persons will not hundreds derive combinations when they can do dozen components for everything already with proper system which you want to destroy without any single good reason to do so.

55 minutes ago, Josh said:

• Problems involving the order different component methods are executed in would go away.
• The component would just be a single object to access in code.

Just use single component per entity without making to so it everyone else, you can do it already. Don't break what already works millions time better than you want to do. Stop ignoring GetComponent() method existence for making excuses.

[Alienhead]

It seems like Josh's mind was made up before starting this thread anyways.  Before I waste anymore time I would like to know if you plan on going through with this new system so that I may start my search for an alternate product.

[beo6]

Why remove the option to create reusable components?
This sounds like you want to get rid of this to force people to always reimplement everything to fit their needs for no reason.

I think it worked perfectly fine for Leadwerks 4.

After some thought through standards where established, many components where made in a way to be compatible. Like the 1st person script.

Quite a few used my "Amnesia" - like notes script (i think). And it allowed some people to quickly put together some games.

 

[Dreikblack]

@Joshyou keep ignoring any criticism on this topic, but i will try again.
Multi-components allow:

• To keep logic components in one place. Even if components without entities will appear (meanwhile you want to do opposite...) there is still a lot of examples like thunder - point light with components that: 1. Make light appear and with-time reduce brightness. 2. Do sound. 3. Trigger 1 and 2 on random time. All 3 components are used in a lot other cases.
• Entity and component being different classes in good thing - no overriding for same names, no extra bull**** when you looking for something with autocomplete. Also component may exist without entity and i use it (by creating with own method).
• Mix behavior and avoid tech debt aka duplicated code in this case. Some of real examples beside above: 

1. Brush entity with: Tile trigger (when unit enters in trigger) which trigger dialog component (to text for player) and also trigger Objective trigger (to make objective about finding this door complete), usable trigger - context button to open door. All of at same entity and would be longer to make with worse result if we had no multi-comp system.
2. Padlock on door  (brush with lock texture): UsableObject component - for highlighting this entity and trigger usable trigger from above by picking. Second component is RemoveObject - for removing this lock when door is open.
3. Animated model: on signal it's start moving with Way Mover component and start animation with another component. And i would also use third component to remove entity from scene in next game, but currently it's in WayMover.
4. Similar combo for weapons on table + they have QuakeModel component for fixing their model.
5. Tile trigger, dilaog + SoundEffect to make sound when unit enters this trigger.
6.  Button entity: Trigger on damage component + WayMover to make move this entity on trigger.
7. Pillar with WayMover and EnvLevel component - to hide entity when it's too close to camera
8. Acid brush - Acid component + WayMover.

In result with enough components you can make a levels without coding just by combing components.

Made up by you cons:

Quote

With mulitple components, you have to know exactly what component you are looking for.

With single one it's exactly same, even if you screw it up by mixing with entity - you NEED to know what component entity have to do anything with that. You can't do entity->health = 0 in both Lua and C++ because Component don't have and you cast it in C++ anyway (and it's easy to do currently - just use GetComponent() and in lua it will be an error if table (component) don't have it.

For C++ you also can cast not to even base Class, but interface class if needed.

By the way in reality you never have cases when entity have few component with same method which you want to call. Like why the hell same entity would have two different health or use()? You just do GetComponent<Interface> or GetComponent<SomeBaseComponent>(), call once whatever you want and thats it.

And in Lua you use single component which have function for sure you just do in Lua without loop and knowing which exactly component is that:

entity.components[1]:Use()

In result nothing will be changed in that matter and problem simply does not exist.

If anything, tag system for components would be helpful for Lua to determinate if abstract component have variable and functions quickly. Something like:
local components = entity:GetComponentsByTag("Health")

Quote

One script, one entity

Why it's would be bad already described in Multi-comps pros. You are too lazy to write GetEntity() it's your personal problem.

Quote

ECS totally throws that away and makes things far less modular and reusable.

Sorry, but it's literally random bull**** of yours and i explained above how it's opposite, meanwhile new approach would break everything and make people do same stuff all over again in same scripts/components without ability to combine functionality. If you can't make combinable components it's only your own skill issue. And most likely reason why FPSPlayer and footstep components are not work together (which could be non true after another your false accusations) is how messy FPSPlayer component is - it's have too much stuff that have to be in different components. And you want all components be that bad...

Quote

downside of multiple components is never knowing what type of object an entity really is supposed to be.

Aaaaaaaaaaand nothing would be changed for single component. In most cases entity type does not matter and when it does you just use specific component for specific entity type. And ofc. it's easy to check entity type via casting if you need.

Again nothing would be changed in that matter and problem simply does not exist.

Quote

Any time you call a method, set a value, or get a value from another entity, a for loop is required. This is tedious and makes me want to avoid entity interactions, unless I absolutely have to do something.

Entity interactions get very complicated and ambiguous

Retrieving a value from another entity involves a lot of code and is ambiguous.

Another example of made up issues because @Joshignores Entity::GetComponent() existence.

 

Short conclusion:

Mono-component gives no benefits at all and hurts everything that multi-components system gives, and would do big damage for both novices and experience engine by removing ability to make and combine simple and clear components, beside confusing people by combing entity and component scopes.

[Alienhead]

I would like to officially withdraw my opinion on this subject,  I do not wish my opinion to have any sway on the outcome due to the fact I have thought long and hard on this matter and decided to move on to a different product.  I bid you all a fond farewell, I've had some fun years here!

[AnthonyPython]

I agree completely with dreik and reep on this matter, seems to be completely a none issue, I prefer making specialized components like a health or armor component etc, so more multi-component less than mono, instead of always doing it as a mono-component. But I do like to do it some times as a mono component from time to time so I do a mix of both.
I think this is more a developers preference of how they want to approach something more than an actual issue.
If ya want to do mono component tutorials that is fine, but do not try to force a very specific methodology with such a late change idea onto current developers.
It would be different if this was the path you wanted to do from the start, and no one would be bothered about it but that isn't the case. Especially when as reep pointed out is too close to 1.0 release.
So yea a complete none-issue.