• Nicolay Korslund (8/8) May 09 2008 I have written the very first tutorial for Monster, the D-based game scr...
• janderson (14/29) May 09 2008 Hi,
• Nicolay Korslund (9/20) May 09 2008 You link the VM (which is a library) into your app, and call a function ...
• Bill Baxter (8/9) May 09 2008 Might want to consider a different extension since .m is what Matlab has...
• Nicolay Korslund (2/12) May 09 2008 Hmm, that's true. Looks like the .m extension is also used by Maple, Mat...
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (3/6) May 09 2008 Gettext uses .mo for locale translations, but maybe that's still "less".
• Nicolay Korslund (9/16) May 10 2008 You are right, but I don't think that will be as much of a problem thoug...
• Bill Baxter (6/23) May 10 2008 Well the other thing is code editors. They often decide which mode to
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (3/7) May 10 2008 Wouldn't you normally edit the .po files rather than the binary .mo ?
• Bill Baxter (4/13) May 10 2008 I have no idea, I just googled for "emacs mo-mode" and there was a hit
• Charles D Hixson (4/34) May 10 2008 How about .mn? Anything use that? Or .mon or .mns? It
• Bill Baxter (6/42) May 11 2008 I was going to say how about just .ms for "monster script", but
• Nicolay Korslund (3/13) May 13 2008 By some miracle it appears that .mn is completely unused (or as good as)...
• Mike (6/9) May 10 2008 Why not .monster?
• janderson (18/48) May 09 2008 On most of the projects I've used game scripting languages on, design
• Nicolay Korslund (13/23) May 10 2008 That's a pretty neat feature. I'm not sure what would happen when a scri...
• janderson (35/51) May 10 2008 design would simply run a bat file and instantly the running
• Nicolay Korslund (6/6) May 13 2008 Thanks for the helpful feedback and ideas.
• janderson (26/34) May 13 2008 - 2D/3D Space fighting game. Used Lua controlling the game by terminal,...

Nicolay Korslund <korslund gmail.com> writes:

I have written the very first tutorial for Monster, the D-based game scripting
language:

http://monster.snaptoad.com/tutorials/tutorial1_basics.html

It only covers the very basics (how to run scripts, what functions and
variables look like, etc.) The syntax is pretty similar to D, so this tutorial
shouldn't be too hard to follow for D developers. I'm writing partially with
future users in mind though, including game modders and such, so I'm trying to
keep it simple.

I also released version 0.8 a little while ago, you can find it here:

http://monster.snaptoad.com/download.html

Monster is a very young language, and even some essential features like garbage
collection are still under development. However, it it is mature enough to play
around with, and I'm working actively on the missing features.

I've had some great suggestions already as to where to take the project next,
but if you are interested in game development and have some ideas for the
language, I'm always open for more suggestions.

- Nico

janderson <askme me.com> writes:

Nicolay Korslund wrote:
 I have written the very first tutorial for Monster, the D-based game scripting
language:
 
 http://monster.snaptoad.com/tutorials/tutorial1_basics.html
 
 It only covers the very basics (how to run scripts, what functions and
variables look like, etc.) The syntax is pretty similar to D, so this tutorial
shouldn't be too hard to follow for D developers. I'm writing partially with
future users in mind though, including game modders and such, so I'm trying to
keep it simple.
 
 I also released version 0.8 a little while ago, you can find it here:
 
 http://monster.snaptoad.com/download.html
 
 Monster is a very young language, and even some essential features like
garbage collection are still under development. However, it it is mature enough
to play around with, and I'm working actively on the missing features.
 
 I've had some great suggestions already as to where to take the project next,
but if you are interested in game development and have some ideas for the
language, I'm always open for more suggestions.
 
 - Nico

Hi,

Nice work.

So one thing I don't understand.  How would I bind a script into DMD or 
C++.  Also would this work with Visual C++?

It would be nice if the D binding API supported features like automatic 
reloading (optional of course).  Knowing how to debug it in a debugger 
would also be useful (if possible).  Built in profiling would be another 
nice feature.

Does it use DMD as the underlining compiler?  How efficient is it?

If I could use it with Visual C++, I would push for it on my next 
project which is some time off.  It seems to be much better then lua 
simply because its typesafe.

-Joel

Nicolay Korslund <korslund gmail.com> writes:

janderson Wrote:
 Hi,
 
 Nice work.
 
 So one thing I don't understand.  How would I bind a script into DMD or 
 C++.  Also would this work with Visual C++?

You link the VM (which is a library) into your app, and call a function telling
it to load the script file. At the moment the scripts have to be separate .m
files in the file system, but more input options will come later (since that is
a trivial thing to add.) You can then call script functions from your code (and
vice versa using 'native' functions.)

