All entity meta-data is loaded in a similar fashion to the player entity. So states like basic attributes, skills, inventory, etc... are constantly parsing instead of being called upon when needed. Basically the engine wastes a lot of resources on absolutely useless tasks.
Cell Based loading; This significantly lowers the amount of entities allowable in a loaded cell aka a hard limit. Anything that surpasses the limit will basically break the engine resulting in game breaking issues or a crash.
Modular everything, basically the entire engine is a jigsaw puzzle that is stuck together with rubbers bands, tape, glue, gum, and anything else that could be used as an adhesive. If a module is updated, it broke another, then that get updated... then it continues on cascading through them all. Instead of building a comprehensive system that is efficient and easy to debug, they turned it into cooked spaghetti and dumped it on the ground.
The engine
doesn't support in engine animations, or any real features observed in the games. They are all produced via modules... that must be loaded and remain loaded individually. To give you an idea forward kinematics, inverse kinematics, translation, nor deformations. So stuff like a train car in Half-Life 1 are impossible to program into the engine without using workarounds, hacks, modules, or by exploiting bugs. For example imagine a single entity, except all the variables that determine it's actions are exterior to its programming. In this case separate controllers are applied to the entity to get it to function. Instead of programming in the required information into the entity itself. Remember the Broken Steel tram? It was a NPC character wearing a hat running a path. The NPC, train hat, paths, and trigger initiators all had to be loaded, instead of a path and a single entity...
Height map terrain generation, literally one of the most annoying ways to make terrain. In this case the terrain can only deform on a single axis, which means static assets that use a lot of computational power must be used to make simple terrain like cliffs.
Literally
no optimization tools, look at Fallout 4's Sanctuary. The entire area is just a bunch of static assets layered on top of each other, wasting all your computers resources to render something you're not going to see.
Most of the engine's operations are tied to the frame rate... *sigh* like physics calculations... So if the frame rate drops or increases, so does calculations the engine does. It's like playing an old DOS game on a modern PC without adjusting the CPU speed.
The
lighting within the engine is so out dated goldsrc (The engine the original half-life used) is still considered better. Plus the module for lighting is so inefficient that a good deal of computer calculations get soaked up by dynamic and static light sources. There is also a max limit of light sources within a cell... Heaven have mercy on the soul of the modder or map designer that placed one too many lights in a cell.
The engine constantly trips over itself trying to load separate modules, this often results in conflicts or weird easily preventable bugs that directly impact game play. Kind of like backing a horse up a mountain side. A great example of this is Fallout 4's bug of missing inventory items that still weigh down the player. Which is caused by a desync of modules that are intended to operate in tandem.
It still uses a
manual NavMesh system, Instead of programming an entity with a basic AI collision detection calculation for pathing, it uses a system that requires the entities to rely upon an actual separate mesh, that overlays everything the NPC can traverse. While some engines use navmesh systems, they instead only mark faces and vertexes of existing geometry for parsing without having to generate completely separate faces and vertexes.
Spawns and gibs, every time something is spawned it has to be fully loaded as previously stated, this also includes items and gibs. When something gibs the spawned entities often spawn inside each other and require a collision calculation to "bust apart", instead of using dynamic slices based on the existing mesh and having the engine calculate the slices. Plus the sudden extra calculations cause frame rate drops, and bugs quite often.
I could keep going but
