Processor vs. System

[sschmid]

Since I'm already breaking the api here and there for the next release, why not adding yet another controversial proposal:

Rename Systems to Processor

ES “Systems” should be batch-processing algorithms: you give them an array/stream of homogeneous data, and they repeat one algorithm on each row/item. Calling them “Processors” instead of “Systems” reduces confusion.

Adam

[ghost]

Yeah, I tend to call parts of my program that e.g. handles UI, events etc as an event system etc not necessarily meaning an entitas system. I like the idea of renaming System to Processor.

[sschmid]

ECP FTW! 👯

ECS is so 2016 ;)

[JuDelCo]

I like this more than the Pool-Context at first sight, so, why not?

[sschmid]

from @JRSerjeant

Sounds good to me. A System systems components vs. a Processor processes components. The latter sounds much better and the former just sounds odd when you say it.

[WoLfulus]

Yeah, I had a "Processor" on my old ECS project too 😆

I like it 👍

[paraboxx]

To me processors are things that take one kind of data and transform it to get another kind of data. Event Processors take events and generate more events or make changes to game state entities.

Systems are things that work on stuff continuously. So an IReactiveSystem could make sense as IEventProcessor, especially if the events are deleted right after. But IInitializeSystem->IInitializeProcessor? Or IUpdateProcessor?

Also, does this mean the whole batch processing ideal wrt to cache friendliness is off the table then?

[paraboxx]

Or to state it differently: A processor processes a certain kind of thing. So it becomes a ThingProcessor. But systems in the more general sense can pull together information from various sources and act on them. Like a RenderSystem that might act on changes to Position, Health and AI State. Do we call it a RenderProcessor then? It doesn't process render, because render is not a component. Or should I call it a PositionHealthAIStateProcessor? The last one says what is being processed, but not what for. This is fine for input and event processors, but not for systems that don't have a singular input.

[IsaiahKelly]

An "entity processor" does sound more descriptive of the actual purpose than an "entity system". A system can also be quite complex, but calling it a processor should help reinforce the single responsibility idea behind it. I like this.

[IsaiahKelly]

Would it also be acceptable to name processors simply "process", e.g. RenderPositionProcess ?

[thygrrr]

Uhh, I name my Systems plainly anyway, e.g. "RenderViews", "LoadViewsFromPrefabs", etc.

I don't 100% like the Processor idea, mostly because it sounds weird for IExecuteSystems. But if push comes to shove, I'm quite indifferent. 👍

[IsaiahKelly]

Actually, IExecuteProcess or maybe even just IProcess sounds better to me than IExecuteSystem.

[IsaiahKelly]

This might be going a wee bit off topic, but I've been thinking about the naming convention of ECS in general for awhile now, especially within the context of Unity.

For example, Unity's definition of a "component" makes perfect sense to me (logic & data encapsulated in a discrete element, e.g a behavior). But in a modern ECS the term makes a lot less sense because a "component" in ECS is simply data and the term doesn't actual express that. It can also be a little confusing to someone used to Unity's definition.

So I thought why not just call components "data" instead? e.g. HealthData, PositionData, etc. This perfectly describes what these components actually hold, and this combined with the more popular "processor" over "system" also gives us a new term: EDP (Entity-Data-Processor). Which I think is actually an excellent term.

However, I guess you could also just adopt this "data" naming convention without even renaming the actual component element itself, but I do like the EDP term.

Please excuse all my thought diarrhea :p

[sschmid]

@IsaiahKelly I love to talk about details like this, you don't have to excuse your thoughts :) Finding good names is an art :) Recently, I was researching a way where any object can be used as components / data instead of being IComponent. I ended up calling those objects Health or Position, no suffix at all. You're right, in the end it's just data. Let's see where this is going.

[IsaiahKelly]

One of the unique features of EgoCS seems to be the way in which it combines both entity components and Unity components together. However, I'm too much of a newbie to know if their approach is good, since this might tightly couple entities to GameObjects?

I'm still trying to make my brain understand this whole ECS concept at the moment :)

[meyerzinn]

Honestly, I would definitely ask to keep entities and Unity entities separate for several reasons:

1. Entitas-CSharp should, like the name implies, be for C#, not Unity. A separate implementation could be Unity specific.
2. It would make life living hell for those of us working on alternate implementations of Entitas as an ECS in other languages.

Next, on the topic of naming:

I disagree that "components" as we know them are just data. When you consider what they represent, I think the word component properly explains what they are. Components describe characteristics of entities; for example, a Health component describes an entity that has health. It is not so much data as features of entities, so one could say Health is a component of an entity, meaning the entity is comprised of characteristics including Health.