I plan on writing tutorials on all this in the coming weeks, but for now the
only "documentation" is the example set in the download.

The C++ API hasn't been set up for Windows yet, but it will basically be just a
static library and a header file so it should work fine with VC++ when it's
completed. 

 It would be nice if the D binding API supported features like automatic 
 reloading (optional of course).  Knowing how to debug it in a debugger 
 would also be useful (if possible).  Built in profiling would be another 
 nice feature.

I'm not quite sure what you mean by automatic reloading, could you explain?

I agree completely about the debugger and profiler (and also coverage analysis
and other statistics) and I plan on adding this at some point, but I don't know
when.

 Does it use DMD as the underlining compiler?  How efficient is it?

If you mean the script compiler, then no. It's written entirely from scratch,
and compiles to bytecode only.

As for efficiency, the overall design is build with efficiency in mind, but I
have purposely done very little detail optimization. The internal architecture
is going to change a lot, and optimizations would have to be maintained and
redone all the time. Like they say, premature optimization is the root of all
evil. But efficiency (speed and memory) will be THE top priority once the
language becomes a little more mature.

- Nico

Bill Baxter <dnewsgroup billbaxter.com> writes:

Nicolay Korslund wrote:

 At the moment the scripts have to be separate .m files in the file system, 

Might want to consider a different extension since .m is what Matlab has 
used since the 70's.  Given the increasing use of sophisticated math and 
physics code in games, it's not unlikely that a game developer (or other 
user of your scripting language) will also be a Matlab user.  Matlab is 
used widely in education too (in the US at least), so anyone who is a 
student is likely to have Matlab installed.

--bb

Nicolay Korslund <korslund gmail.com> writes:

Bill Baxter Wrote:

 Nicolay Korslund wrote:
 
 At the moment the scripts have to be separate .m files in the file system, 

 
 Might want to consider a different extension since .m is what Matlab has 
 used since the 70's.  Given the increasing use of sophisticated math and 
 physics code in games, it's not unlikely that a game developer (or other 
 user of your scripting language) will also be a Matlab user.  Matlab is 
 used widely in education too (in the US at least), so anyone who is a 
 student is likely to have Matlab installed.

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.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

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

--anders

Nicolay Korslund <korslund gmail.com> writes:

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 :-)

- Nico

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

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 ?

--anders

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Charles D Hixson <charleshixsn earthlink.net> writes:

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?

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Nicolay Korslund <korslund gmail.com> writes:

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

Mike <vertex gmx.at> writes:

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/

janderson <askme me.com> writes:

Nicolay Korslund wrote:
 janderson Wrote:
 Hi,

 Nice work.

 So one thing I don't understand.  How would I bind a script into DMD or 
 C++.  Also would this work with Visual C++?

 
 You link the VM (which is a library) into your app, and call a function
telling it to load the script file. At the moment the scripts have to be
separate .m files in the file system, but more input options will come later
(since that is a trivial thing to add.) You can then call script functions from
your code (and vice versa using 'native' functions.)
 
 I plan on writing tutorials on all this in the coming weeks, but for now the
only "documentation" is the example set in the download.
 
 The C++ API hasn't been set up for Windows yet, but it will basically be just
a static library and a header file so it should work fine with VC++ when it's
completed. 
 
 It would be nice if the D binding API supported features like automatic 
 reloading (optional of course).  Knowing how to debug it in a debugger 
 would also be useful (if possible).  Built in profiling would be another 
 nice feature.

 
 I'm not quite sure what you mean by automatic reloading, could you explain?

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

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.

2) A callback in the API to say when a script has changed would be 
useful.  The callback could either print a message or return false to 
prevent the script loading.


 
 I agree completely about the debugger and profiler (and also coverage analysis
and other statistics) and I plan on adding this at some point, but I don't know
when.
 
 Does it use DMD as the underlining compiler?  How efficient is it?

 
 If you mean the script compiler, then no. It's written entirely from scratch,
and compiles to bytecode only.
 
 As for efficiency, the overall design is build with efficiency in mind, but I
have purposely done very little detail optimization. The internal architecture
is going to change a lot, and optimizations would have to be maintained and
redone all the time. Like they say, premature optimization is the root of all
evil. But efficiency (speed and memory) will be THE top priority once the
language becomes a little more mature.
 
 - Nico

I totally agree about pre-mature optimisation.  I thought you might by 
compiling to a DLL or something.

Monster's pretty impressive stuff as its complicated stuff writing a 
programing language compiler.

Nicolay Korslund <korslund gmail.com> writes:

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

janderson <askme me.com> writes:

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

Nicolay Korslund <korslund gmail.com> writes:

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

janderson <askme me.com> writes:

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