The longer-term goal is something CAD-like, where you get immediate feedback on design changes, analogous to how architectural CAD systems will highlight things like "lacking structural support" or "violates building code". With games simple versions could be "unreachable areas", "item never needed", etc. More involved versions could be generation of basically the kind of log data you would get from playtesting, only instead of empirical log data, it's analytically generated logs of possible playthroughs exhibiting requested properties: http://www.kmjn.org/notes/analytical_metrics.html
Many of the above can also be done with software-verification systems, which in some cases might be a better choice for efficiency reasons. However, the stuff coming out of the AI community is a lot more flexible as a modeling language, feels less like writing a fixed specification. It's also designed to be editable, e.g. you can add or remove game mechanics without re-formalizing the whole domain (a property John McCarthy calls "elaboration tolerance"), due to being based on a nonmonotonic logic. I was also already familiar with Prolog, and ASP's syntax is heavily modeled on Prolog's, even though they work entirely differently under the hood.
The longer-term goal is something CAD-like, where you get immediate feedback on design changes, analogous to how architectural CAD systems will highlight things like "lacking structural support" or "violates building code". With games simple versions could be "unreachable areas", "item never needed", etc. More involved versions could be generation of basically the kind of log data you would get from playtesting, only instead of empirical log data, it's analytically generated logs of possible playthroughs exhibiting requested properties: http://www.kmjn.org/notes/analytical_metrics.html
Many of the above can also be done with software-verification systems, which in some cases might be a better choice for efficiency reasons. However, the stuff coming out of the AI community is a lot more flexible as a modeling language, feels less like writing a fixed specification. It's also designed to be editable, e.g. you can add or remove game mechanics without re-formalizing the whole domain (a property John McCarthy calls "elaboration tolerance"), due to being based on a nonmonotonic logic. I was also already familiar with Prolog, and ASP's syntax is heavily modeled on Prolog's, even though they work entirely differently under the hood.
As far as getting started with it, the Potassco people have a pretty good book: http://potassco.sourceforge.net/book.html
As a much shorter way in, a colleague of mine wrote a tutorial on using ASP for generating game maps that are guaranteed to have certain properties: http://eis-blog.ucsc.edu/2011/10/map-generation-speedrun/