eternagame / EternaJS

Eterna game/RNA design interface
Other
12 stars 10 forks source link

Refactor Constraints #2

Closed luxaritas closed 5 years ago

luxaritas commented 6 years ago

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.

luxaritas commented 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 appropriate ConstraintBox 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.

luxaritas commented 5 years ago

Resolved in #156