VGA SCI with Parser!

[OmerMor]

Yes - it's possible!

A little background:
The early AGI & SCI0 games had a built-in ("kernel-mode") parser which you used for writing commands. Later, in SCI1 games, Sierra replaced the parser with a point-n-click interface. The parser op-codes were still part of the SCI language, but they were deprecated, and trying to use them would cause an error.
So it would seem that using a parser in VGA SCI1 games would be impossible.
Brian once suggested writing a parser in the game scripts ("user-mode" parser), but so far noone took his challenge and wrote one.

And then came HWM & trodos...
HWM found out that in the transition from SCI0 to SCI1, Sierra forgot to "take out" the parser from one VGA game - the 1990 christmas card VGA demo. He wrote a simple script, and together with trodos they actually managed to use the parser, and revive it from the dead...

If you want to try it out, here is the demo with the SCRIPT and VOCAB patches:
https://drive.google.com/file/d/0B5j-_ZMS8_UoSjE5VVNEb2RPcms/view?usp=sharing

Start typing! When you do you should see the dialog prompt. The "look" command will be recognised.
That's it!

If you wanna see some pictures, here they are:




Enjoy!

Omer.

[Cloudee1]

It's a novel idea Omer but it may not be practical to have both the text parser and point and click. I have made a totally point and click interface for our ega version, and by the time youv'e added all the clickable stuff which is actually a hundred times easier than coming up with all the different phrases that someone would type in,  but to also include all the if saids would seriously put a hurt on the memory.

I don't know what kind of memory resources the later sci games required but if it's anything like we have now, there just isn't room in the game for both.

[OmerMor]

I think having both interfaces is redundant - the beauty in this is that it's possible to make a parser-based game (which personaly I liked very much). It's also would be possible (when a decompiler would be available) to take an existing EGA SCI0 game like SQ3, and make a new VGA version of it with the same parser interface by just changing the views and pictures.
For me, knowing it's possible, fill me with joy 
Omer.

[trodoss]

Ah...the infamous "Christmas Demo"...  I was going to copy some of that over, but I guess I don't need to

As far as a text parser goes... I know that what got people excited about this in the first place was the possibility of VGA games with the "old" text parser.  If it was just point+click  and VGA, I can tell you that the "best" engine to reverse engineer make work is Secret of Monkey Island 2 demo (SCUMM).  It supported things like scrolling game screens, an intuative point+click interface, and a fairly nice 'cross platform' open-source interpreter (ScummVM).  There is a site, LucasHacks, that has a lot of information about SCUMM.  No one has made a SCUMM editor, but from what I have seen it would be *much* easier to reverse engineer.  I have been tempted to look into it but it seems Lucasarts has a habit of trying to control their 'fan made'/'hacks' of their games.
----
... I can definately say that not all the "tools" are there yet to really make a VGA game (SCI1) with this parser.  Sure, Brian Provinciano's beta did have support for opening the resouces, but it would take some more work to edit them.  Plus, you have a different "object" model in this game, so your SCIScript isn't going to translate over.  I have been working on deconstructs of the exact script necessary, but has taken a while (life has gotten in the way). 

Another (what seems like a less popular route) to get VGA games made would be to use the SCI0 "scripts" with SCI1 resources using FreeSCI interpreter.   If "Glutton" (the more unstable SCI1 branch of FreeSCI) was further along, this would be an option. 

[lskovlun]

Hi,

If Glutton was further along, what do you mean "further along"?!
Regarding the object model in SCI1, the differences are not that huge, especially if you use the text parser interface. I have successfully written small scripts for SCI1 interpreters (don't ask - it was a very ugly hack). I failed to make it work with Sierra's interpreters (it is quite difficult to debug without a working debug window), but it worked in FreeSCI. The memory model is different, so your memory woes are likely to disappear, provided you use text resources correctly (that feature in Sierra's original compiler which generated code to handle text resources automatically would be cool here).

What would have to be done in order to make the current template game SCI1 compatible would be this:

• Add new (dummy?) classes and selectors as required by the SCI kernel interface.
• Create a vocab.994 file compatible with the chosen interpreter (SCI studio does not have an editor for this file; would have to be done manually).
• Look at the FreeSCI code and figure out how the kernel/script interface changed. Some of these changes are subtle (e.g. the Motion class), but I believe we have most of them covered. Change the template game appropriately.

[trodoss]

lskovlun,

If I understand correctly, Glutton does not allow the saving of games (which would keep either a game made to run into it short, or keep people from using it at all).  Maybe that has changed in a few months since I looked at it last?

From what I can tell from looking at dissassembled code, SCI0 and SCI1 may have not been that different in their kernel calls (added more), but Sierra must have changed their object model in their own code around this time.   FreeSCI is more "forgiving" of code than the Sierra interpreter, and does make experimenting hard.

I have been able to recreate some of the classes and have actually gotten compiled scripts from it.  What I am unsure of is if Brian's last (latest --SCI1) compiler was complete.  I have found that I can make things work if I just insert bytes for commands in (like loading the palette) where it does not work from "compiled" code.

[lskovlun]

trodoss,

It is true that we had to take savegames out when designing Glutton. On the other hand, you say that FreeSCI is more forgiving than Sierra SCI for developers. I'd say that depends on what you're doing; for example, some Sierra games use the StrAt kernel call for accessing arrays. We have had to include special code for this case (among others) in FreeSCI, because it abuses the particular implementation of StrAt (in FreeSCI, a variable is really 32 bits wide instead of 16). Glutton in its original incarnation would have aborted with a VM error here. Similarly, Christoph implemented type checking of arguments to kernel functions; we have had to relax this checking somewhat as we discovered other kinds of abuse.

I still think you are overstating the case when you say that Sierra changed their object model. If you are dealing with parser based games, you could easily use the template game we have already, with the changes I outlined earlier. The major changes only come in when we consider the point-and-click stuff; we still have state machines, room objects, actors, views, etc. working like they did in SCI0.

Your last comment ("if I just insert bytes for commands (like loading the palette)") makes it sound like your biggest problem is with Brian's compiler being designed for a particular interpreter version. I can only say it has worked for me (I used the PQ3 interpreter and class hierarchy) -- the crash I got could have been debugged if I had spent more time on it than I did. I had a simple program, written in an afternoon, that made SCI Studio-compatible .SCO files out of the original game and linked my own code against them. Since I used the files from an original game, I had none of the problems you'd have to solve in adapting Brian's template.

Lars

[trodoss]

lskovlun,

I know you have worked really hard on FreeSCI/Glutton, and I would think it would be a natural fit for a community-supported VGA platform (especially considering the community interest in the text parser-based games).  I would say that when it is functionally complete (and can save games), it would be the best way of accomplishing the goal of VGA + text parser.  I know that is not the goal of FreeSCI, but it would be a nice side-benefit.

I have been working with the "Christmas Demo" parser so far (as it still has the text parser included, and works off of SCI0 file structure).  Brian was working with Leisure Suit Larry VGA for his SCIScript complier. 

My most successful 'hacking' the parser I am using has been by by adding in SCRIPT.xxx (mostly SCRIPT.000) into the directory (using the old Sierra patch backdoor).  I probablly could have linked it back into the RESOURCE.xxx file(s), but I was trying to do something easy to test.

I would ideally like to make a 100% SCIScript solution that can generate code that works both under this older Sierra parser and FreeSCI.  I don't know if that is really feasable, but I figured it was worth a try.

[OmerMor]

It's worth a try trodos, trust me! 
Give it your best shot...