Do you have a source for this, because I really think this list gets at the heart of the "engine" issue here.
People quoting that post, sound like someone opening a radio for the very first time as beginning electrical engineers and being like "well here's all the problems, it's all these WIRES in here fucking things up!"
That list is just a list of very rote features and system patterns that virtually every game uses. Like their complaints about the entity component system are precisely the point of ECS. ECS
is modular programming, that's literally the strength of ECS. The entire point of an ECS is that entities are literally container pawns that don't contain any actual "programming," but instead are merely individual instances of larger systems that tick each entity separately. The name itself even explains how it works -- an ENTITY COMPONENT system.
Like, let's take a second and design an entity component system entity class for a second, literally see how it's done:
Code:
class Entity_Interface
{
int EntityID;
public:
Entity_Interface();
virtual ~Entity_Interface();
virtual const int GetEntityTypeID() const = 0;
inline const int GetEntityID() const { return this->EntityID; }
};
template<class T>
class Entity : public Entity_Interface
{
void operator delete(void*) = delete;
void operator delete[](void*) = delete;
public:
static const int STATIC_ENTITY_TYPE_ID;
Entity() {}
virtual ~Entity() {}
virtual const int GetStaticEntityTypeID() const override { return STATIC_ENTITY_TYPE_ID; }
};
Like, that's seriously all there is to an entity. An entity, in an ECS system, is literally just a container wrapper. It's a super abstract concept, that merely registers that an instance (or entity) of a more complex system, determined by a mere identification type, has been created. Entities, in an ECS, are merely tiny allocations in a memory pool, that get parsed by a larger system that iterates through the pool. Entities literally shouldn't contain "programming," that's what their
SYSTEM is for.
Or the bit about meta data -- the author sounds like he wants to definitively claim an observer pattern is inherently superior to polling, except one cannot make this claim in isolation without being able to examine the underlaying architecture of the engine, what polling vs observing means in practical terms. There are, believe it or not, actual reasons one would choose to use a polling pattern over the observer pattern, depending on the behavior needed. Their complaints about cells is literally just vector quantization, one of the most classical compression schemes around. Of course they have limits, everything in computer programming has limits. Actually, switching to a model "without limits" is way, way more janky.
Read this book:
http://gameprogrammingpatterns.com/
All the shocking "issues" in that post are literally just the general nuts and bolts of game design.
