|
|
|
|
|
|
by Hodgman
2796 days ago
|
|
|
The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up.
You need to work on your speed reading skills before throwing shade... |
|
|
Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man.
So I'll quote you: "You need to work on your speed reading skills before throwing shade..."
> The fact the flexibility is being removed is discussed too
You state: "Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature."
Which is failing to recognize that the whole point of the original code - written by a game engine developer - is to demonstrate exactly how to do this for performance and flexibility for any small team.
> along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up.
With out it being there, I cannot judge it. But considering that you removed features and barely managed to match the ECS for performance is... not promising.
The point of the ECS is to be a very efficient solution to the run-time composition problem. You removed run-time composition and still weren't technically able to be more performant than it with your solution. You are comparing apples to oranges and still loosing on arguably the most key aspect of the entire problem space!