Rodney Said > 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. <http://www.devarticles.com/c/a/Development-Cycles/Learning-About-the-Graph- Construct-using-Games-Part-1/> 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. http://monsieurx.com/modules.php?name=Downloads&d_op=viewdownload&cid=14 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... note: stack geometry is handled by gim.rev (see downloads->taoo->[rev->]managers http://monsieurx.com/modules.php?name=Downloads&d_op=viewdownload&cid=23 > 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 do it 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 usage. 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... cheers Xavier _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
