Messages

Although I'd perhaps propose to again split this into verb ID and object ID to make further handling more convenient; for example, you will be able to run some specific commands in case of each "look", or tell "I cannot look at xxx" if the object is unknown, etc.
And of course there are still ways to split the giant switch into several parts to make it work in current AGS.

Splitting it up will definitely allow it to fan out further and get past that particular limitation.  What I found interesting was that structs could have functions which allow them to access its members using the 'this' keyword.  Unfortunately though, they don't have the ability to store any type of function "pointer".  If this were possible, then the for() loop method could find the matching word, call through the function pointer and break from the loop (arbitrarily repeating this method for sub-commands as you suggest); but alas....

Doesnt AGS support case switch? Would that also work?

There is no way you can use Parser.Said with switch, because you are not testing single result, but results of multiple function calls with different parameters until you find which works. The values at switch's "case" are constant expressions that must be known at compilation time.

(Also, Gurok knows better, but I guess switch may be using same internal mechanism for nested code blocks as if/else)

Unless there is a limitation on the switch statement having a certain number of cases, the easiest thing to do would be to convert the resulting operation to a value that can be used within a switch...case from a loop.

The way that I would approach this using an array of structs, one the string that I would want to check and the other member with the value to use in the switch() case construct.  Each case could then dispatch to a method to handle that particular match.  For example:

Code: ags

    struct ParseDispatch {
       String text;
       int dispatchId;
    };

    ParseDispatch dispatch[2];

    dispatch[0].text = "look blanket";
    dispatch[0].id = 1;

    dispatch[1].text = "do something";
    dispatch[1].id = 2;

Now, after setting up the strings you want to check and declaring the functions you wish to call, you can use the loop to do the appropriate check and if you find a match that returns true from the Parser.Said() call, get the dispatch value and break from the loop:

Code: ags

int dispatchId = 0;

for (int i = 0; i < 2; i++) {
   if (Parser.Said(dispatch[i].text)) {
      dispatchId = dispatch[i].id;
      break;
   }
}

switch (dispatchId)
{
   case 1:
      LookAtBlanket();
      break;
   case 2:
      DoSomething();
      break;
   default:
      break;
}

Of course, this example is contrived and can be tidied up a bit.  You could use an enum value for dispatch IDs instead of hard coded numbers for readability or choose to use the loop counter as the ID for a match and just use an array of Strings instead of structs.

That being said, is there a limitation on the number of case statements in a switch?

Greets!

My name is Joe and I currently live in the US.  I've downloaded and started to learn how to use AGS several years ago, but my workload at the time didn't allow me to devote much time to working on a game.

I grew up with interactive fiction, starting with Colossal Caves, Scott Adams' Adventures as well as the Infocom interactive fiction.  As the genre evolved, I became a fan of Sierra's games, owning several of the games and collections over time, from King's Quest, Space Quest, Police Quest, Leisure Suit Larry and Quest for Glory.  I also became enamored with LucasArts' games, especially the talkies, such as Day of the Tentacle, Sam & Max Hit the Road, The Dig, Loom and Indiana Jones and the Fate of Atlantis.

I had created two interactive fiction games as a hobby many, many years ago and after having played graphical "point & click" adventures, wanted to eventually create one of my own.  I am a software developer who will probably be more comfortable with scripting and logic, but will most likely fall short in the graphical arts and music category (although I am very willing to grow and learn in that arena).

I hope to become a contributing member in the forums one of these days, but I do have a lot of reading to do and hopefully come up with a demo that is worth the time for others to play and evaluate.  There is plenty of reading material out there which will keep me busy for some time, but I'm sure I will have some questions to ask the experts from time to time.

My first priority is to understand the scripting language; I can probably be most helpful in helping write, debug or optimize scripts.

Regards,

Joe