scripting

What is the most common way to implement scripting in a general RTS game?
Development in C/C++. Is yacc/lex a good solution? python? make a
special-purpose recursive descent parser?

Andreas

On Thu, 13 Jan 2005, Andreas wrote:

> What is the most common way to implement scripting in a general RTS game?
> Development in C/C++. Is yacc/lex a good solution? python? make a
> special-purpose recursive descent parser?

In addition, what is the best way to make an "interpreter" for such a
scripting system?

In article <Pine.LNX.4.58.0501132232060.27771@tiger.stud.ntnu .no>,
=?ISO-8859-1?Q?Andreas_R=F8sdal?= <andrearo@stud.ntnu.no> wrote:
>What is the most common way to implement scripting in a general RTS game?
>Development in C/C++. Is yacc/lex a good solution? python? make a
>special-purpose recursive descent parser?

I'd recommend something like the Lua programming language (see
http://www.lua.org/ ) , as it's small, efficient, already used in a
lot of games, and integrates well with other languages that may be
used to do other parts of your game.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

nathan@visi.com (Nathan Mates) writes:
> In article <Pine.LNX.4.58.0501132232060.27771@tiger.stud.ntnu .no>,
> =?ISO-8859-1?Q?Andreas_R=F8sdal?= <andrearo@stud.ntnu.no> wrote:
> >What is the most common way to implement scripting in a general RTS game?
> >Development in C/C++. Is yacc/lex a good solution? python? make a
> >special-purpose recursive descent parser?
>
> I'd recommend something like the Lua programming language (see
> http://www.lua.org/ ) , as it's small, efficient, already used in a
> lot of games, and integrates well with other languages that may be
> used to do other parts of your game.

I would second that: use an existing scripting language/engine if possible.

Otherwise, if you just had to roll your own, then a special-purpose parser is
almost always better than a parser tool like yacc. The reason is that the
amount of work need to write your own is not actually much different from the
amount of work needed to specify a grammar file, especially if you consider
the glue code needed to integrate the generated code with the rest of your
program. Furthermore, it is much easier to code up special cases (e.g. custom
lookaheads) in a home-grown parser than in a tool like yacc with its builtin
context restrictions.

Plus in general with parser tools you need to track tool maintainance issues
as well like licensing, versioning, etc.

Parser tools are good for when you are afraid of writing parsers yourself,
since they will at least do it right.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

"Andreas Røsdal" <andrearo@stud.ntnu.no> wrote in message
news:Pine.LNX.4.58.0501132232060.27771@tiger.stud. ntnu.no...
> What is the most common way to implement scripting in a general RTS game?
> Development in C/C++. Is yacc/lex a good solution? python? make a
> special-purpose recursive descent parser?
>
ok, some prefer to use a general purpose language (python, lua, ...).
on one hand, one leverages what work has been allready done in that
language;
on the other hand, the language allready exists and thus what one can
implement is a little more constrained, and often at least the parts using
the language become a slave to the language...

as for lex/yacc, I don't know what exactly the major appeal is to them, imo
they often seem overkill for general script lang syntax, and I don't really
personally feel that compelled to use them...

thus, as from what I have seen recursive descent seems to be a fairly common
approach to parsing.
of course, the work of writing the parser depends on the language syntax,
eg, one with something like a lisp-style syntax is pretty easy, and a c
style syntax is much harder. lots of others fall between these, so one could
pick and choose if they wanted to come up with one they like, and vary
between the extremes of simplicity and complexity.


python and lua are common and well known and well developed.

I have a lang, however, it has basically no real user community and is still
not all that well developed.
however, it does feature a syntax that looks fairly close to javascript in
general though...

if you want to, you could look at or possibly even use my lang (it is LGPL).
http://sourceforge.net/projects/bgb-sys/
under the name of 'pdsys'.

here is a spec that sort of goes over a lot of the code in the "central
mass" as it were:
http://bgb-sys.sourceforge.net/pdlib.html


similarly, for actual game engine related stuff you could look at or use
code from lbxgl (located within pdsys) if you want, however, as a
forewarning this code is GPL (even if I haven't gone around and put the gpl
notice everywhere). one could use code from this, but I would recommend
asking me about it if they want to use the code under a different liscence.
for unmarked files it will usually be ok, however, some of the marked pieces
were not originally written by me, and are thus bound to being gpl.

the quake engine may also be worth looking at, but is pretty much entirely
GPL if that matters.


though I haven't put much real thought into it, the idea of an "abstracted
c-like syntax" is floating around. the idea is that basically the parser
would be divided up into a number of general pieces, and would thus itself
remain a fairly small piece of code. all the other parts of the syntax would
work basically by "patching into" the parser, effectively defining a path
from syntax->parse tree and possibly the inverse. one could also try to an
"ultra regular" syntax as well, however, sanely this would lead to some
divergence from c land...

STATEMENT=((<keyword> ['(' <ARGS> ')'] [<BLOCK>|<EXPR>])* | <EXPR>) ';'
BLOCK='{' <STATEMENT*> '}'
ARGS=<EXPR> [',' <ARGS>]

EXPR would be all the stuff for expression parsing.
an idea that comes up here is to try to generalize some, eg:
prefix, infix, and possibly postfix operators.
likely some will require special cases, eg, parens are a special case
(possible could be definition of "pairwise" prefix operators, eg, for a
given operator there is a matching pair that serves as a terminator).

adding a comma operator, then both ARGS, along with function call syntax,
could probably be simplified. ARGS would then just become EXPR, and function
calls would become essentially a blank operator.
these could have odd consequences, eg, parens are only needed when passing
multiple arguments, thus, eg, "sin PI" or similar becomes valid in most
cases.
similarly, array indexing would be a special case of the blank operator, so
'[' would become a pairwise operator. this could either not be
distinguished, be handled specially by the compile code, or '[' could
produce a special value. ...