To illustrate my point, suppose we have two entities, each with a set of components (forgive the Go syntax, it's my comfortable language and illustrates the point fine):

type HealthComponent struct {
    Health float32
}

type RegenerationComponent struct {
    Rate float32 // Represents the rate of regeneration (health per tick) this entity regains health at.
}

type Player struct {
    HealthComponent
    RegenerationComponent
}

type Bullet struct {
    HealthComponent
}

In this example, Health is characteristic of both Player and Bullet; that is to say, having health is a component that helps to make up the definition of both entities. However, RegenerationComponent is only characteristic of a Player entity; thus, a player can be differentiated from a bullet by virtue of the fact that the underlying components that make them up are different.

What you describe (using components as data) helps to differentiate between the same component in multiple entities. Maybe you want some players to regenerate health faster than others; you could set the rate differently on both. But both regenerate health.

[meyerzinn]

I actually do like the idea of renaming System to process. Per Google (our lord and savior), a definition of process is:

(verb) perform a series of mechanical or chemical operations on (something) in order to change or preserve it.

Further, the definition of a processor is:

(noun) a machine that processes something.

I think that fits perfectly with the entity-component-~system~processor paradigm, as they are meant to modify or preserve entity states routinely.

A system implies a bunch of parts making up a complex whole, so the union of all processors could be considered a system. @paraboxx in this implementation of an EC~S~P, systems don't continuously operate; they are restarted every time the overarching state is updated. Thus, these mutations aren't so much continuous as they are procedural.

[IsaiahKelly]

@20zinnm I agree that entity components and Unity components should have a clear distinction/separation from each other. However, I don't think @sschmid is trying to remove that. I think he's just trying to find better ways to integrate ECS into the Unity workflow and/or make their application more universal. The pure C# base is a key "component" ;) of Entitas, so I wouldn't worry about that going away.

I disagree that "components" as we know them are just data. When you consider what they represent

Components describe characteristics

It is not so much data as features of entities

I think you're confusing the literal definition with the abstract. "components", "characteristics", "features" no matter what you call it, it's still all just data! However, just calling it "data" might be a bit too literal. You, however, seem to favor the term "characteristic". So why not just call them that instead? Too many letters? :p

This is probably just personal taste, but the term "component" has never sounded right to me. I think it suggest a more complex and independent system. However, I have yet to find a term I really think should replace it. "data" seems like the easiest, but I've also thought about other terms and you've actually just added to the list.

List of alternatives to "component":

• data
• trait
• facet
• element
• feature
• attribute
• characteristic
• property

Some of these terms obviously conflict with preexisting C# terms, however, I actually think "trait" might be my favorite right now and it's very similar to feature or characteristic, but much much shorter!

[meyerzinn]

@IsaiahKelly I like the idea of trait, and in fact I think there is precedent for that, but I would like to reiterate that an entity is comprised of multiple components (or "traits") which describe the entity in different ways. Merely having a component/trait indicates that it is characteristic of the entity; the data contained within further elaborates upon the trait (for example, its rate or magnitude). It is not just data, because its presence is symbolic of the components that make up the entity. I think it is more appropriate that they be named traits.

[IsaiahKelly]

@20zinnm I actually completely agree with you on what a component is and represents. I think this is all just a misunderstanding over my issue with the term "component" itself. The fact that the term is symbolic or abstract doesn't change the fact that it's still just data. So I disagree with the idea that a component is "not just data" because the symbolism here is still just data, but like I've already said "data" is probably too literal or generic a term to be used instead.

I'm really just arguing semantics. I personally dislike the term "component" when used here in the Entitas context, but there is nothing technically wrong with it. I just feel like there might be a better symbolic term that would more accurately represent the fact that an entitas component holds pure data. However, I might only feel this way because Unity's use of the term "component" has distorted my understanding of what a component should or can be.

In any case at least we both like the term "trait" :) One other term I've thought of is "token" which can mean "A specific instance of a phenomenon or a class of things", but I'm still favoring "trait".

[ghost]

"token" would just end up confusing the hell out of me since I use Antlr in some projects with Entitas. :p

[meyerzinn]

I think trait works especially well in this context, as we are talking about entities :)

[IsaiahKelly]

Yeah, an entity "token" probably makes a lot less sense than an entity "trait" or most of the other terms suggestions anyway.

[sschmid]

Thanks guys for the conversation and for your input. I really like 'Processor' etc, and I think, if I would start from scratch, I would consider calling systems like this. I think I will suspend this issue for a while, since I'm currently working on other features. Also, with the latest release I think I already used up your energy with renamings and breaking changes ;) I'd like to go easy on you for the next few weeks ;) But I might re-open this issue in the future. For now, I'll keep it classic, ECS, Entity, Component, System.