Hot answers tagged component-based
102
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 ...
34
Components are great, but it can take some time to find a solution that feels good to you. Don't worry, you'll get there. :)
Organizing components
You're pretty much on the right track, I'd say. I'll try to describe the solution in reverse, starting with the door and ending with the switches. My implementation makes heavy use of events; below I describe ...
24
First of all, you when build component-based systems, you don't have to take the approach of turning everything into a component. In fact, you generally shouldn't -- it's something of a neophyte mistake. In my experience the best way to tie together rendering and physics systems in a component based architecture is to make those components little more than ...
21
If there are no popular ones, then why not?
Because there is nothing resembling a consensus on how such a framework would operate.
On a thread on Gamedev.net I determined that when people talk about component-based game systems there are actually at least 8 possible permutations of how they expect them to work, based on 3 different factors:
Inboard ...
16
One of the primary benefits of a component system is the ability to take advantage of caching patterns - good icache and prediction because you run the same code over and over, good dcache because you can allocate the objects in homogeneous pools and because the vtables, if any, stay hot.
The way you have structured your components, this advantage ...
14
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 ...
12
It might not come up so much for a small personal game, but one hard problem when it comes to game data is multi-user editing/versioning. We use a lot of small text files that get baked down to a small number of binary blobs by a build process. This makes life easier for designers since they have a lot of flexibility in their workflow. CCP, as a counter ...
12
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 ...
11
We have a similar situtation in our project, and we solved the problem by saving components (not functions) to LUA metatables. Basically, when we are creating an entity (or game object as we call them) on LUA side, code looks something like:
function createShip()
...
self.transform = registerToComponent("transform")
self.sprite = ...
11
If you're talking about a moddable game, then you might want to follow one of your suggestions above. But if you are concerned about rolling over your own errors, I'd say don't do it. I have become an advocate of Fail-Fast. If this is an error that you have created and must resolve before releasing, you should make the error obvious. The article that is ...
11
You already accepted an answer, but here's my stab at a CBS. I found that a generic Component class has some limitations, so I went with a design described by Radical Entertainment at GDC 2009, who suggested separating components into Attributes and Behaviors. ("Theory and Practice of the Game Object Component Architecture", Marcin Chady)
I explain my ...
11
Materials are a graphics concept, and belong in your renderer. A renderer is too low-level a piece of architecture to be built on top of an entity system. Entity systems should be for higher-level game objects. Not everything needs to be a component, and in fact, it's generally a bad idea to try to force everything into a single paradigm like that. It ...
10
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 ...
9
No lie, architecting games (or any other simulation-style program) is harder than your average business app. When you have lots of different entities that all need to interact then in the code they'll need to, well, interact. Letting them do that in a maintainable way is tricky.
A component pattern can help, but even then figuring out how to wire the ...
9
One of the things that Unity does is provide some helper accessors on the parent game object to provide a more user friendly access to common components.
For example, you might have your position stored in a Transform component. Using your example you would have to write something like
e.GetComponent<Transform>().position = new Vector3( whatever );
...
9
If you think a 2D RPG is so complicated that you not only need a database, but also a ORM to simplify the interfacing to that database, then I'd suggest you probably haven't yet studied the game mechanics yet. Do bear in mind that we had Zelda in the cartridge era where you might have had 256 bytes of battery-backed RAM to save the current state of the game ...
9
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 ...
9
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)
, ...
8
I was under the impression that in a components based design the entities are essentially components containers (with possibly some message thrown in). Viewed from this perspective the each components would store a little of the state. For instance if the ghost-behavior-components decides it needs to enter the intangible mode it also sends a message to the ...
8
There's a line between complete granularity, leading to no code wastage or blob-like state (which is why component architectures are favoured), and usability.
Obviously things may have a Position, but they're not necessarily dynamic (so why have Velocity and Acceleration?). However, something with a Velocity is going to be a moving object, so it makes sense ...
8
It seems like what you want is a factory.
http://en.wikipedia.org/wiki/Factory_method_pattern
What you can do is have your various components register with the factory what name they correspond to, and then you have some map of string identifier to constructor method signature to generate your components.
8
It seems like a very reasonable first step.
You're opting for a combination of generality (the "additional components" map) and lookup performance (the hard-coded members), which may be a bit of a pre-optimization -- your point concerning the general inefficiency of string-based look-up is well-made, but you can alleviate that by choosing to index ...
8
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 ...
8
'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 ...
7
Personally I don't think there are any good examples, largely because the definition of a "component-based system" for games is so loosely defined that it can mean next to nothing.
You might find some of the discussion in this answer helpful: How to implement a component based system for items in a web game.
On the whole though, the approach is simply to ...
7
You're on the right track. Getting a reference to a GameComponent from other GameComponents relies on GameServices.
Revised code would look something like:
var inputComponent = new InputComponent(this);
this.Components.Add(inputComponent);
this.Services.Add(typeof(IInputComponent), inputComponent);
Getting the component back out from another component ...
7
Should the shield be its own entity
that tracks the location of the
player? That might make it hard to
implement the damage filtering. It
also kinda blurs the lines between
attached components and entities.
Edit: I think there's not enough "autonomous behaviour" for a separated entity. In this specific case, a shield follows the target, works ...
7
The distinction between user and developer is not always clear in game development. Standard programming techniques like "fail fast" are not always advantageous, especially as team sizes grow.
For example, perhaps your technical artist has screwed up the shader for the targeting outline - broke the fallback, let's say, so it's only loading on SM4 systems, ...
7
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 ...
7
It looks mighty fine to me. I'm using a similar approach in my engine.
My definition of an Entity is that it is an object that can interact in some way with other objects. Right now I have the generic GameObject class, with three children: Player, Enemy and Bullet. It also has handles to five different modules:
ModuleSprite - renders the entity
...
Only top voted, non community-wiki answers of a minimum length are eligible
