Can I use Revolution for this?

Rodney Somerstein rodneys at
Fri Aug 2 20:15:00 EDT 2002


Thanks for the reply. There are some great ideas here. Hopefully some 
others will chime in as well.

>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.

My concern isn't related to the size of external files. Rather, it is 
the limit of how many objects can be created in a standalone after 
reading the external data. I'm kind of fuzzy on what can and can't be 
done in a standalone, but it seems that this might be an issue.

>  >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.

Actually, the script commands from the user will probably just be 
contained in an external text file. I agree that it is cool to be 
able to do this kind or dynamic programming. From my reading of the 
limitations of the starter kit, which is supposed to be the same as 
for standalones, I'm not sure that I can create this many objects on 
the fly. In the starter kit, you can only insert 20 objects into the 
message path. I don't know if this is a cumulative total or means 
only 20 at one time. I also don't know if I can check when the user 
issue a mouseDown to see if there is a graphical object underneath 
the cursor and then add it to the message path or if it already has 
to be there in order to detect the mouseClick on that object.

>>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.

I suspect that you are right about there being no hard limits on how 
many objects can be there. I will have to create just such a test 
stack unless someone else chimes in with some anecdotal or hard 
evidence. Again, part of this concern is that if I have to generate 
the objects ahead of time, performance might always be bad even for a 
relatively small game.

>>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.

I wouldn't likely actually be moving between cards, as a board games 
tends to have fairly static views. This issue could be there for 
switching between stacks, though. Again, as you stated above, I will 
just need to write some tests to find out.

>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.

I remember Dan Shafer's scriptExpert. In the early 90's, I was the 
lead on a fee-based scripting support line at Apple for HyperCard, 
AppleScript, and Apple Media Tool. I think I looked at almost every 
HyperCard product ever created. That was one of the more interesting. 
I hadn't thought of creating this kind of UI, but now that you 
mention it, I might do just such a thing for later releases.

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

Again, due to limitations of standalones, I'm not sure that I can 
stuff do scripts into that many objects. Also, in the starter kit, do 
scripts can be only 10 lines long. I'm not sure if I'm limited by 
this when adding scripts to a dynamically created object. The 
documentation on standalones is frustratingly non-existent except for 
some comments here on the mailing list. I'll post another message 
about that. Hopefully Jeanne will have something to say relating to 
that situation.

>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 look forward to seeing it when you get the chance.

>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.

This is a bit of a concern to me as well related to XML. However, the 
only time that the XML would come into play would be when loading a 
new game file. This might create acceptable performance. The 
performance of a command parser that I write for a custom game 
development language might not be any better in Rev than using XML. 
If I do have a custom language, then I can put as many commands into 
an object as I want as Rev would just see it as text (same would be 
true for XML). I would then have to already have scripts created that 
execute those "commands". The downside to doing this that I lose a 
lot of flexibility in that all features added for a game have to be 
supported by my engine. Otherwise, I could just let the users code 
the features.

If I can't do this in Revolution, I'll likely end up going to Python 
(maybe PythonCard if I can ever get it to work under OS X), Java (I 
could use Jython), or possibly SmallTalk if the new version of 
VisualWorks non-commercial adds good OS X support. (I notice that you 
have more than a passing interest in these other languages and 
environments as well ;-)


More information about the Use-livecode mailing list