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

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

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

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

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.

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

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

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

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