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
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
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
↑ ↓←→ 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
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.
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
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
↑ ↓ ←→ 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
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
↑ ↓ ← → 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
↑ ↓ ←→ 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
↑ ↓ ←→ 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
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
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.
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.
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 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
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
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
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next