The real problem with the Automizer

[Lord Estraven]

... IMO is that it wants to be an imperative, procedural programming language.

I'm serious. Right now it uses JSON, a data format. And any moderately functional automizer profile quickly develops into a nightmare of deeply nested, branching potentialities. It winds up completely inscrutable.

But even a complex automizer profiler could be better expressed by switch statements, or even if-then-else statements. Much more expressive, much less verbose. And it's not like we have grave security concerns that discount Turing-complete languages.

e.g. right now my generic "destroy unenchanted equipment" rule looks like this

Code: Select all

[
  {
    "action": "destroy",
    "condition": {
      "conditions": [
        {
          "conditions": [
            {
              "symbol": ")",
              "type": "symbol"
            },
            {
              "symbol": "(",
              "type": "symbol"
            },
            {
              "symbol": "]",
              "type": "symbol"
            },
            {
              "symbol": "[",
              "type": "symbol"
            },
            {
              "symbol": "/",
              "type": "symbol"
            },
            {
              "symbol": "\\",
              "type": "symbol"
            },
            {
              "symbol": "|",
              "type": "symbol"
            }
          ],
          "type": "or"
        },
        {
          "conditions": [
            {
              "status": "average",
              "type": "status"
            },
            {
              "status": "bad",
              "type": "status"
            }
          ],
          "type": "or"
        }
      ],
      "type": "and"
    },
    "module": "ToME",
    "name": "Destroy Average Stuff"
  }
]

Now let's say we did this in something like Python.

Code: Select all

if object.symbol in [ "[", "]", "(", ")", "|", "/", "\" ]:
    if object.status in [ "average", "bad" ]:
        object.destroy

Much better, I'd say. Less confusing to edit by hand, probably even for computer novices. Plus it becomes trivial to throw in other arbitrary requirements:

Code: Select all

if object.symbol in [ "[", "]", "(", ")", "|", "/", "\" ]:
    if object.status in [ "average", "bad" ]:
        if not "Dark Sword" in object.name:
            object.destroy

With the automizer, that requires a whole lot of messing around.

What say you all?

[Yottle]

This looks like a good idea to me.

I once tried to write a universal automizer (which isn't that hard to do conceptually) but realized that I needed a separate set of rules for every class and race. Something that could handle conditional logic more robustly would be better.

[AnonymousHero]

This looks like a good idea to me.

I once tried to write a universal automizer (which isn't that hard to do conceptually) but realized that I needed a separate set of rules for every class and race. Something that could handle conditional logic more robustly would be better.

There's no way that embedding anything like Python is going to happen in my fork. The whole point was to get away from the ridiculous amount of incidental complexity of integrating two languages.

That said... I've never been particularly happy about the way the automatizer worked. I think the system in e.g. Entroband/PosChengband is much better and it's pretty simple to understand. The downside is that might perhaps be a little special-casey.

The squelch system in current Angband is probably the best of breed, IMO, because it a) reflects what the player actually wants, namely to ignore items, b) it's simple UI-wise, and c) doesn't actually irreversibly destroy items if you're careless. However, with the ridiculous number of drops in T2, I don't think it's quite feasible to use it. :/. Perhaps a variant which actually destroys items when you walk onto them would be acceptable.

(However, it's probably not something I'm interested in implementing ATM, nor do I have the time, honestly.)

[Lord Estraven]

I kind of figured. Ah well.

I might attempt to DIY here, not sure it's worth the effort though. Rather put the effort into another variant.

[AnonymousHero]

FWIW, I think it might be a fun little programming learning experience (if you're so inclined) to implement a parser for something like PosChengband (using some sort of parser generator).

I also don't think it would be too hard to implement something quite Pythonesque (like your strawman proposal).

[Zizzo]

Well, there was my old replacement auto.lua that wrapped a more readable language around the internal XML-esque automatizer data format. Your example rule, for instance, could have been written in ATP (as I dubbed the language) as:

Code: Select all

rule "Destroy Average Stuff" destroy
  if symbol = "[", "]", "(", ")", "|", "/", "\"
     and status = "average", "bad"
     and not (name = "Dark Sword");

Unfortunately, it sounds like things have changed too much for it to be useful anymore.

[Lord Estraven]

Wowza. Cool!

That would work, I think, up to version 2.3.9-ah (at best). Not past that, because it uses JSON rather than XML after that version.

Edit: BTW, @AnonymousHero, I'm curious - did the original implement its own XML parser or something?

[AnonymousHero]

Edit: BTW, @AnonymousHero, I'm curious - did the original implement its own XML parser or something?

Yup. Or, rather... calling it a "parser" would be generous. It was a regexp-based thing that didn't actually understand real XML, it just understood the very small subset that the automatizer used. I can't recall if it also relied on the particular formatting (e.g. "no newlines between attributes" and such), but I think it might have done.

(I couldn't find any reasonable XML parsers for C++ at the time and so decided on JSON.)

[Lord Estraven]

Naive, regex-based XML "parser", right... There but for the grace of God go I.

Anyway, I'm considering a go at the imperative automizer-script-thing. Never worked with parser generators before though. Googling up Flex/Bison, the syntaxes look like some bastard hybrid of Ruby, Haskell, and BNF... Though I feel like the main challenge would not be setting up the parser, so much as integrating the parser into the game in a meaningful and maintainable fashion.

(I guess the best/only way to do that, would be to have Flex and Bison invoked during the build process? Maintaining chunks of autogenerated, optimized C does not sound like fun.)

[AnonymousHero]

Googling up Flex/Bison, the syntaxes look like some bastard hybrid of Ruby, Haskell, and BNF... Though I feel like the main challenge would not be setting up the parser, so much as integrating the parser into the game in a meaningful and maintainable fashion.

(I guess the best/only way to do that, would be to have Flex and Bison invoked during the build process? Maintaining chunks of autogenerated, optimized C does not sound like fun.)

Yes, definitely -- if we're talking about parser generators they should be incorporated as a part of the build somehow. It's customary to actually have it as a "special" build target which is only called when explicitly asked for and to just include the generated files in the VCS repository -- so that "ordinary" users who just want to build from source can do so without installing bison/flex/whatever.

I'm not sure what's best when using C++ these days, but Boost.Spirit seemed interesting at least...

(I think there's a new-improved-C+11-ified-version of Boost.Spirit on the way, but I'm not sure what the status is on that. See http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/ for a starting point.)

If we use a template-based solution, then all that's really needed is to include the headers (similar to how Bandit++ is incorporated)