I love it! Thank you for making it and sharing it. And kudos for pulling it off.
I'm interested in the process of creating the puzzles. What are the conceptual steps you go through to create them? Do you use some algorithmic process or it's all handcrafted?
The process evolved and I have eventually settled with something like this:
*Step 1: Level Generation*
Let's say I decide to generate 3-ball levels at 4x4 grid
I do `generate_all_boards(width: 4, height: 4,max_obstacles: 6)`
and it will spit out all unique boards 4x4 with at most 6 tiles occupied by an obstacle with regards to all possible isoporphisms (rotations and mirrors)
Then for each level I start generating with BFS all possible positions reachable from this state. I have several complex heuristics to decide which of those positions makes the most interesting level.
After trying a LOT of heuristics I have made two main conclusions:
- on board there is very often one main trick and any of the interesting final positions have solution based on the same trick and trying to make more levels from one geometry is in all cases I tried a logic duplication.
- the maximum movecount is good enough of a metric
so I take the maximum movecount position, whith some other tie-breakers I don't remember.
e.g.
FINAL POSITION: score:
Movecount: 13
A B C .
a . c .
. . . b
. . . .
Rinse and repeat and I have aproximately 40k levels in the current database.
*
Step 2 : Level Curation*
I have created a version of the game with all those 40k levels split by groups of geometry, number of balls and number of obstacles, and a button "random level in current group". And I started playing those random levels over and over and over. I added a small button "Rate this level" so that whenever I got a level I thought was interesting or some new motive has appeared I rated it as "Super".
In the end all the "Super" levels made it into final game.
Let's do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework. As the author states, "So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities." Let's add another role to scrum called the craft master. This individual has excellent technical leadership skills and deep technical knowledge. The craft master's goal is to defend what the team is doing as a craft (much as the scrum master would defend the process of scrum itself), making sure that the craft's level of quality is manifested through a Definition of Done that takes way more of a center stage than it currently does. Would this be empowering developers?
I am on the fence. A master craftsman is awesome to have on a team, but I worry that, just as understanding of Scrum gets pushed off as the Scrum Master's problem, craftsmanship would become the craft master's problem. That's how we get "team leads" and "architects"
I'm interested in the process of creating the puzzles. What are the conceptual steps you go through to create them? Do you use some algorithmic process or it's all handcrafted?