Re: A few questions about scripting

> How does one make a unit test for a line of script in a trigger's
"OnEnter" event passing values of the
> wrong type to a function it calls?  I'd love to have more unit tests.

By calling the "OnEnter" event in the script in a test.

With proper mocking and dependency injection, you should be able to unit
test every line of code. We have some old code written pre-tests that don't
quite get to that level, but for pretty much all new code, we get very
close. The rule is: "If you care if it breaks, it needs a test to make sure
it doesn't." And if you don't care if it breaks, then why are you writing it
at all?

Regarding custom languages: how's the debugger support? I think the debugger
support for existing languages (Python, Lua, Erlang, JavaScript,
ActionScript etc)  is spotty enough that I wouldn't even want to think about
a language for which I'd have to write the debugger. (And a language that
could be debugged by gdb would be close to "no debugger" anyway -- "slow"
doesn't even begin to describe it, and all the GUI wrappers on top of it ;-)

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Wed, Apr 28, 2010 at 5:45 PM, OvermindDL1 <[email protected]> wrote:

> 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
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com