Skip to content

Instantly share code, notes, and snippets.

@SanderMertens
Created June 12, 2020 17:46
Show Gist options
  • Save SanderMertens/bfc957e911daf8aa9774933c15268441 to your computer and use it in GitHub Desktop.
Save SanderMertens/bfc957e911daf8aa9774933c15268441 to your computer and use it in GitHub Desktop.

Here are some generic design guidelines (emphasis on guidelines, not rules):

  • When building a new feature, start with the components and spend time thinking about how the components will be used (how often are they written/read, who owns them, how many instances etc)

  • Design components so that they have a single purpose. It is much easier (and cheap) to combine two components in a query than it is to split up components, which causes a lot of refactoring.

  • Don't over-generalize. If your code has lots of branches it is possible that you're trying to do too much with a single component. Consider splitting up components. It's ok to have multiple components with the same fields, if this makes your business logic simpler (and faster).

  • Think twice before adding collections to components. Collections are OK if the contents of the collection are meant to be interpreted as an atomic unit, but if the individual elements must be interpreted in a standalone way, consider creating separate entities instead.

  • Avoid dependencies / direct interaction between systems. Components are the only things that should be used for inter-system communication.

  • Don't store function pointers in components. If you need to provide different (mutually exclusive) implementations for a component, use systems & tags.

  • Don't feel like you should store everything in ECS. ECS is great for iterating large sets of entities linearly, but things more specialized than that (like spatial data structures) are better implemented separately. You can always cross-reference entity handles from your specialized data structure.

Something thing that trips people up when starting with ECS is that it's hard to know what the overhead of certain operations is. This may help a bit, though note that this varies per ECS framework:

  • Iteration over large sets of similar entities is super fast

  • Random access (entity.get) is comparatively slow

  • Entity creation / destruction is cheap when compared with OOP

  • Adding/removing components is comparable to creation/deletion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment