The Sokoban module (Molpy.Sokoban) as a whole is incomplete. However, generation, the most challenging portion, is implemented. It still needs fine-tuning, but most of that is uninteresting. By this I mean making new ultra-simple puzzles (which require no new functionality, just a good deal of work). The reason for this, essentially, is that, while it can generate everything in theory, it is highly unlikely to generate interesting puzzles; it would therefore be good to throw in more primitive puzzles, which could cause more interesting puzzles to arise. Additionally, in #1417, I sketched a significant optimization that could be done at the cost(?) of somewhat annoying built-in savescum prevention, but this isn't in yet since I'm not sure it's entirely necessary or good.
If someone else is interested in designing some more, the convention used is:
The Sokoban module (Molpy.Sokoban) as a whole is incomplete. However, generation, the most challenging portion, is implemented. It still needs fine-tuning, but most of that is uninteresting. By this I mean making new ultra-simple puzzles (which require no new functionality, just a good deal of work). The reason for this, essentially, is that, while it can generate everything in theory, it is highly unlikely to generate interesting puzzles; it would therefore be good to throw in more primitive puzzles, which could cause more interesting puzzles to arise. Additionally, in #1417, I sketched a significant optimization that could be done at the cost(?) of somewhat annoying built-in savescum prevention, but this isn't in yet since I'm not sure it's entirely necessary or good.
If someone else is interested in designing some more, the convention used is:
[String]{Char:"@", Wall:"#", Space:"_", undef:" ", Crate:"+", Target:"o", Filled target:"%", Char on target [unused, changeable]: "*"}