Closed luxaritas closed 5 years ago
From Tim:
ConstraintBox
should be be an abstract base class, or an interface, rather than being the single kitchen sink for all constraint types.- Constraints should be separated into their own classes. A given
Constraint
object should know how to construct its appropriateConstraintBox
visuals. Currently,PoseEditMode.updateConstraint
handles all constraint logic, which is madness.- All SCRIPT constraints should ideally be completely removed from the external script system (see the next wishlist item), and implemented in game code directly, and the SCRIPT constraint type should be removed. (My understanding is that there aren't actually user-created constraints; the custom script-based constraints that many puzzles have are actually created by the Eterna team, so embedding their logic in the game itself is appropriate.) The script system, by necessity, executes asynchronously (even though scripts themselves are generally synchronous, they need to be fetched from the network when first accessed, which is necessarily an async operation.) This means that
updateConstraint
cannot always return an "isSatisfied" value, which adds some unnecessary complexity to constraint updating code.
Per the last point - I think user-generated constraints might still be desirable at some point. That said, the API could still be improved, and even dropped for now with the idea that it might come back later.
Resolved in #156
Constraints should be reimplemented as an interface, where each constraint would provide appropriate images, validation, etc. As noted by @tconkling, UI/logic decoupling in ConstraintBox is also desirable.