334

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


43

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


36

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


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


26

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


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


18

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

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


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

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

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

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

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


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

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

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


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