refactor systems to use cleaner dependency resolution

1 files changed, 17 insertions, 1 deletions

diff --git a/honey/notes.md b/honey/notes.md
index 5dd25e7..16ccc49 100644
--- a/honey/notes.md
+++ b/honey/notes.md
@@ -13,11 +13,27 @@ assets are cached. each asset type has a module (e.g. `mesh`, `image`, `sound`,
 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 can be embedded in tables that indicate dependencies, i.e. which other systems *must* execute before them in order for things to work correctly. They have a signature like
+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."