Tag Info

Hot answers tagged

210

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 ...


66

// in entity_a's code: entity_b->takeDamage(); You asked how comercial games do it. ;)


58

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 ...


38

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 ...


31

A comment: The Artemis implementation is interesting. I came up with a similar solution, except I called my components "Attributes" and "Behaviors". This approach of separating types of components has worked very nicely for me. Regarding the solution: The code is easy to use, but the implementation might be hard to follow if you're not experienced with C++. ...


20

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 ...


19

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 ...


18

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 ...


18

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 ...


17

The two key benefits that I constantly hear lauded about entity systems are 1) the easy construction of new kinds of entities due to not having to tangle with complex inheritance hierarchies, and 2) cache efficiency. Note that (1) is a benefit of component-based design, not just ES/ECS. You can use components in many ways that do not have the "systems" ...


16

A system is only useful if it is useful. If a system where 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. ...


14

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 ...


13

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 ...


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.


13

Remember to not get carried away with entities and components. It's totally fine to not have your World as a component. If you know for sure there's only going to be one of something, it doesn't make much sense to make it a component. Components are made to be reused in numerous entities, combined with other components. This doesn't make the game less pure, ...


12

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 ); ...


12

Nicol Bolas' answer is straight on, but stepping aside and looking at your problem from a distance: you really don't need the type of the entity. You only need to care whether "does the object have component X" or not and your problem is that you have not properly identified X. If two objects behave differently then give them different components or just ...


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

The major advantage that comes to my mind is that it allows the configuration to be edited/managed by a non-programmer without requiring them to touch any of the game scripts.


11

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 ...


11

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 ...


11

If you are going to be storing the Components in a collection all together then you must use a common base class as the type stored in the collection, and thus you must cast to the correct type when you try to access the Components in the collection. The problems of trying to cast to the wrong derived class can be eliminated by clever use of templates and ...


11

Mick West's article explains the process of linearising entity component data, in full. It worked for the Tony Hawk series, years ago, on much less impressive hardware than we have today, to greatly improve performance. He basically used global, pre-allocated arrays for each distinct type of entity data (position, score and whatnot) and references each array ...


9

Please check out the links that I put in the bottom of this answer. A good number of them thoroughly answer this question, and I'd rather not duplicate the information here. In particular, there is a question, "Component based game engine design" which I think directly answers your question.


9

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 ...


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

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.


9

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 ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible