49

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


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


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


20

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


15

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

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


13

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


13

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


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

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

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

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

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

Short answer: Entity Component System (ECS) is not a part of OOP. The discussion that most influenced my understanding of Entity Component Systems is on T-Machine and an example framework inspired by this discussion useful for reference is Artemis. One of the fundamental concepts of OOP is encapsulation - application design breaks the domain into objects ...


10

Any way that works is a way that works. That sounds snide, but really, your game is 1000x more important than your architecture. Pick any approach you like and find easy to use. The ones I've seen in real shipping games (using component-based design, not ECS specifically; I've never seen pure ECS "in the wild", though many component designs have ECS-like ...


10

The simple version: don't. One could argue that you have perhaps a slight misunderstandings about how to build an ECS (why would you sent a list of Entity* to a system to update? the System is supposed to have its own self-contained collection of the components it cares about, and the global entity list should barely ever even be used... a "true" ECS doesn'...


10

Can Component hold the logic? or it should not and stay as a bag of data? That's how you like. I suggest to stick with the first implementation and finish your project, then see if it worked out for you or not. If you do that, however, I suggest you drop the concept of System as you described it, as you'll have two lanes of doing things, which will, in ...


9

Most entity systems don't use Data Oriented Design. Note that entity system doesn't necessarily imply DOD, it just means splitting gameplay functionality into different component classes giving entities certain features and behavior. You can (very easily) create a bloated and horribly slow Object-Oriented version of an entity system. So entity systems are ...


9

In ECS everything is broken down to components that describe functions. A weapon is a physical item so one component will be a physical position. If it is on the ground or thrown at an enemy (sword / throwing knife) then you need the physical position component to decide if it was picked up or hit something (e.g. wall or monster). When a weapon is held you ...


9

First, you should not have a strict 1-1 mapping of Components to Systems. It's unclear to me from your question if that's the case already. You may very well have singular systems that use or interact with numerous components. Rendering, physics, AI, etc. are all Systems (they perform a cohesive set of updates and logic) but interact with many Components. A ...


9

Is there some advantage to having each attribute laid out contiguously in memory? It's better for cache locality of data access. Memory access is slowest part of all modern computing systems. As memory buses pull in multiple bytes in "cachelines" and most modern CPUs will prefetch memory that it detects are being accessed contiguously, keeping data that is ...


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