leaf expressions would likely just be a set to have things added to it.

....

likely a parser of this sort would, however, be fairly straightforward and
general. this would look quite strange, however...


(crap, even posts I intend to be small get long...).

Andreas Rrsdal <andrearo@stud.ntnu.no> wrote in
news:Pine.LNX.4.58.0501132232060.27771@tiger.stud. ntnu.no:

> What is the most common way to implement scripting in a general
> RTS game? Development in C/C++. Is yacc/lex a good solution?
> python? make a special-purpose recursive descent parser?
>
No scripting, it's bit silly. If you have runtime compilation and
ability to recompile your AI rutines at runtime.
One of a ways is compile a buffer in memory then push the result into
Java VM, of course you are paing the cost of using multiple languages
in one project.
If you really need some scripting, roll your own. It's best it will
do just what you want and it would be extended as needed. Beware
scripting will get rid of safety nets of compilers. Java when you'd
compile a buffer would give you error report, so you'd get rid of
compile time errors. When scripts aren't script, but part of the
program, you could plug them into unit testing, or and throw in some
security methods. Plain scripting is prone to bugs, as I discovered
from playing of games, nasty hard to track bugs. Ever tried Gothic?
I think the best way is write a GUI program for "in game events" that
would give you some quality asurance, result would be stored in a
sometype of bytecode, or serialized form. Disadvantage of this
aproach is nobody would be able to edit that files with text editor.
Advantage of this aproach is NOBODY would be able to edit that files
with text editor (especialy at the last minute in a hurry).

>
>In addition, what is the best way to make an "interpreter" for
>such a scripting system?

Download Java virtual machine from java.com install it. Use it with
your program. Add script editors and debugging interface for you
program writen in Java.
Of course you didn't tell us for what do you want that scripting.

Game project on a Norway university? As a required part of study, or
for your free time?

In article <Xns95DEC639EBC4DRaghar@195.250.128.45>,
Raghar <notfor@mail.com> wrote:
>> What is the most common way to implement scripting in a general
>> RTS game? Development in C/C++. Is yacc/lex a good solution?
>> python? make a special-purpose recursive descent parser?

>No scripting, it's bit silly. If you have runtime compilation and
>ability to recompile your AI rutines at runtime.

I don't think the original poster is talking about doing the AI
routines as/in a scripting language. I think it's more in the sense of
in-mission scripting, much the way games like Starcraft have the
ability to play a voiceover, transfer units to your team, etc when
some objective is achieved. That's a perfectly worthy use of a
scripting language, as things triggered only by events cuts CPU usage
down a lot.

And, for such small things, using a lightweight language designed
specifically for scripting and coexistance with a main game is a
far better choice. Adding Lua to a game is really simple. Adding
Java (your suggestion) is a lot less.

Nathan Mates

--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

On Fri, 14 Jan 2005, Nathan Mates wrote:
> In article <Xns95DEC639EBC4DRaghar@195.250.128.45>,
> Raghar <notfor@mail.com> wrote:
> >> What is the most common way to implement scripting in a general
> >> RTS game? Development in C/C++. Is yacc/lex a good solution?
> >> python? make a special-purpose recursive descent parser?
>
> >No scripting, it's bit silly. If you have runtime compilation and
> >ability to recompile your AI rutines at runtime.
>
> I don't think the original poster is talking about doing the AI
> routines as/in a scripting language. I think it's more in the sense of
> in-mission scripting, much the way games like Starcraft have the
> ability to play a voiceover, transfer units to your team, etc when
> some objective is achieved.

Yes, exactly. Scripting like in Starcraft or C&C Red Alert is what I'm
interested in. Events in the game should trigger the scripting system,
then the scripting system should perform some logic operations to decide
which actions to take, and then somehow tell the game-code that it should
do.

However, the scripting system (the interaction between the game, the
scripting language, events etc++) for a complex RTS game this can be a
challenge to develop and maintain, I suspect. Therefore, I'd like to find out how the current games
most likely are designed in this area.

Andreas

Andreas Røsdal wrote:

> What is the most common way to implement scripting in a general RTS game?

I suspect one should follow two simple rules:

- whatever's slow migrates into C++ (and maybe a new algorithm)
- whatever changes often migrates into the scripts

So, new code that never runs afoul of those rules will simply remain where
it was born.

Here's an example of a game with a thick scripting layer:

> The latest title from the German Company "BlueByte" called "Settlers V"
> is about to be released. It consists of:

> - 500.000 LoC written in C++
> - 150.000 LoC written in LUA

> LUA is used for all the mission scripting and they are very happy with
> it since they started using it in Settlers IV. Settler V is one of the
> major PC gaming titles to hit the stores for this Christmas.

> Bernd

So, whether they followed that rule or not, it seems they got its results...

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

On Thu, 13 Jan 2005 22:34:30 +0100, Andreas Røsdal wrote:

> What is the most common way to implement scripting in a general RTS game?
> Development in C/C++. Is yacc/lex a good solution? python? make a
> special-purpose recursive descent parser?
>
> Andreas

I don't know much on this subject, and have only begun research on it. But
I'll tell you that there seems to be a few popular prebuilt scripting
languages popping up.

The ones are:
Scheme through Guile and other interpreters
Python
Perl
Lua
Ruby

I have not found much on Java, probably because it isn't used for this,
though I am not sure.

And, being one of the few programmers who likes scheme I'll recommend
you do scheme for the heck of it, cause i know no advantage/disadvantage
to any of these things anyway.

Percival