Can I use Revolution for this?
dan at danshafer.com
Fri Aug 2 17:55:01 EDT 2002
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
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.
Writer, Spiritual Student and Teacher
Founder, Fellowship of One Mind, Monterey, CA
More information about the Use-livecode