avoid closures where possible; they lead to weird garbage collector effects!


assets
------

assets are cached. each asset type has a module (e.g. `mesh`, `image`, `sound`, etc). These have the following functions:

	* `get(filename)` - cached load of the given file. throws error if it cannot be found
	* `forget(filename` - remove the cached copy, if any of the given file
	* `clearCache()` - clear the full cache for that asset type

individual assets may have additional functions.


entities
--------

entities are just identifiers. they are UUID strings. they index into components.


components
-----------

components are data tables. they are supposed to contain only booleans, numbers, strings, and tables containing the other three types; they may contain additional state data (e.g. userdata, functions, etc) if they are prefixed by an underscore, and these things are transient and will have to be re-created on the next load from the bools, strings, numbers, and tables. the one exception to this rule is glm types; components *are* allowed to contain Vec3/Mat4/Quaternion/etc. (the glm types serialize nicely so this is not problematic.)


systems
-------

systems are pure functions (NOT closures!!). they must be embedded in tables that give them a name and indicate their dependencies, i.e. which other systems *must* execute before them in order for things to work correctly. They have a signature like

> `system(db, dt, [params])`

where params is a table. all parameters, including the params table, are passed in by the systemdb every frame; the system should NEVER close over them.

(i may allow an exception to the system closure rule for the sake of physics update frequencies, but in general i would prefer to avoid them at all costs.)

system modules should return an array of any systems needed for that conceptual system to work; the system db will add them all as one "system."