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 that depends on what the scripts are being used for. What kind of tasks did you script in your projects?

> 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

On Fri, 09 May 2008 23:15:59 +0200, Nicolay Korslund <korslund@gmail.com> wrote:

> Hmm, that's true. Looks like the .m extension is also used by Maple, Mathematica and Objective-C, to name a few. I think I'll switch to the much less occupied .mo.

Why not .monster?

-Mike

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Anders F Björklund wrote:
> Bill Baxter wrote:
> 
>> Well the other thing is code editors.  They often decide which mode to use based on file extension.  I don't do anything with gettext mo files, but a quick check reveals there is indeed an "mo-mode" for emacs meant for editing those gettext files.  So I'd avoid .mo too if I were you.
> 
> Wouldn't you normally edit the .po files rather than the binary .mo ?

I have no idea, I just googled for "emacs mo-mode" and there was a hit for it.

--bb

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) or anything that art or design will need to tweak.

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

Bill Baxter wrote:
> Nicolay Korslund wrote:
>> Anders F Björklund Wrote:
>>
>>> Nicolay Korslund wrote:
>>>
>>>> Hmm, that's true. Looks like the .m extension is also used by Maple,
>>>> Mathematica and Objective-C, to name a few. I think I'll switch to
>>>> the much less occupied .mo.
>>> Gettext uses .mo for locale translations, but maybe that's still "less".
>>
>> You are right, but I don't think that will be as much of a problem though.
>>
>> I guess the biggest issue with shared file extensions is on Windows and other
>> GUI-based systems where users expect to open common file types by double
>> clicking on them, or in other cases where it's easy to confuse what kind of file
>> you're dealing with. Like if you have a year-old directory called all-math-scripts/
>> and you're a regular user of Matlab, Mathematica and Maple - I wouldn't want
>> to be that person :-)
> 
> Well the other thing is code editors.  They often decide which mode to use based on file extension.  I don't do anything with gettext mo files, but a quick check reveals there is indeed an "mo-mode" for emacs meant for editing those gettext files.  So I'd avoid .mo too if I were you.
> 
> --bb
How about .mn?  Anything use that?  Or .mon or .mns?  It should be possible to come up with something that's essentially unique within three letters...if not, well ... mnstr?

Charles D Hixson wrote:
> Bill Baxter wrote:
>> Nicolay Korslund wrote:
>>> Anders F Björklund Wrote:
>>>
>>>> Nicolay Korslund wrote:
>>>>
>>>>> Hmm, that's true. Looks like the .m extension is also used by Maple,
>>>>> Mathematica and Objective-C, to name a few. I think I'll switch to
>>>>> the much less occupied .mo.
>>>> Gettext uses .mo for locale translations, but maybe that's still "less".
>>>
>>> You are right, but I don't think that will be as much of a problem though.
>>>
>>> I guess the biggest issue with shared file extensions is on Windows and other
>>> GUI-based systems where users expect to open common file types by double
>>> clicking on them, or in other cases where it's easy to confuse what kind of file
>>> you're dealing with. Like if you have a year-old directory called all-math-scripts/
>>> and you're a regular user of Matlab, Mathematica and Maple - I wouldn't want
>>> to be that person :-)
>>
>> Well the other thing is code editors.  They often decide which mode to use based on file extension.  I don't do anything with gettext mo files, but a quick check reveals there is indeed an "mo-mode" for emacs meant for editing those gettext files.  So I'd avoid .mo too if I were you.
>>
>> --bb
> How about .mn?  Anything use that?  Or .mon or .mns?  It should be possible to come up with something that's essentially unique within three letters...if not, well ... mnstr?

I was going to say how about just .ms for "monster script", but apparently that's already a 3DS Max Script.  Too likely to clash with the game-dev demographic.

But .mns looks good.  Only thing I see using that is "AutoCAD ASCII Menu".

--bb

Bill Baxter Wrote:

> Charles D Hixson wrote:
> > How about .mn?  Anything use that?  Or .mon or .mns?  It should be possible to come up with something that's essentially unique within three letters...if not, well ... mnstr?
> 
> I was going to say how about just .ms for "monster script", but apparently that's already a 3DS Max Script.  Too likely to clash with the game-dev demographic.
> 
> But .mns looks good.  Only thing I see using that is "AutoCAD ASCII Menu".

By some miracle it appears that .mn is completely unused (or as good as) so I think I will settle for that. .ms would probably have been even better, but as you say it's too likely that game-devs have 3DS installed. And besides I don't want the Microsoft legal department on my back ;-)

- Nico

Thanks for the helpful feedback and ideas.

It would be interesting to hear what kind of projects you have worked on, just to get some context around it, and if you have some other ideas for what a scripting language / framework could contain. If you want to share that kind of stuff, of course.

- Nico

Nicolay Korslund wrote:
> Thanks for the helpful feedback and ideas.
> 
> It would be interesting to hear what kind of projects you have worked on, just to
> get some context around it, and if you have some other ideas for what a
> scripting language / framework could contain. If you want to share that kind of
> stuff, of course.
> 
> - Nico

- 2D/3D Space fighting game.  Used Lua controlling the game by terminal, recording/playback of the game and game logic rules.
- FPS (scripting was used for AI and game logic rules -> Health appears here after you kill this guy)
- Barnyard ("Kinda" open world with minigames instead of fights, scripting was used for AI and quest system)
- Startrek MMO (scripting was used for spells, special effects, communication between the server and flash on the client)
- Secret project at Riotgames http://www.riotgames.com/ (can't tell you about this yet).


Ideas:
It seems that every time I've used scripting languages the design has come out slightly differently.  I think being able to represent a state machine in its simplest form would be really useful.  Simple/easy to use binding to the C++ / D would be useful.  Being able to easily move parts of the scripting language back into C++ when it becomes slow (ie similar syntax).  Being able to record and playback script commands would be nice, although I'm not sure how many people would use that functionality other then myself.

The biggest reason I get for using a scripting language is faster iteration. That is why automatic reload is a very important piece.

Finally, (one I can't put my finger on) a reason to use a scripting language other then iteration.  I think the scripting language needs to provide something that would be more difficult to do in C++ / D.

-Joel