Looking for suggestions/advice

[Rodney Somerstein]

>Can you provide a built-in library of commands, functions, and 
>properties for game scripters? With this, your users could do 
>powerful things - say, change the color of all pieces, or set the 
>permissible moves for a piece - without having to use lengthy 
>scripts. Most of the scripting would already have been done for 
>them. (It would be quite a bit of work to write a library for game 
>scripters, but it has to be easier than trying to implement an 
>entire programming language for them.)

Jeanne,

As you have already seen if you are following this continuing 
disjointed, rambling saga, I have kind of come to the conclusion 
already that this would be the best way to implement things. Using 
this method also makes it easier for people to transition from simple 
game modules into much more complex ones without having to learn 
everything from scratch. They simply keep using the same commands, 
but start taking advantage of Transcript features also.

In Rev, this does mean that I would be building scripts on the fly 
and this is where I start running into RunRev imposed limitations on 
standalone apps.

>And I second Geoff's suggestion to get in touch with Kevin and 
>inquire about whether you can make special arrangements as to script 
>limits.

I will do so, but I've been trying to think through exactly what I 
need before asking. It would be nice if people could use at least 
some features of Transcript in their scripts without having to buy a 
DreamCard license. But what could/would they realistically be limited 
to? I see a need for loops, variables, and IF-THEN statements at the 
very least. Of course each object in the game needs to be addressable 
as well. I need to keep my proposal simple since I'm looking to do 
this at essentially no extra cost (or minimal cost).

Given the structure of Rev stacks, these scripts would probably have 
to be importable into almost any kind of object in order to work. 
Cards might need to have specific behaviors built in, etc. Of course, 
it would be possible to address all of this from a script at the 
stack or card level, but that might be a bit of a mess. I would 
basically have each element in the game try to call a script with the 
same name as the element - for example, playingPiece1 tries to call 
the playingPiece1 script which would exist in the card. That would 
enable me to import the commands to just one object. Does that seem 
like it might be a useful way to limit things; that is, restricting 
scripts to just one level of the message hierarchy?

-Rodney