Re: A few questions about scripting

On Wed, Apr 28, 2010 at 5:14 PM, Will Vale <[email protected]> wrote:
> On Thu, 29 Apr 2010 01:32:19 +1200, Brandon Van Every <[email protected]>
> wrote:
>
>> The past is the past.  But given the languages that are available
>> off-the-shelf today, would you still be inclined to roll your own?
>
> I doubt it. What would be the point? If you want a general purpose embedded
> language you'd probably choose Lua. The situation was a lot less clear in
> 1998 though.
>
> To be fair, developing the language, compiler and runtime initially didn't
> take that much programmer time - a couple of man months? But we did pay for
> a false start before, and maintenance later. Plus those two months pushed
> back some of the design schedule which had knock-on effects. The perils of
> starting from the ground up.
>
>> Let alone roll 2 of your own.
>
> I think I'd still be tempted to roll my own high level mission language, for
> the reasons in my earlier post. This feels like a good trade-off between
> coder effort (not much) and ease of building the game (much).
>
> One thing I forgot to mention in the original pros/cons - a benefit of
> having a 'proper' language (and toolset) embedded in your game is it opens
> up a lot of modding possibilities. We even wrote our mod front end
> (selecting and activating multiple mods) in script as a post-release patch.
> But that's a PC-specific luxury, not many people can do that these days.

I am curious, have you all thought of a Lisp/Scheme'ish style
language?  I am not actually using Lisp/Scheme myself, rather I made a
purely C++ embedded and tied S-Expression language (although using far
more 'english' type works rather then annoyances like car/cdr/etc...)
with the full power of a Lisp style macro and read-macro system (to
make the language whatever you want it to be).  I just use this
myself, not released it, but it works really well, and it has no
interpretive layer, it gets compiled directly to LLVM JIT on-the-fly
(even the macro/read-macro type functions are compiled, and if called
in the code then the parsing stream is passed to the compiled function
that still runs at full speed).  I have a few odd constructs, like you
have to explicitly state which functions are visible to the C++ side
(as they will have cdecl wrappers created around the fastcall function
signatures that are required for the tail-call support), and there are
no global variables (I am making it Actor based, kind of like Erlang),
and actors can call actors or functions, but functions can only
functions, and message passing is mostly optimized out.  It beats C++
in speed in math functions at least.  But I am curious why no one has
already created such a thing, it was surprisingly easy to do.
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com