In general, constraints are what give good puzzles only one solution. In Latgrid, there are many types of constraints that are available to the setter to restrict what the solver will do. Some are implicit, like the size and shape of the grid or what objects can be drawn with the given controls, others are explicitly programmed by the setter, like no repeating digits allowed in a row, column, or box of a sudoku. All of these constraints will do (at least) two things. 1) They inform the solver what puzzle the setter had in mind and allow solvers to catch simple mistakes early (if they enable error highlighting). 2) It could enable automatic solvers to guide the setter in what's possible and try out puzzle designs without having to manually work out all the logic him-/her-self.
Because of this dual-goal mindset, I eventually want to structure explicit constraints to have a form that caters well to both. Aka, you add code for error highlighting and get auto-solver logic for free. But I have to start somewhere, so I'm just going to get some simple error highlighting going.
Basic plan going forward
Let me think of the easiest form to implement so I can get some code going.
First, only work with one grid type at a time, i.e. constraints must be rewritten for each grid type. That's the most common case and multiple grid types can be handled with multiple constraints for now.
do not implement user aliases or program presets at first. Only use extremely basic components. If the core is bad, the whole thing will be bad.
Try to think of a way to implement multiple constraints systems at once so I can test the difference between them. I might even support multiple versions indefinitely, adding more and deprecating some as I go.
For now, I think having a text input that evals JavaScript to encode constraints is the simplest way to do it; don't waste time designing a UI around the wrong API. It might even be just imperative JavaScript at first. That would allow me to change the API much more easily.
Only mark errors for now. Worry about automated solving and any compatibility with them later.
[ ] Make layer object styles use classes and class sets to style their own objects. It might not actually be classes, but a set of ids and some styles instead so I manage which objects have which styles all in one place. I guess which is more common, that I change styling without touching objects or change which objects exist (and their attirbutes) without touching styles?
[ ] A class set has a set of ids and some styles. I need to convert multiple class sets into a map from ids to their classNames and a map from classNames to class styles.
[ ] Figure out how to check for "errors" in the logic of the solve.
[ ] Mark errors using class sets. The first version will simply change the stroke width to something and change its color to red.
Description
In general, constraints are what give good puzzles only one solution. In Latgrid, there are many types of constraints that are available to the setter to restrict what the solver will do. Some are implicit, like the size and shape of the grid or what objects can be drawn with the given controls, others are explicitly programmed by the setter, like no repeating digits allowed in a row, column, or box of a sudoku. All of these constraints will do (at least) two things. 1) They inform the solver what puzzle the setter had in mind and allow solvers to catch simple mistakes early (if they enable error highlighting). 2) It could enable automatic solvers to guide the setter in what's possible and try out puzzle designs without having to manually work out all the logic him-/her-self.
Because of this dual-goal mindset, I eventually want to structure explicit constraints to have a form that caters well to both. Aka, you add code for error highlighting and get auto-solver logic for free. But I have to start somewhere, so I'm just going to get some simple error highlighting going.
Basic plan going forward
Let me think of the easiest form to implement so I can get some code going.