Not exactly. It’s more like it uses a different kind of interface to create a command to the game that, as a piece of data, is the same “shape” as a simple parser command – a verb and (usually) a noun. But as Dan says, it doesn’t actually get there by parsing text.
It also implements a world model – interconnected rooms, portable and non-portable objects, inventory, etc. – that is so heavily associated with parser games that they’ve become near synonymous.
For the most part, I think that world model is what supports the game design paradigm that we’ve come to think of as parser games, and it’s what people who like parser games actually like about them. All I did was take out the actual parser, which is, for the most part, what people who don’t like parser games actually don’t like about them.
And since parser game authors – with the exception of a few numpties like me – generally start with an out-of-the-box parser, it means that the process of designing a game in gruescript is pretty much the same as designing a parser game.
So I’m really pleased to see Gruescript explicitly allowed in ParserComp. In terms of what sort of games people can expect to make, or play, it’s probably less of a departure than what people like Arthur diBianca are making – games that do parse text, but have an underlying structure that’s unlike anything you’ve seen in a parser game before. And I’m really looking forward to those. Variety is awesome, and it’s refreshing to see that even ‘restricting’ a competition to parser(ish) games still encourages new forms.