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

[Kent Q. <ken...@co...>]

> 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