342
There are a multitude of ways to represent and implement entity component systems, but here is an explanation of one way. Keep in mind there is no concrete definition of entity/component/system architectures, so this is just one implementation.
I'm going to introduce an analogy for entity/component/system architectures that might help. Let's think of an ...
43
If I were in this situation, I would create each part of the boss as a separate entity. These "sub-entities" would include some kind of AttachmentPoint or ParentEntity component. This component would include a reference to the parent entity and an offset from the parents position. When updating the position, they check the parent position and apply the ...
26
Camera: Making this a component would be pretty neat. It would just have a isRendering flag and depth range like Sean said. In addition to "field of view" (I guess you might call it scale in 2D?) and an output zone. The output zone could define the portion of the game window that this camera gets rendered to. It wouldn't have a separate position/rotation ...
25
I think it's totally fine to have simple methods for accessing, updating or manipulating the data in components. I think the functionality that should stay out of components is logical functionality. Utility functions are just fine. Remember, the entity-component system is just a guideline, not strict rules you need to follow. Don't go out of your way to ...
15
What is often used is an intermediate Intent System which abstracts the input and keeps track of the context and relevant gamestates.
The Intent system will stop transmitting inputs when the simulation is paused for example.
It also handles the mapping between controller events and intents (move in direction, run, shoot, reload...).
This way your other ...
15
I would suggest starting by reading Mike Acton's 3 big lies, because you violate two of them. I'm serious, this will change the way you design your code: http://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html
So which do you violate?
Lie #3 - Code is more important than data
You talk about dependency injection, which may be useful in ...
13
Here's how I approached this:
Camera
My camera is an entity like any other, which has attached components:
Transform has Translation, Rotation and Scale properties, in addition to others for velocity, etc.
Pov (Point of view) has FieldOfView, AspectRatio, Near, Far, and anything else required to produce a projection matrix, in addition to a IsOrtho flag ...
13
How can I use multiple meshes per entity without breaking one component of a single type per entity?
Your Position component could have a "parent/children" logic, where any Entity with a Position may have a parent and their position is relative to their parent. Instead of having several meshs on the same entity, you can make more than one entity, each with its own mesh and link them together. You can even make the children entities listen to their parent ...
12
You've probably heard of the God/Blob object anti-pattern. Well your problem is a God/Blob loop. Tinkering with your message passing system will at best provide a Band-Aid solution and at worst be a complete waste of time. In fact, your problem has nothing specifically to do with game development at all. I've caught myself trying to modify a collection while ...
12
You are over-complicating things. I would go so far as to say that even using component-based design is just overkill for such a simple game. Do things the way that makes your game quick and easy to develop. Components help with iteration in larger projects with a huge variety of behaviors and game object configurations but their benefit to such a simple ...
11
Not everything has a dynamic set of properties. In fact, much of software engineering is about trying to pin down a precise and static specification of something.
Static hierarchies are easier to reason about because they're broadly fixed in the code. Components can lead to an explosion of possible permutations - great if you need that flexibility, but ...
11
Only the Unity developers can give their true motivation for this design, but one argument in support of doing it this way is that there is an argument that each class in a software project should handle one and only one responsibility. The GameObject is a named collection of Components, and adding position/rotation/etc to that means it would have 2 ...
11
The sole constraint of an identifier in an entity component system is that the generated identifier be unique. That's the only criteria. If it's unique, it's good.
Any method which satisfies this one constraint is a proper way to assign IDs.
guid? Fine.
integer from an incrementing counter? Provided the
counter isn't going to overflow during play, ...
11
Yes, you're thinking too complicated.
It sounds like a lot of your problems could be solved with a messaging system and some additional attributes that allow you to specify some filters, and finally not worrying about being so strict with entities/components.
Messaging will help you with some aspects like triggering particles, powerups, and so on. For ...
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
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 ...
10
'That' article is not one I particularly agree with, so my answer will be somewhat critical I think.
This seems really practical in many situations, but the part about components being just data classes is bothering me. For example, how could I implement my Vector2D class (Position) in an Entity System?
The idea isn't to ensure that nothing in your ...
10
That is usually done using messages. You can find lots of details in other questions on this site, like here or there.
To answer your specific example, a way to go is to define a small Message class that your objects can process, e.g:
struct Message
{
Message(const Objt& sender, const std::string& msg)
: m_sender(&sender)
, ...
10
Regarding a more strict implementation of entity/component based
engine, is my solution viable?
Will it work? Sure, you can make it work. But I wouldn't recommend it.
Do I risk to get stuck at any point due to the lack of flexibility of
this implementation (or anything else)?
You're straying pretty far away from the entity/component concept. Without ...
10
Short answer: Entity Component System (ECS) is not a part of OOP.
The discussion that most influenced my understanding of Entity Component Systems is on T-Machine and an example framework inspired by this discussion useful for reference is Artemis.
One of the fundamental concepts of OOP is encapsulation - application design breaks the domain into objects ...
10
Any way that works is a way that works. That sounds snide, but really, your game is 1000x more important than your architecture. Pick any approach you like and find easy to use.
The ones I've seen in real shipping games (using component-based design, not ECS specifically; I've never seen pure ECS "in the wild", though many component designs have ECS-like ...
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
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 ...
9
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'...
8
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 ...
8
I implemented an entity component framework (similar to Artemis) after I'd already been in development for a while, but I don't think I would have done things differently if starting from a blank slate.
I have my world totally separate from the entity framework. It just didn't make sense to me to convert the world into some sort of entity or collection of ...
8
Consider this example:
You're making an RTS. In a fit of complete logic, you decide to make a base class GameObject, and then two subclasses, Building and Unit. This works just fine, of course, and you end up with something that looks like this:
GameObject
ModelComponent
CollisionComponent
…
Building
ProductionComponent
…
Unit
AimingAIComponent
...
Only top voted, non community-wiki answers of a minimum length are eligible
