Re: Scripting

[Chris <chris@starforge.co.uk>]

Jorrit Tyberghein wrote:


>>Who says you need to when gcc is a download away, template makefiles and
>>"scripts" are easy to distribute and you have dlopen?
>>
> 
> Well... Try to get that working reliably on all platforms (windows, linux, ...) :-)


:) platform independance, or at least making it easy to use it on windows, 
is not a high priority for my game (quite the opposite in fact - the general
response given to people who ask for a Windows version is "when I'm dead and
buried, if you're lucky, and even then I'll come back to haunt you"). But
if it is an issue,

http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html

that's what libraries like glib are for. If you have all the platform 
specific stuff in an object that is included in the library at compile time 
based on the platform the compiler indicates then it should be possible to 
make it work, at least on Linux, HP-UX and Windows.


> Also doing the compiler is not very fast.


There are trade-offs everywhere. The four big problems with scripting via 
linked libraries are (IMO):

- if you change the code, you need to type

   make nameoflib

   and wait the handful of seconds it takes to recompile the library, then
   you need to bring up the console in the game and tell it

   cs_reload nameoflib   (or whatever)

   Whereas, if you're using an interpreted scripting engine then you edit the
   code and tell the game to reload it. However, you pay for not compiling
   the code as it now has an intepretation overhead.

- debugging can be a pain unless you have a rigid set of rules about
   checking pre and post conditions, a custom version of assert that
   prints out file and line numbers, function names, descriptions and
   a stack trace - I have code to do this if anyone is interested -
   a well documented interface to the engine and a set of functions for
   handling things like allocating memory, accessing files and so on.
   Unlike interpreted scripting where there is a clear division between
   problems in script and bugs in the engine (assuming a correct
   interpreter..) using libraries means everything is one big piece of
   code and picking out which bit is going wrong can be trickier...

- It is harder for non-coders to pick up. Although if you do it right, it
   isn't as bad as some people would claim - with the use of example or
   "fill in the blanks" code, macros to hide more complicated operations
   and by avoiding the more complex programming concepts it is no harder to
   program your stuff in C++ than it is in python (it is certainly easier,
   or at least more understandable than doing them in perl!!)

- interpreters can check access, restrict the code to a sandbox and do
   array bounds checking and so on. When you're using libraries you don't
   get any of this - whether this is a problem or not depends on the
   situation. The scope for malicious tinkering is greater in libs than in
   interpreted scripts, but how much of a problem that is is up to you...

*To me* these four significant problems are outweighed by the increased 
speed (and hence scope for greater complexity) and flexability that libs 
offer. To someone else, who needs the increased security of a script
sandbox, doesn't mind about the interpretation overhead or needs 100% 
guaranteed portability, these four points may be too much.

Chris
-- 
  .------{ http://www.starforge.co.uk }-----. .--------------------------.
=[     Explorer2260, Designer and Coder     \=\ P: TexMaker, ROACH, site \
=[___You_will_obey_your_corporate_masters___]==[ Stack: EETmTmTRRSS------ ]