Perhaps consider creating an engine, and then having the engine provide all the relevant functionality.
Consider moving to promises for loaded assets, so they can be more easily loaded in an async fashion?
Would be nice to abstract the passing around of the current gl context when constructing new assets that require access to it. This way, the only thing that needs to be exposed by the engine's api is creating a drawable/entity.
Perhaps also consider abstracting out entities to some degree, and making drawables a tree, ala THREE. Thus, a Resonator would really be an empty drawable that has the children [ResonatorBody, ResonatorCore], with the transforms of the parent passing to the children.
Then, a Portal could become even more fully-featured, with its own resonators, links, shield, etc becoming children.
Basically, Entities could be mostly factored away, since they basically are what has been described here. More robust tools for managing children would be nice.
Perhaps consider creating an engine, and then having the engine provide all the relevant functionality.
Consider moving to promises for loaded assets, so they can be more easily loaded in an async fashion?
Would be nice to abstract the passing around of the current
gl
context when constructing new assets that require access to it. This way, the only thing that needs to be exposed by the engine's api is creating a drawable/entity.Perhaps also consider abstracting out entities to some degree, and making drawables a tree, ala THREE. Thus, a
Resonator
would really be an empty drawable that has the children[ResonatorBody, ResonatorCore]
, with the transforms of the parent passing to the children.Then, a
Portal
could become even more fully-featured, with its own resonators, links, shield, etc becoming children.Basically,
Entities
could be mostly factored away, since they basically are what has been described here. More robust tools for managing children would be nice.