13
Short version: no, your job as an engineer is to evaluate all applicable solutions to problems before choosing a solution
Long Version:
"ECS" is an overloaded term. It had a somewhat clear definition at first but it's been overly muddled since. It doesn't matter much, though, since the answer is the same either way: every architecture has pros and cons. If ...
11
Applying the RequireComponent decoration to a script will ensure that the GameObject has the specified component.
If the component is missing:
Unity will attempt to add a component of this type for you,
If this fails (e.g. mixing RigidBody/RigidBody2D) then the script will refuse to attach.
C# sample:
[RequireComponent (typeof (Rigidbody))]
public class ...
11
The simple version: don't.
One could argue that you have perhaps a slight misunderstandings about how to build an ECS (why would you sent a list of Entity* to a system to update? the System is supposed to have its own self-contained collection of the components it cares about, and the global entity list should barely ever even be used... a "true" ECS doesn'...
10
In C#, having an instance (non-static) method in a class does not copy the instructions for each object created from that class. Static or not, the data that represents the instructions only exist in one place.
The member variables, or state, of each of the instantiated objects do get their own space in memory. When you write a non-static method on a ...
10
What's an object?
What we call an object or an entity depending on the model is, fundamentally, made of two parts: data, and behaviour. Game objects have properties and do things.
Let's take a simple, free-falling ball as an example. A ball's data is:
Its current position
Its current speed
Our ball can do a single thing: fall. When a ball falls, it does ...
9
In ECS everything is broken down to components that describe functions.
A weapon is a physical item so one component will be a physical position. If it is on the ground or thrown at an enemy (sword / throwing knife) then you need the physical position component to decide if it was picked up or hit something (e.g. wall or monster). When a weapon is held you ...
9
Im late to the party here but I spent A-LOT of time researching this.
First why I don't use the following:
XML: Excessively verbose. Tons of redundancy. Repeating field names? GROSS
JSON: I think JSON is great for a UI layout but for a database, hell no. It will have the same problems as XML, redundancy, and deep nesting. GROSS.
SQL: This is a great ...
9
First, you should not have a strict 1-1 mapping of Components to Systems. It's unclear to me from your question if that's the case already. You may very well have singular systems that use or interact with numerous components. Rendering, physics, AI, etc. are all Systems (they perform a cohesive set of updates and logic) but interact with many Components.
A ...
8
To add to the other answers here, you can use something like in the following code to have a bit set of arbitrary length that grows on demand. This method even lets you do a simple form of compression; if your most common components have the lowest ID values, the majority of your entities will use a small amount of bitset memory to track their components, ...
8
Components are just a collection of data and logic. How you store and relate them to the logical entity is where you gain or lose performance depending on the strategy you choose.
My example and explanation is in Java, but the theory can be applied to any language.
The way I usually handle custom Component engines is with HashMap registries of components. ...
7
Games typically approach this type of issue using a transformation hierarchy.
In this model, each entity can be treated as a "child" of a "parent" entity. The entity's local position and orientation components are interpreted to be relative to the position and orientation of the parent.
Parent entities may in turn have their own parents, ...
6
Partly to allow data-driven operations, and partly because an ECS is a specific subset of all possible component-based designs.
A main point of component-based approach to aggregation (be it ECS or another use of components) is to allow you to reconfigure game objects without needing a recompile. You have an editor that your designers and game scripters ...
6
Taking the example of the guitar:
(...) a player you can, for example, not only play on guitar as a Musical Instrument, but use it as a Weapon or, what is perhaps more unobvious, throw it right to the furnace to get some heat in a cold winter night.
First off, move away from using object inheritance to model this. Although, I want to note that using OOP is ...
5
After using several entity-component systems, especially CraftyJS, I more or less got the answer to my question: yes, you can reuse components (especially sprites or images and mouse-click handlers in 2D games) for the GUI.
Much of the time, you only have access to the ECS, and not the underlying systems (eg. drawing system). In this case, it's okay to use ...
5
It's OK to have component dependencies. And the more explicit the dependency the better. There's nothing worse than dependencies hidden behind useless layers of indirections.
Your case doesn't look like a dependency hell to me. No circular dependency or unclear ownership of data: consider yourself lucky!
Now I still believe that you need to reverse your ...
5
You could use a Dictionary. Store all Transforms as a key with reference to each Car.
In this example, we have a god Game class that holds references to all Cars. (just make sure your Script Execution Order has Game execute before Car does)
Each Car class adds itself to the Game's Car Dictionary upon Awake.
Then in your Raycast, you get the Car directly ...
5
Do the simplest thing that works, especially early on.
If you've ever seen videos of triple-A titles in alpha, you'll know how slow / buggy they are. This is normal; in fact, it's desirable. And it's often because they used the naive solution to problems.
Agile development philosophy states Refactor Mercilessly; I couldn't agree more, from experience. ...
5
I personally would go with the event sending, because it's more explicit and easier to follow in code. Something like:
public delegate void DirectionChangedHandler(float direction);
public class Direction {
[SerializeField]
private float angle = 0.0f;
public event DirectionChangedHandler DirectionChanged;
public float Angle
{
...
5
I was considering voting to close this question as opinion-based, but I think there are a couple of misunderstandings about Entity-Component Systems and Data-Oriented Design here that are worth addressing.
ECS is just a tool
Like any programming pattern or principle, it exists to help you write good software. It is not an unbreakable law of physics or a ...
5
A lot of systems in a game that needs to be updated are things that are not rendered and don't need any input, they simply need a call to their update function every frame. They don't have any physical representation in the game world...
That sounds like an entity that has no Renderer component (doesn't get rendered) and no InputHandler component (doesn't ...
4
Raw pointers: Fast but violates the idea of RAII. How to check if a
component is deallocated? It feels like a scary unsafe path
Raw pointers are a perfectly valid choice. All that using a smart pointer would do is move all of the ownership and dependency logic out of the component code into member variables, convoluting your ownership structure ...
4
Processing data in arrays is not component based or data driven design. Component based design is about aggregation and dynamic composition.
Much of the hype about component performance in the indie community is extremely ill-advised. I've seen great complex 3D games written from scratch in C++ with a fairly naive memory allocator and component ...
4
I'll try to explain with an example:
Let's say we have an RPG where you can enchant your weapons with elemental damage. The weapon still have a "physical" attack power, which is reduced by the enemies "phyical armor". But now we have elemental damage, and thus the enemies might have elemental resistances.
This is perfect for Entity Component System, ...
4
I would recommend having both.
Entity/Component Graph
This defines which entities are attached to which components. In my engine, there is no such thing as an "entity", but any component can have child components. This graph is not used to draw or update components, but is only used for logical queries and events that are supposed to effect component sub-...
4
Being 'cache friendly' is a preoccupation big games have. This seems to be premature optimization to me.
One way to solve this without being 'cache friendly' would be to create your object on the heap instead of on the stack: use new and (smart)pointers for your objects. This way, you'll be able to reference your objects and their reference will not be ...
4
Your component entity system doesn't match that which was shown in the article. The article doesn't attach logic components to entities, it uses system objects which look for data components.
Additionally IDs are typically enumerations or bit keys instead of strings. You'd have a system component that would do something like:
function update(entities):
...
3
Maybe you could use a C-style bitfield and just add new fields as needed.
struct ComponentIds {
bool person : 1;
bool renderable : 1;
bool movable : 1;
bool ai : 1;
// and so on...
};
class GameObject {
public:
ComponentIds componentsUsed;
};
Since you only need boolean flags, a bitfield struct would be a lot ...
3
Ideally, your Object should have no explicit reference to its components: IUpdater, IDrawable, etc. It should rather maintain a list of pointers to a base class, ideally serialized from data:
class Object {
public:
Object(const char* fromFile); // serializes _componentList
private:
std::list< IComponent* > _componentList;
};
The rational is ...
Only top voted, non community-wiki answers of a minimum length are eligible