Monster 0.8 + Tutorial

[janderson]

Nicolay Korslund wrote:
> janderson Wrote:
> 
>> On most of the projects I've used game scripting languages on, design 
>> would simply run a bat file and instantly the running application/game 
>> would update with their new script.  A message would be displayed in the 
>> running app, "script blar.m reloaded.".
> 
> That's a pretty neat feature. I'm not sure what would happen when a script is
> reloaded - as Monster is very object oriented, you would in fact be reloading a
> class when you reload a script. So would the changes affect existing live
> objects of the class (which could have "interesting" side effects for some
> changes), or only affect newly created instances?

I guess it depends on how far you want to go with it.  I think with lua 
we always kept the longterm data in client rather then in the scripting 
language.  Perhaps when the callback fires the user could make the 
decision to reload particular instances.  Although it would be cool if 
it could somehow recreate all the objects by copying over pieces that 
remain the same.  Maybe some sort of debugging object could be made that 
contains the names of all the variables in the script could be used for 
that.

> 
> I guess that depends on what the scripts are being used for. What kind of
> tasks did you script in your projects?

AI, Spells, State machines, Game rules, binding of special effects at 
certain times.  Basically data driven stuff that you want to push to a 
tool (which generates the script), art of design.

BTW: I've never been a big fan of using scripting languages for game 
programming, but other people are so I've been forced to use them.  I 
prefer data/tools that are constrained to the problem at hand.

However there are 2 places I've found them useful:
1) State machines
2) To save on having to by compilers for everyone.


> 
>> To save you some time if you plan to do this, here are some pointers:
>> 1) Don't try date scanning lots files, this is fast for a couple of 
>> files but will thrash the disk for lots of files, leading to noticeable 
>> delays in the app.  Instead I recommend writing to an index file with 
>> the files that have changed.  Then monitoring that file for changes; Or 
>> using some other communication method.
> 
> It could be faster (although more complicated) to do this using file system
> notification (FindFirstChangeNotification on windows, inotify on linux) and let
> the file system notify you when a file changes. But I don't have much
> experience with this, maybe you do.
> 
> - Nico

It is; but it still can slow things right down when you get a load of 
file changes.  That might be what you want to do, however I think the 
best approach is to send a message to the application.

-Joel