This zettel concerns itself with how entities are to respond to agent actions in a manner logically consistent with the game rules. It’s clear that the agent submitting actions should not be aware of environmental constraints in place; it simply generates actions, and observes if they are not executed as desired. So should the corresponding entity be responding for properly managing this action, i.e. as opposed to simply updating its state corresponding to the submitted action, should have to ensure correctness according to game rules internally (e.g. check if the move is valid in the current state before executing). Or, should entity just make the update according to its own reaction logic, and then the env uses a set of constraints to check the global state at each tick to ensure correctness according to game rules?
While the former is a valid and potentially more flexible approach, it somewhat clashes with my idea of providing an easy API for a client to define their own Entities (perhaps there’s a simpler way around this e.g. having a method devoid of systematic checks that the user can override, and then it’s checked for correctness internally by the entity somewhere else. Take for example cars, overriding an acceleration mechanism and then making sure later that it makes sense, outside of the clients view). I say this because I don’t think the client should have to ensure logical consistency and know about internal game rules to define reactionary agents; this simply makes a lot of assumptions about their underlying knowledge with the environment itself
Was thinking about how to more formally specify logic behind an environment in the problib, came across matter.js and its constraint system. This gives me ideas on how to build rules into the environments programmatically, and have a set of Constraint objects
Note how there’s a difference between wanting to take an action (on the agent side), how an entity might respond to a given action, and then the env ensuring only valid responses can be executed. For example, lifting my arm up and hitting a table. As an agent I’m submitting an action to move my arm, but constraints from the environment (ie existence of the table and it being in my way) are preventing my body (entity) from carrying out this action and desired response. This should be considered when building the constraint system. Right now after some initial thought, it seems most clear that constraints should be functions of both the previous state and the next state “to be” (a temporary state after desired entity updates are made). Then constraints are checked, which ensure that the to be state has a logically correct progression forward from the previous state. This reminds me of database systems, which apply a series of transactions in a sandbox mode (a temp state) and when a conflict occurs or constraint is violated, it rolls back these changes or prevents the entire transaction from occurring. Note that there could some issues with how this unrolls; it feels like things could get complicated quickly if all entities are computed based on this temp state, and then one entity was actually failing a constraint, causing every computed value to be incorrect and invalid.