Hello everyone.

I'm currently working on some game engine and have been scratching my head quite a while on how to handle multiple entity types.

To be on the same page, an entity is to me an element in the scene/level, for instance:
- Hero / Player
- Various sort of enemies and their respective behavior
- Inanimate elements
- Animated elements
- Terrain
...

I spent some time looking at the literature and modern trends. It seems that a lot of game engines are still with the OOP mindset, but are transitioning from classic inheritance to things such as component based entities.

Casey previously wrote some articles about a new editor feature for The Witness and disclosed some code for the occasion:
-> http://mollyrocket.com/casey/lister_panel.cpp

In this code, one could guess how entity are coded. There's apparently a generic entity class and other subclasses (Grass, door, etc.) for which Casey just do a simple cast in order to access specific class members. But I might be completely wrong on this (some predefined void* data pointer at the end of the original entity class that gets molded into another specific entity class when casting?).

To the question: How would you handle multiple entity types?
Considering that:
- distinct entity types could be represented as different data structure (the grass entity would have a number of instance for example), though some common base would be present (uid, position, etc.)
- distinct entity types could be handled by different code logics (i.e. the rendering for grass would use instance-based rendering).
- all of this without falling into the OOP trap and keeping a performant data-oriented code.

I'm sure there's no perfect answer, but I wanted to collect some thoughts on the matter and improve my current code base keeping in mind & following what Casey has been teaching us so far :)

I have been in that position where I try look for information on what is the best way to do something. So I address that first. Trying to search for best way is usually huge warning sign that you don’t know what you want or you don’t know requirements of your game. For me this is the “come up with use case first” aspect of handmade hero. I also think that almost everything is a metaphor. What I mean is that how people think about entities, their composition, or how to process them will affect how you structure your code and what terminology you use. But maybe there is some benefit of being aware of different approaches.

I think how you handle your entities depends on scope of your game. For example, if your game would be similar to Invader, then I would just start with struct per per entity and keep instances in array. Anything more complex, like components, would just slow you down and obscure the code.

Usually natural extension from struct per entity is like that OOP way where you would create some base struct shared by entities. And I think that is totally ok if your game is not huge. And if game is big, then components can be ok. Again totally depends on your game.

I am very data oriented and think lot about data. Last time I played around with more complex system my entities were nothing more than just id number. Components were data that were stored in arrays. You could access those components with entity id, if needed. And I could process component data in linear fashion. I feel that this makes multithreading also easier because it’s easier to reason about update order.

I don’t like books, but I think best book on this subject is Game Engine Architecture. It gives more general overview of things and doesn’t try to create illusion that there would be one best way to do something.

Hey thanks for taking the time to answer!

I have been in that position where I try look for information on what is the best way to do something. So I address that first. Trying to search for best way is usually huge warning sign that you don’t know what you want or you don’t know requirements of your game. For me this is the “come up with use case first” aspect of handmade hero

That's a good point. I have a general idea of what I want and need but for I must admit that for now, my entity types are more seen as "concepts" (as mentioned above). These concepts are different enough that a simple struct isn't sufficient, hence starting to think of a good design to approach the representation.

Usually natural extension from struct per entity is like that OOP way where you would create some base struct shared by entities. And I think that is totally ok if your game is not huge. And if game is big, then components can be ok. Again totally depends on your game.

I'm currently working with the former solution (base entity class and per-entity-type derived classes with no multi-inheritance bs).

Components were indeed quite sexy for a good tradeoff between modularity/flexibility and data oriented designs. I'm still having trouble envisioning how to divide my current entity types implementation in components (I felt like the design would get me back to some inheritance/polymorphism solution within the component system).

I don’t like books, but I think best book on this subject is Game Engine Architecture. It gives more general overview of things and doesn’t try to create illusion that there would be one best way to do something.

Ah yeah I actually own that one. It's a great book but unfortunately not really balanced in content. Some chapters cover a topic quite in depth whereas some don't and just vaguely list techniques or notions without digging too much. Still an enjoyable read for insight on how to apprehend/write a "modern" game engine.