0

I'm making a little IDE and during programming activity i am facing a little difficulty that i'm trying to explain. I have two layers (cpp files), one for the more low level entities (entity itself, vector etc) and one for the higher level (the IDE level, like buttons etc.):

in entities.h

struct EntityComponent{
};

struct a_component : EntityComponent{  //cannot change this
};

struct Entity{
    ... //entity data like childs, parent, transforms, and so on

    std::vector<EntityComponent*> components;
};

in ide.h

struct GuiButton{...};
struct GuiProperty{...};

Now i wants that every entity and every component takes a pointer to a more higher type declared in the ide.h layer, for example a gui element to draw the entity or component data, so i have made:

in ide.h

struct EditorEntity : Entity{
 GuiProperty* properties;
};

struct EditorEntityComponent: EntityComponent{
 GuiProperty* properties;
};

I can use EditorEntity in the IDE in place of Entity and use properties. Problem arises when i want to do the same with the EntityComponent structure: every component in the low layer is declared inheriting this EntityComponent structure, so i cannot change this value cause is statically declared in every component definition.

I need a EditorEntityComponent : EntityComponent that contains a more higher type Property but i don't want place an ugly pointer in the EntityComponent repr. Any help?

freesoft
  • 57
  • 7
  • Are you familiar with the "a bag of apples is not a bag of fruit" maxim? – n. m. could be an AI Dec 18 '17 at 17:01
  • @nm yeah i know :) – freesoft Dec 18 '17 at 17:08
  • Correct me if I'm wrong but it seems you have this exact situation here. – n. m. could be an AI Dec 18 '17 at 17:54
  • Pretty much what I'm saying. The composition (or entity component paradigm) doesn't work unless you let it. EditorEntityComponent is EntityComponent, and using the framework as intended is NOT "ugly". – Kenny Ostrom Dec 18 '17 at 18:24
  • @nm yeah it seems, but not too.If you are experts you cannot say only two words about this – freesoft Dec 18 '17 at 20:15
  • How about a little more on the big picture design. An entity has (and owns) components. What do properties do? Why do you have properties on both the entity and the component? If properties are so important to ECS, why are they not handled in the base class? – Kenny Ostrom Dec 18 '17 at 21:20
  • i explain you: i have two files, one with low level stuff and another with higher level stuff.the entity has low level stuff in it, but had to be visualized in the ide so he needs property that are declared in the higher level.i cannot put an elemnt of higher level directly in the representation of the low-level object.understand now? – freesoft Dec 18 '17 at 22:51

1 Answers1

0

You are talking about the "composite" design pattern https://en.wikipedia.org/wiki/Composite_pattern

The example in the famous book "Design Patterns" (by Gamma, Helm, Johnson and Vlissides) actually is a gui editor, exactly what you are trying to use it for. If you can get a hold of that, read that chapter.

Even when following well known guidelines, there are still many ways to do things. What follows is entirely my own opinion:

The mistake you are making is trying to use the typing system to control what components can be attached to other components. But the has-a tree heirarchy needs to be the same from the top down in order to be easy and reliable.

Instead, you can control what components are allowed under each class by giving it the responsibility of creating those. If your entity editor creates each of its entity editor components, then no other class can ever assign it the wrong type.

Kenny Ostrom
  • 5,639
  • 2
  • 21
  • 30
  • 'The mistake you are making is trying to use the typing system to control what components can be attached to other components'. i don't want to control, i wanna only augment representation of a base class – freesoft Dec 18 '17 at 17:10
  • After a little research, I see there is something called entity component system, which is basically "composition" plus "strategy", going by the much older and better known design patterns. I do not understand what you are saying about augmenting representation -- can't you do that already by just putting the EditorEntityComponent exactly where it belongs, in the vector of EntityComponent objects, which it is? – Kenny Ostrom Dec 18 '17 at 17:14
  • I think you did not understand the question, i'm sorry maybe i can explain better, reediting my initial message – freesoft Dec 18 '17 at 20:21