335

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

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


44

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


42

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


34

I know you do not conceptualize this as collisions, however what you are doing is colliding a circle centered at the creature, with all food. You really do not want to check food that you know is distant, only what is nearby. That is the general advice for collision optimization. I would like to encourage to search for techniques to optimize collisions, and ...


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


23

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


21

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


19

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


17

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.


17

Chewy has it right, but if you're using C++11 you have some new types you can use. Instead of using const std::type_info* as the key in your map, you could use std::type_index (see cppreference.com), which is a wrapper around the std::type_info. Why would you use it? The std::type_index actually stores the relationship with the std::type_info as a pointer, ...


16

You should adopt a space partitioning algorithm like BVH to reduce complexity. To be specific to your case, you need to make a tree that consists of axis-aligned bounding boxes that contain food pieces. To create a hierarchy, put food pieces close to each other in AABBs, then put those AABBs in bigger AABBs, again, by distance between them. Do this until ...


14

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


14

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


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

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


12

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


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

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


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


12

Fork-Join You don't need separate copies of components. Just use a fork-join model, which is (extremely poorly) mentioned in that article from Intel. In an ECS, you effectively have a loop something like: while in game: for each system: for each component in system: update component Change this to something like: while in game: for each ...


11

How to properly implement message handling in a component based entity system? I would say that you want two types of messages: Synchronous and Asynchonous. Synchronous messages are handled immediately while asynchronous are handled not in the same stack frame (but may be handled in the same game frame). The decision which is which is usually made on a "per ...


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

This seems great, considering fast access for a component using entity id and more importantly, fast iteration over elements of array (because systems do this all the time) and fewer cache misses than if I store components in Entity or use: Have you actually measured cache misses? Are they in any way being a problem for you? Would eliminating them for your ...


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

Your IDs should be a mixture of index and version. This will allow you to reuse IDs efficiently, use the ID to quickly find components, and makes your "option 2" much easier to implement (though option 3 can be made much more palatable with some work). struct entity { uint16 version; /* and other crap that doesn't belong in components */ }; std::...


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