www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Monster 0.8 + Tutorial

reply 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
May 09 2008
parent reply 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
May 09 2008
parent reply 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
May 09 2008
next sibling parent reply 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
May 09 2008
parent reply 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.
May 09 2008
next sibling parent reply =?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
May 09 2008
parent reply 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
May 10 2008
parent reply 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.


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
May 10 2008
next sibling parent reply =?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
May 10 2008
parent 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
May 10 2008
prev sibling parent reply 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.


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

should be possible to come up with something that's essentially unique within three letters...if not, well ... mnstr?
May 10 2008
parent reply 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.

"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

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
May 11 2008
parent 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
May 13 2008
prev sibling parent 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/
May 10 2008
prev sibling parent reply 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.
May 09 2008
parent reply 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
May 10 2008
parent reply janderson <askme me.com> writes:
Nicolay Korslund wrote:
 janderson Wrote:

 On most of the projects I've used game scripting languages on, 


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 

 reloaded - as Monster is very object oriented, you would in fact be 

 class when you reload a script. So would the changes affect existing live
 objects of the class (which could have "interesting" side effects for 

 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 


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 

 notification (FindFirstChangeNotification on windows, inotify on 

 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
May 10 2008
parent reply 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
May 13 2008
parent 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
May 13 2008