Hot answers tagged entity-system
104
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 ...
46
Good question! Before I get to the specific questions you asked, I'll say: don't underestimate the power of simplicity. Tenpn is right. Keep in mind that all you're trying to do with these approaches is find an elegant way to defer a function call or decouple the caller from the callee. I can recommend coroutines as a surprisingly intuitive way to ...
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 ...
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 ...
13
Maybe you're thinking too much in entity systems.
Entities are meant to scope objects in game, like characters, enemies, scripts, bullets, triggers, etc.
Maybe if you make your UI separated, it will be way better and easier. You don't have to make EVERYTHING inside the entities scope.
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 ...
12
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 ...
11
A more serious answer:
I've seen blackboards used a lot. Simple versions are nothing more than struts that are updated with things like an entity's HP, which entities can then query.
Your blackboards can either be the world's view of this entity (ask B's blackboard what its HP is), or an entity's view of the world (A queries its blackboard to see what the ...
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 = ...
10
I learned about game entity systems through the book Game Engine Architecture by Jason Gregory. He discusses several implementations, ranging from class based to purely aggregate components, complete with examples. I highly recommend it, not just for that section, but for anybody who wants to know how to structure code for their game.
Edit: Just found this ...
10
Well, it's not really one extra call, is it? It's n * 100k extra calls per frame, if you're doing this every time you retrieve the sprite component for each entity!
Maybe your entity should just have a field for the sprite component, null if it hasn't got one, rather than indirecting through all this dictionary and typeof stuff. Ditto for other commonly ...
10
A system is only useful if it is useful. If a system were an entity is "simply a collection of components" is less useful than a system where an entity is mostly a "collection of components", then do that.
Stop trying to make "pure" systems and focus on making good ones that do what you need. Use components until components are no longer useful for you. ...
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
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 ...
9
First of all, using a thread per entity (talking about OS threads here, not language specific cheap co-routines) is insane. A thread is expensive, for example it needs a stack which by default uses 1MB of address space. Thread switching is expensive costing thousands of CPU cycles.
I wouldn't use multi threading at all in your main game logic. It adds a lot ...
9
What I have done is make the server do everything. The client(s) can merely ask the server to do something but can't do anything themselves. In this case, the server will always be the one assigning IDs and problem solved.
I have not dealt with client-side prediction while waiting for the server to approve actions like: "Shoot a rocket" or "Make a solar ...
9
No, multiple inheritance does not solve all the same problems that entity systems do: entity systems and multiple inheritance are two very different things. You can build an entity system with or without multiple inheritance and similarly you can utilize multiple inheritance without building an entity system.
Traditionally, component-focused entity systems ...
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
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
The real problem with your approach is class proliferation. See Mick West's seminal article on why CBEs (component-based entities) are better. Also see Wikipedia. A quick example for a game is as follows:
Given a space shooter where you can pick up combinations of different equipment and powerups, consider the following:
You pick up the Ooze Cannon ...
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
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
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
...
7
My opinion is that an entity should have its own Update method, but not its own Render method.
The entity contains most of the information necessary to update itself. It may require a bit of information about the context, such as the world, other entities nearby, etc., but most of the information is contained within the entity. Therefore it is the natural ...
6
I'd recommend taking a look at LÖVE "an awesome framework you can use to make 2D games in Lua. It's free, open-source, and works on Windows, Mac OS X and Linux." It's clearly not an alternative to the Cryengine, but should certainly demonstrate how to effectively utilize the potential of Lua for entity creation and game logic. Combine that knowledge with how ...
6
The "pure aggregation" approach described by West in that linked article eschews an "entity" object altogether. There are components, floating around in memory, but they are tied together only by implicit relationships, if at all.
One way to do this is a so-called outboard approach. In such a system, components are held by systems that manage or otherwise ...
6
First steps: write something and measure the performance.
If the performance is not good enough then use the measurements you made to drive your optimization.
Naively threading hundreds of entities is probably not the way to go. A scheduling queue might be, but only if you determined by your measurements above that the big OnAction() loop is tying you ...
Only top voted, non community-wiki answers of a minimum length are eligible
