Request for 'lint'-style debug assistance

[skeezix]

From a blog posting:

I’m thinking stuff like.. – ensure rooms all have two ways in/out (ie: dead ends not allowed?) – or better yet .. a graph check, that ensures all rooms are reachable (this is distinct to the above in that you could have rooms AB and CD that satisfy exit/enter above, but never reach each other, so that you essentially are wasting rooms.)

[MikeTaylor]

Nice idea, to offer linting options. I think the way I’d want to do this is with a command-line option --lint (or -L for short) that takes as its argument a sequence of characters indicating specific conditions to check for.

[MikeTaylor]

Fixed in release v1.3.0. At present the two supported options are -L e (report rooms with no exits at all) and -L E (upper case; report dead-end rooms with a single exit). You can use -L eE to get both together. For example:

$ scottkit -c -L eE t7.sck > /dev/null
warning: 1 rooms with no exits: 'cave'
warning: 3 rooms that are dead ends: 'throne', 'cell', 'crypt'
$ 

I considered doing the graph-walking check you mentioned, but decided it would not really be useful: virtually every adventure game has vast sections cut off from the start location in its initial state. For example, running such a check on Zork would report that all the underground locations are unreachable -- as indeed they are, before you move the rug, open the trapdoor, and enter it.

I'll happily consider other linting options -- file additional issues at will!

[MikeTaylor]

More voluminous output from linting Nosferatu (which is not quite ready to release):

scottkit -c -L eE nosferatu.sck > /dev/null
warning: 5 rooms with no exits: 'hidden', 'ledge', 'cave', 'inpit', 'bottom'
warning: 8 rooms that are dead ends: 'coffin', 'busstop', 'bus', 'shed', 'hut', 'chasm', 'cavern', 'underground'

The thing is, there are good reasons for all five of those "trap" rooms to have no exits.

[skeezix]

The lint option is wisely not a required runtime param; so it can be used for 'recommend me some issues!'; it woudl probably be unwise to add in state tracking.. going too far off into IDE-land: ie .. let the operator specify 'okay, that one exception is ok, suppress it for next run', so they could in the future re-run to only find new issues. That'd be easily done by the user doing a run > output/foo and then diff'ing after some runs. (I'm thinking like in CADs here, with pcb capture, where you have a set of rules from your pcb supplier such as min and max trace with and distance and such, so you run the exception report, and then you flag which are not really issues or not since theres no way the software can really be sure, and then over time you can easily catch new exceptions.. pretty handy. But this is a pretty niche of a niche, so, ehhh.. :)

A furthger option down the rabbit hole could be ... what about a room or item that is not referred to, and otherwise seems dead end? ie: if there is no action pointing to it, and it is dead end (or in 'nowhere'), then it is probably either a source easter egg, or a bug?

Either way, awesome that you snuck in some features so rapidly, when you're still hot on the path; can always add more down the road!

[MikeTaylor]

Thanks. Jeff. I fixed a stupid lint bug in v1.4.0, which I just released (it would crash when not given a --lint option!) and made bunch more minor changes.

On the way forward for linting: I agree that there are lots of things that could be done, and trying to find entirely unreferenced rooms (reachable neither via exits nor actions) is among them.

At this stage, though, I am keener to be shaking out actual bugs than adding too many new features. Do let me know if you find any.