1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
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."
|
