Using Entities and Components at their best?

#1

Hi there ! I started to read Paradox’s samples yesterday, and I must say I find the whole thing quite interesting ! I always searched for a simple game engine that wouldn’t “do too much” (thinking of Unity), and this looks like the code-centric engine I was looking for !

I just happen to have some questions about entities, for their true purpose isn’t quite clear for me. I started to code my own first “game”, after reading lots of sources, and the way the engine manages its entities is a bit confuse to me :

I understand that an Entity is composed of Components, each type of components allowing several behavior/mechanics. What I don’t understand is : How comes things like translation can be implemented in the Studio and not custom attributes like speed ? What I don’t get is, if I come to code, say, a basic physics system with a couple of balls rushing towards a gravity well in space, I have to implement that speed factor. Then I’ll have the ball’s position defined as a component, and its speed defined in a Ball class, which will also contain an Entity as one of its members, right ?

So my class “structure” will be the following (according to the SpriteEntity sample) :

class Ball:
├─Entity:
│ ├─Position
│ └─Collisions
├─Speed
└─Other attributes like color, etc.

Isn’t it a bit, well… unlogical ? I just think I’m getting something wrong, thus I don’t think I got the purpose of Entities right. Could someone explain how Entities can and should be used ?

Thanks in advance !

1 Like
#2

Hi Elarcis,

Entities and components provide the extensibility and ease the processing of entities within the engine. Components are like dynamic properties, as the engine is able to process efficiently entities for a specific type of component (through entity processors)

A component is considered as an attached behavior on an entity. It is well suited when you need to attach a behavior to any entity and you want this behavior to be processed in a batch way by the engine. In your example, you could create a BallComponent, and put all your attributes in it (Speed, direction, color…etc.).

But if your ball is not really a behavior but a sealed end-user “entity” of your game, for which you don’t particularly need to process them in an uniform/batch way repeatedly at each frame, but you manipulate them in a specialized/discrete way, then having a class Ball is not unlogical at all and often more user friendly as you can categorize easily the core entities of your game.

So it depends, whether the attributes you want to attach to an entity are a behavior attachable/detachable/batch-processable or a genuine categorization of your entities in your game.

Does it make more sense for you?

1 Like
#3

Thanks for your help!

As these balls would all have exactly the same behavior, it’s indeed starting to make sense. So “all” I would have to do is inherit EntityComponent with a BallComponent and do the same with EntityProcessor, which would take care of updating every Entity “filtered” to have a BallComponent in them ?

Of course, for such a small project this looks like overkill, but I can easily see why it becomes handy when having several different behaviors that you can just switch like that, I’ll give it a shot, thanks!

EDIT:
I must admit fetching the source and analyzing the EntityProcessor and EntityComponent classes certainly helps understanding how they work. All of this is clever.

#4

Note that when we will add ScriptComponent (support to attach runnable scripts on an entity), it will probably make less sense to develop “entity wrappers”, because it will be possible to attach a discrete behavior with its data for a specific entity (as a script instance would contain both data and functions)

#5

I can imagine that.

Will these ScriptComponent be manageable in Paradox Studio, like every other “engine” component ? You’d add a ScriptComponent and the studio would automatically link it to a corresponding cs file in the VS solution ? I think that would be nice, in opposition to custom components, which one cannot see in the studio, although they’re at the very same level of inheritance than “engine” components.

PS:
I successfully inherited EntityComponent and EntityProcessor<T> and it works like a charm, thanks for the advice ! I like the idea of “required flags”, it seems so powerful :slight_smile:

#6

Indeed. Plus, while developing on Desktop, you will be able to modify them at runtime from your code editor and see changes without having to relaunch your game. You will be able to edit these attached scripts from both VS and Paradox Studio.

#7

Neat! I look forward to it, thanks!

#8

So, seeing the documentation on EntityProccessot<T>, I had a couple of questions-

  • What exactly does the generic parameter T represent? The documentation doesn’t seem to list a constraint, so it’s a little confusing
  • Are there any plans to add multiply-keyed systems, such as those which handle multiple components per entity? This is something I saw in the Artemis ECS and seemed extremely useful for keeping certain data discreet but able to interact in an aggregate way
#9

As I understand it, T is usually a struct in your EntityProcessor defining data to be manipulated by this specific processor : TransformationComponent, AnimationComponent, etc. everything that you defined to be a filter in your constructor :

public CustomProcessor()
    : base(new PropertyKey[] { CustomComponent.Key, TransformationComponent.Key })
{ }

That data would then automatically be referenced each time you add an entity via Entities.Add() by overriding the method GenerateAssociatedData() in your processor :

protected override AssociatedData GenerateAssociatedData(Entity entity)
{
    return new AssociatedData
    {
        CustomComponent = entity.Get<CustomComponent>(),
        TransformationComponent = entity.Get<TransformationComponent>(),
    };
}

When processing your entities in the Update(GameTime time) method of your processor, you can access data with two member dictionaries defined in EntityProcessor<T> : matchingEntities and enabledEntities, respectively to get all registered entities matching your key filter, and all currently enabled entities. (thus to update game logic, enabledEntities is recommended)

I hope I got it right, and if so, that I’ve been helpful :wink:

1 Like
#11

This is actaully amazingly helpful, thanks!

Though I admit I might go through and just implement the EntityProcssor<T1, T2...Tn> classes, I think I know how I’m going to do this now.

#12

I haven’t tested Xenko yet (waiting for Linux version), but I would like to ensure. Do I understand correctly that Xenko actually have real ECS implementation? With ‘System’ part in the place ;)? Like you can have components only with data and process them with systems (processors)? Just like it’s in real ECS libraries (let’s say Artemis)?
ps. sorry for reanimating this old thread.