RE: [GD-Design] Scripting Engine and C++ Games

[Stewart L. <St...@cl...>]

I agree that FUBI is very platform specific, although I think it could be
implemented on any platform without too much trouble. In our case this
doesn't matter, but I can se how this would be a drawback for some games.

I also accept your argument that the api could become very messy and poorly
designed, it's almost too easy to export functions. We are taking measures
to avoid this such as extensive help documentation, but it's definitely
something I'll watch out for.

From a development point of view it is very useful having such a flexible
api, it's very easy to export a function and write a quick script to test
something, it has dramatically reduced C++ code pollution. So far it's been
only the programmers using the language and so the flexibility is really
useful. I'm interested to see what starts to happen when the designers start
pushing it.

Yes, by simplicity I did mean simplicity from the designers point of view,
the compiler and engine are definitely not simple. ;) The big difference is
that my scripting language was designed to make simple tasks simple to
implement. Our end user will never see the scripting language, and us
programmers will probably still mostly be using C++.

There's always a trade off between flexibility and rigid structure, so far
in our game flexibility has won outright, but we may have to nail things
down as the project starts to grow.

If I ever have to implement a more extensive scripting language I will
definitely consider your approach, thanks.

Stew.



-----Original Message-----
From: Kent Quirk [mailto:ken...@co...]
Sent: 12 July 2002 18:44
To: Stewart Lynch
Cc: gam...@li...
Subject: Re: [GD-Design] Scripting Engine and C++ Games


> I've implemented FUBI and so far I really like it, although it has yet to
be
> really stretched by the designers. I am interested in your approach, but
I'm
> not sure I follow exactly. Are you saying that you generated ICE interface
> classes from the C++ code and then the system shadowed the system objects
in
> the scripting engine? or have I got the wrong end of the stick.

The C++ code had a table of functions internally with additional
metadata. The C++ code could generate interface classes in ICE, that
were used by the ICE compiler.

At runtime, the C++ code manufactures functional ICE object code
(which calls the C++ functions) as a subclass (the ShadowSystemObject)
of the interface class.

Another benefit of this, by the way, is security. Our ICE compiler
will NEVER generate object code to escape into the C++ code. In fact, it
doesn't even know there's an instruction to do so. The only place that
instruction is ever inserted is in the ShadowSystemObject. The result
is that it's literally impossible to write code in our scripting
language that can do anything the game API doesn't explicitly permit,
which was important given that we intended to permit end users to
exchange running ICE code.


> Our script compiler doesn't know anything about the game api, it uses a
> .fubi file for the compilation of the scripts. The script engine also has
no
> knowledge of the game api, it just reads in the fubi file and that allows
> any of the exported C++ functions to be called from script. What I liked
> about FUBI was the way that it integrates the scripting language with the
> C++ game code without the script compiler or engine having to be coupled
to
> the game at all, but I'm always open to new ideas.

I guess my problem with FUBI is that it's very platform-specific and
even compiler-specific. Our approach with ICE has so far been ported to
Linux, Mac, and PC -- and code compiled on any one of them runs
without change on all of the others.

The other thing I dislike about it is that because of its functional
nature, it's my belief that it would tend to promote poorly designed
engine APIs. But I recognize that's more of a religious argument than
a technical one.

> We did look at a lot of the scripting languages out there, but still
decided
> to write our own because none of them met our specific needs, and as
someone
> else pointed out it is really important to take the end user of the
language
> into consideration. If the scripting language is for programmers lua or
> python might be fine, but if it is for non-programmers/designers something
> even more simple that's suited to the game might be needed. I don't see
much
> point in having a scripting language that is as complex as C++, the power
of
> a scripting language is that it should be a much higher level language
that
> simplifies tasks for creating the game. I think there's a real danger of
> scripting languages getting too complex and loosing their initial aim.
It'll
> be interesting to see how much of our game actually gets written in
script.

Yes, you've hit on a big part of the reason for ICE. We wanted a
language that end users could use. But we also wanted a language that
could support a robust, object-oriented coding style, because we
expected to write huge portions of our game in it. We shipped 40K
lines of ICE code as part of the game.

I do think you should think seriously about your programming language
design. You can design for simplicity, but just make sure it's the
right kind of simplicity. All too often, simplicity of implementation
is confused with simplicity of language design. There are a lot of bad
scripting languages around that were easy to write but are not so easy
to use.



-- 
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com