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

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

Hello,

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.

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.

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.

thanks for sharing your method, I find it a really interesting topic.

Stew.


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


Given that everyone's talking about FUBI, I wanted to talk for a
minute about what we did with MindRover, because I think it's a really
good solution and quite a bit different in philosophy.

We built our own scripting language, ICE, which is semantically nearly
identical to Java (though the syntax looks more like BASIC).

By the way, I wouldn't recommend doing your own scripting language --
when we did it, 4 years ago, there wasn't much around that was robust
enough for game use. But now there are a lot of freely available
solutions for a language.

Anyway, the part I wanted to talk about was the interface to our core
code.

What we did was build a scripting language compiler that had NO
KNOWLEDGE of the API presented by the game. None at all.

The game's C++ engine could export functions to the API. The API was
chopped up into a set of classes we called SystemObjects. There was a
VehicleSystemObject, for example. You could (with a command line
switch) as the C++ engine to write the interface base classes in ICE
for all system objects, so we'd get a hunk of code that looked like:

'-------VehicleSystemObject------------
class VehicleSystemObject extends SystemObject

  function setEngine(speed as integer, vehID as integer) as boolean
    ' This is an interface with no functionality
  end function

  ...

end class
'-------VehicleSystemObject------------

When you compiled code for the game, you could use a
VehicleSystemObject. But the compiler only saw the interface class
shown above -- there was no functionality visible to the compiler.

The key was in the call to create a VehicleSystemObject. You didn't
just do:

 VehicleSystemObject vso = new VehicleSystemObject()

Instead, you'd have to ask the game system for one:

 VehicleSystemObject vso = system.loadVehicle("myvehicle")

What happened internally was that the system would manufacture a
ShadowVehicleSystemObject, which is a subclass of VehicleSystemObject
that actually had functionality, and return it.

The "system" object was passed in on the constructor of the class,
which is how the whole thing was bootstrapped.


What this all boiled down to was that we have a completely generic
external compiler that knows NOTHING about any game API. The game, in
turn, loads external code completely generically. There's one piece of
code that knows how to construct a class that the language system can
understand, and it simply operates on a table of functions set up in
the C++ code.

Changes to the API simply mean regenerating the base classes and
possibly recompiling external scripts that use them if the interfaces
have changed (we made the system robust across different versions of
class interfaces so we could release updates in the field without
forcing everyone to recompile everything).



One nice thing about this system is that it let us easily build a
standalone execution system for the language. We built a trivial API
that only provides the ability to log a few things to a file, but that
was enough to let us construct a rather significant (150 source files)
language compatibility test suite that's completely automated.
Whenever we make a change to the language we can run the suite and
make sure we haven't broken anything.


Anyway, it's a quite different philosophy than the FUBI stuff. I like
it because it keeps the game engine, the scripting language, and the
scripting API at arm's length, whereas FUBI tends to bind them all
rather closely, which can lead to maintenance issues down the road.

       Kent
       

Friday, July 12, 2002, 7:04:11 AM, you wrote:

> We from SwordLord.com are currently coding for a new game. This game
> should contain a scripting engine with the idea to help us to script many
> of the games features instead of hardcode them in c++. Also level
> designers could add to the games behaviour like that. (As more script in
> the game as happier I am ;))

> We are currently in the design and architecture phase of that scripting
> engine and would like to hear comments, suggestions, tips and read some
> good texts on that topic. Especially on the topic of how to knit the
> scripting and the c++ part together. How they both interact.

> Has any of you some experience on that topic and could help us with some
> tips or could supply us with a link to a good website or book?


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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556