scaling

docs/entities.md

@@ -15,3 +15,22 @@ Components, if they have a defined transform, are relative to the entity they re
 Entities are defined via a typical scene graph system. This allows for easy reuse of components when designing levels.
 
 When the game is run, the movement relationships are broken, and the physics system takes over. In the physics engine, each entity is a direct child of the world. Objects can still be constrained to other objects via the physics system.
+
+The transform properties have local, global, and screen space accessors. For example, for position ..
+
+- pos: the relative position of the object to its master
+- worldpos: the position of the object in the world
+- screenpos: the position of the object in screen space
+
+The core engine only remembers each object's world position. When its position is requested, it figures its position based on its parent.
+
+## Inheritence? Composition?
+
+The idea behind how the engine is oragnized is to encourage composition. Compisition creates cleaner objects than does inheritence, and is easier to understand. And yet, inheritence is useful for specific circumstances.
+
+- Creating a specific unique object in a level
+
+There are only two cases where inheritence can be utilized in this engine:
+1. Whole entities can be subtyped. Only values can be substituted. An ur-type must define all functions and behaviors of an object. but then that can be subtyped to change only a handful of properties.
+
+2. Entities can be subtyped when thrall to another entity. This can only be done once. Thrall objects, like components, can be defined only once on an ur-type. Sub types can only change parameters, and not of the sub objects.

docs/scene.md

@@ -0,0 +1,23 @@
+# The Scene
+
+There are a multitude of representations of your entities in the engine. The two most prominent are the entity system, where entities can be master or thrall to a master. And then there is the physics view, which is mostly flat, where objects are all part of a "world", but can be connected to one another via various physics constraints:
+
+- Pin joints, rigidly connected
+- Slide joints, with a mix or max distance
+- Pivot points, stuck to position but allow rotation
+- Groove joint
+- Damped spring
+- Damped rotary spring
+- Rotary limit
+- Ratchet joint
+- Gear joint
+- Simple motor
+
+The most common sort of connection will be master and thrall. When editing, this relationship allows for simple
+
+## Entity vs Global
+The physics engine stores all objects on the global level. The center of the world is [0,0]. Physics does not handle scaling at all.
+
+The master/thrall relationship is closer to a scene graph. When the master moves, its thralls move, and their thralls move, etc. When a master scales, it is the same.
+
+When the game starts simulating, objects ignore their parent relationship after they are created. They become only part of the world and simulate as such.

docs/scripting.md

@@ -27,7 +27,8 @@ Computation takes place in turns. Each entity has functions called, if they exis
 
 |function|description|
 |---|---|
-|start|called when the object is loaded|
+|load|called after the object is loaded, including in editor|
+|start|called when the object is loaded during gameplay|
 |update(dt)|called once per game frame tick|
 |physupdate(dt)|called once per physics tick|
 |stop|called when the object is killed|