On Sat, Jun 20, 2009 at 6:27 AM, hasen<[email protected]> 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. :)
