Looking for suggestions/advice
b.xavier at internet.lu
Sat Aug 13 00:00:02 CDT 2005
> Thanks for all of the ideas, Xavier. This is exactly the kind
> of thing I was looking for. As I mentioned previously, I
> don't have a formal computer science background. I have read
> enough so that I am at least vaguely familiar with lots of
> different things which is why I figured that there are
> probably better ways to accomplish things.
i found this today which will be a great start for your
computer science degree ;) There's lots of these on the
net and they are always useful to see how they attack
the different kinds of problems we encounter. This one
is not about rev but the techniques are interesting for
both games and general programming.
there's three parts (articles)...
> I would love to take a look at the stack you mentioned for
> the BotWar game. I suspect that I can mine it for techniques.
Here is the top download page.
Now, it's made using my TAOO technique which boils down to
card contains all the main game scripts
there's a "loop"/game section
an arena/grid section (taken from xosmedialib)
finally, a bot section with the bot verbs: move, shoot, etc...
stack geometry is handled by gim.rev (see downloads->taoo->[rev->]managers
> From other ideas that you mentioned, I have been thinking
> along the ideas of more of what you call verbobject handlers
> so that each command isn't quite as large. It just seems that
> command scripts would become really cumbersome to maintain
> and modify if they get too large.
it depends how much you want to reuse your code elsewhere...
a oneword handler/function with parameters is easier to call sometimes,
than having lots of little interdependent script that could get
confused without enough parametrizing. Depends on the context.
For example, when a bot does a command, the internal scripts need to
know which bot did what and how... So a bot id parameter is essential.
> That isn't to say that I
> would be reluctant to add new functionality to existing
> commands. As long as new arguments are optional, it wouldn't
> break existing functionality. I think it is easier for
> non-programmers to understand a greater number of simple
> commands than a small number of complex commands.
if the handlers are named correctly and you follow a set of fixed
rules, it should be easy...
> As for your references to dynamic scripts and associative
> arrays, are there any pointers you can give me to learn more
> about these techniques as they would apply to Rev?
yes and no...
you create a script with a script and then
get "put" && the time
GIM and botspace.rev have a few dynamic scripts, im sure you'll
find plenty examples.
A bit off topic but just on the edge of dynamic scripting is this
verbobject model since it applies gracefully in the dynamic scripting
GIM is a nice example of this verb-object semantics and game scheme
but applied to geometry management.
TAOO, my working environment and framework in Rev or MC is just
like that too but distributed over a growing dozen of "object" class
stacks each with the object's verbs... There's some 200-600KB of
scripts available any time for any taoo component. I dont event
have to look at any script reference ever since it's so obvious
to listObjects, findFile, relatekeywords, etc...
> Also, what specifically do you mean by a pro-active selective
> bot editor? Is this just an editor that knows about the
> commands and helps the user with command completion or
> choosing the commands from menus so that it can prompt the
> user for the specific arguments needed?
you got it... selective meant that it only hands to the user the
available words - no mistakes allowed...
> Thank you for your help,
No, thank you, Dan and Marielle wanted a clear example of how taoo
works, and i just can't find the words or a way to make a simpler
example... This helped quite a bit...
More information about the use-livecode