is a better way that would allow more control by game developers. For example I can see just hooks being a limiting factor

library vs engine.

library beats engine for flexibility every time.

from recent research of mine, it appears that a library combined with boilerplate code is the way to go. The library provides the flexibility. The boilerplate code provides the "framework" or "engine". but since its boilerplate, the user has full control, and is not limited by hooks, forced to inherit from an existing object hierarchy, etc. sort of an "open source" engine.

library vs engine update:

i pulled an all nighter friday, and tried to convert my testbed engine to a layered library layout.

when it came to move_entity(), doing it without callbacks was ugly:

movement_left=move_first()

// check and handle collisions

if entity_collision()..... // library call

if user_collision().... // user implemented, checks for collisions with the world/level map, etc. IE game specific stuff other than entities.

while (movement_left)

movement_left=move_next()

IE the findfirst - findnext "pattern" for step movement, with user code in-between doing collision checks and handling.

actual code was twice as long and twice as ugly.

callback was much nicer:

pre-move entity

if entity vs entity collision occurs, callback user_collision_handler()

if callback user_defined_collision() occurs, callback user_collision_handler(). or even simpler, one callback: process_user _collisions()

update position

it worked so well, i used the callback "pattern" for similar cases.

by the end, i had inverted the engine to be boilerplate code and layered libraries, then re-inverted it back into an engine.

so now its looking like engine is better, despite the callbacks. you just have to have enough hooks of the right type in the right places to provide needed flexibility.