Sensor Controller Interpreter

I've started programming a prototype for MicroSwarmigism, and while things are going slowly, I've got a general notion in place that I want to record here. The idea is that changes to the game occur in three stages, consisting of a sensing stage where data is collected, a controlling stage where changes are calculated, and an interpreting or application stage where instructions are carried out. This is more general then what I'm describing here, and in fact it seems to be a nice way to decompose things like genetic operators or generally operations on a data structure. For now I'm focusing on how I'm planning on using it in Unity.

All three of Sensors, Controllers, and Interpreters are parametrized by their input and output, so they are really just unary functions. The difference is in how they are used, and in Unity, when they are called. Sensors are intended to be used to determine information about the state of the world such as mouse input or positions. Sensors run in Update, and I plan on only running Sensors when their data is asked for, so they are lazy. Controllers are intended to produce the data that is used to make changes. I call this data instructions, but really it can be anything. The Interpreters are intended to apply the instructions to some piece of data. This is done in LateUpate, so all sensors will have pulled their data and ordering of Controllers will not effect Sensors. The ordering on Interpreters is not controlled, so their effects should be commutative if possible.

An example of this that I'm working out right now is this: a Sensor collects mouse input information, a Controller reduces this information to a delta in mouse position, and an Interpreter merges the change in position with the position of a cursor. This would be how the mouse cursor works. Adding a collision sensor and left click sensor would allow a controller to determine is something is selected, and an interpreter to change the cursor's current selection.

Another example would be a swarm with a sensor telling it the position of each of its gisms, a controller averaging that position, and an interpreter on each gism using this information to effect its next move.

Yet another example would be mating- a sensor on a gism would determine close by gisms, another would determine energy level, a controller would determine if mating should occur. The given gisms should then have a sensor providing genetic material, and an interpreter applying crossover.

The one downside to this setup that I can think of is that since Update is used so collect data and produce instructions, and LateUpdate to apply them, there is no time that is used to enforce invariants the way LateUpdate is sometimes used. For example, if the mouse cursor goes off the edge of the screen, we could use LateUpdate to place it back on the screen after all other movements have been applied. I plan on simply being aware of this and programming carefully to mitigate the problem.