Can I use Revolution for this?

[Dan Shafer]

I am relatively new to RR, though I have done a lot with similar 
environments in the past, so take my answers here as 
non-authoritative but likely informed!

At 3:53 PM -0400 8/2/02, Rodney Somerstein wrote:
>
>Now, my concern has to do with the standalone limitations. Is there 
>a way that I can read data from an external file and then create all 
>of the playing pieces and such that are needed in a particular game?

I don't know of *any* limitation, other than computer memory, on the 
number of size of external files a RR stack can read or write. 
Writing scripts that can read metadata from a text file and create RR 
objects will certainly be a non-trivial task, but that would be true 
regardless of the computer programming language or environment you 
might choose, as far as I know.

>Even a small game is likely to have more than 50 pieces. It seems 
>that I'm going to bump into the limitations of the standalone 
>environment as each of these pieces would be an object and the  user 
>needs to be able to script them to a certain extent. Is this a real 
>concern, or is there a simple workaround?

What specific limitations are you referring to here? The inability to 
allow users of your stacks to script the custom objects? That's an 
intriguing problem but I can think of a couple of different ways of 
accomplishing that. Just as one quick example, you could accumulate 
the user's script commands (which you'll of course have to find a UI 
to allow them to generate) into a field or even a custom property 
(untested) and then just tell your stack to "do" that container 
object.  This kind of dynamic programming is one of the cool features 
of RR and other xCard tools.

>My initial thoughts are that there might be several possibilities. 
>First of all, I could pre-populate the game engine with a couple of 
>thousand objects. At run-time, I can read from a configuration file 
>to determine what graphics to set for each object, how to resize 
>them, etc. Startup time for a game would be slow, but this might 
>work. Can a Rev stack even handle this many objects on a single card 
>without bogging down and having the performance become too slow to 
>be workable?

I'm guessing, but my suspicion is that RR doesn't impose any 
*limitations* on this front. Performance might be another question. 
It shouldn't be hard to write a stress script that would test RR to 
the max on this issue, though.

>Not all of the objects would be visible at any one time, but I don't 
>know that this would make much of a difference.

Probably not, except for increased delays in the time it takes to 
move between cards.

>As for the scripting issue, the only thing that I can see to do is 
>to create a custom scripting language for the game designers to use.

You *could* do that and it might even be smart. But another approach 
might be to provide a more interactive way for users to script 
objects without having either to learn a scripting language. "Back in 
the Day," I created a product called Dan Shafer's scriptExpert which 
enabled anyone to write HyperTalk by pushing buttons and answering 
dialogs. You might not need to get quite that elaborate, but assuming 
you could define an isolated subset of Transcript your users need to 
use, creating a clean UI for them to interact with would be feasible, 
maybe even easy.

Take the output from this interactive session with the user, stuff it 
into a RR container object and then "do" the container...and voila!

I have actually created a small example of this kind of RR 
development. As soon as I have time, I plan to post it somewhere for 
people to see as a learning idea.

>I would read these scripts in from a configuration file or files and 
>then parse them myself. XML would probably be ideal for this, but I 
>don't think that Revolution supports XML. I'm also concerned about 
>the speed of doing this kind of parsing if I can't use XML. This 
>would let me get around the scripting limitations in standalones.

Again, I'm not sure what standalone limitations you're referring to 
here, but I may well be overlooking something. I haven't yet licensed 
RR (though I will be doing so soon).

XML may not be the best route to go here even if you can find a way 
for RR to support it. While XML is a very nice markup language for 
inter-application data transfer and other things, its overhead is 
huge and performance of XML-based applications, in my experience, 
tends to be pretty horrendous.



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer
Writer, Spiritual Student and Teacher
Founder, Fellowship of One Mind, Monterey, CA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~