MiniD 2 - Might as well be done

[Jarrett Billingsley]

On Sat, Jun 20, 2009 at 6:27 AM, hasen<hasan.aljudy at gmail.com> wrote:
>
> Say, a guy like me, who's not very well experienced in writing useful
> applications (I mostly write throw-away code or university assignments).
>
> If I want to write a small program and I want to make it "scriptable", then
> I suppose that I can use MiniD for that, so do the docs explain how I can do
> that, or do you kinda assume that I already have an experience doing this
> kind of thing?

That's a good point-of-view to ask that question from, and I hadn't
considered it.  :)

As a short answer, I'll give you an account of a small experience I
had making a little game.  I stubbed out a small engine in D, and
wanted to make MiniD a part of it.  So the first thing I did was just
use it for a configuration and level data system.  It's very nice to
be able to write the data files using a fully-capable language.  A
normal configuration file, stored as XML (shudder) or JSON or whatever
other data-only format you can think of just seems so pedestrian
compared to the flexibility and expressiveness of a programming
language.  Need ten boxes in a row?  [Box(x, 0, 0) for x in 0 .. 10].
How about if you want to move all the objects over by 100 units?
objects.each(\i, obj -> obj.pos.x += 100).  You'd still be typing the
namespace declaration by now if you were using XML.

Then I was messing with physics, and wanted to be able to tweak the
various simulation parameters on the fly, rather than changing,
recompiling, running, seeing that it's horribly off, quitting,
changing, recompiling.. so I bound some MiniD functions to set the
physics parameters, added an in-game script console, and then I could
just change things within the game until they worked right.  Then I
could just write all those settings out to a file - from within the
console, of course - and use them in the original program.

The game hasn't gotten much further than that, but already I can see
how it's kind of working out.  The scripting seems to kind of work its
way into areas of the program where it'd be nice to do runtime
customization.  The in-game console alone opens up so many
possibilities: setting up testing scenarios by spawning objects and
enemies and  jumping to arbitrary levels or positions or events;
loading various configuration files in-game to test out which ones I
like better; querying all sorts of things about the game and engine
on-the-fly (why is performance so bad?  ohh, there are 480,000
particles, I'm never killing them off..); and so on and so forth.
It's already saved me a lot of time by eliminating the
compile-run-test cycle.

Being a programmer, I tend to think in terms of computation and
programmability, and embedding a scripting language in my program lets
me interact with it (through a backdoor or as a matter of course) in
those terms.  *That* is what I like about it.  :)