Scripting AI...
Tiziano Lena
Hi to All!
I would like to make a (really) strategic game with Mechs. I loved the
article on Gamasutra about adding languages in game engines and my
dream is to write an AI based on scripts. I am now brainstorming so
any advice / url / anything will be really appreciated.
Thanks, Tiziano.
Joel Crisp
Hi
Ashley Fryer wrote:
>
> In article <3584eba8...@news.flashnet.it>, tlenat...@flashnet.it
> says...
> You should take a look at Lua. Lua is a language that was created
> specifically for embedding. It's lightweight, fast, clean, and free (
> source code and all ). A bunch of smart people have been working on it
> for quite a while, so be smart and take advantage of them. :-)
>
> http://www.tecgraf.puc-rio.br/lua/
>
> ashley
In addition to the comments from the others, consider JavaCC (parser generator)
as it has some advantages :- produces JAVA source output, recursive descent parsers
[bigger but faster than yacc style] very good diagnostics, AST node builder (builds
in memory representation of language while parsing with little effort on the part of
programmer)
Other embeddable langauges : Guile (scheme derivitive from GNU/FSF), TK/TCL, JAVA (don't
ignore this one - it's very good for dynamic knowledge representation and supports late
binding of classes so you can add new behaviour, e.g. unit types to the game easily),
EMACS lisp (had to add that one ;-), BASIC (yes, but easy for players to tinker with)
Another example of very simple but extremely effective scripting is Total Annihilation
- see the download of the map editor from Cavedog for more details.
More complex scripting is in Duke Nuk'em 3D - very interesting example.
Last but not least I have had some considerable sucess scripting mobiles in a MUG via
a simple condition:action pair scripting language (if all conditions are fullfilled, execute
action)
Joel Crisp
Java Consultant, SUN Microsystems
Opinions are my own, not those of my employer.
Mattias [remove spamguard] Fagerlund
>as to the article on gamasutra, it's a great source of inspiration, though
>there was one comment that was a bit misleading. herein the author claimed
>to have gotten a compiler up and running in a little over a day. it took a
>month for me to implement our games compiler, several other programmers i've
>spoke with have indicated it took them a similar amount of time. this was
>my first compiler, so of course i could do it again in less time - though i
>suspect i'll spend at least as much time w/ the next one i write because
>there will be so many other things i'll do.
A compiler in little over a day is impressive, if true. An interpreter
is no problem in 24 hours. That's a rather basic interpreter, but still.
Does scripting rule out interpreters? They're slower, no doubt,
but they're far easier to create.
Mattias
Christer Ericson
On Wed, 17 Jun 1998 13:51:08 +0200, "Mattias [remove spamguard] Fagerlund"
<ma...@spamguardacacia.se> wrote:
>[...]
>A compiler in little over a day is impressive, if true. An interpreter
>is no problem in 24 hours. That's a rather basic interpreter, but still.
If you know how to use tools such as 'yacc' and 'lex', you could
have a compiler up and running in however long it'll take you to
type your language grammar in plus some extra time to add the
semantic actions for your rules.
A tiny language (the size of a primitive desktop calculator) you
could do in well under an hour, so I see no reason to doubt that
you could do a moderately complex scripting language in just
over a day.
Christer
Neversoft
Dave Kirby
On Wed, 17 Jun 1998 09:44:35 +0100, Joel Crisp <joel....@uk.sun.com>
wrote:
[snip]
>
>In addition to the comments from the others, consider JavaCC (parser generator)
>as it has some advantages :- produces JAVA source output, recursive descent parsers
>[bigger but faster than yacc style] very good diagnostics, AST node builder (builds
>in memory representation of language while parsing with little effort on the part of
>programmer)
>
>Other embeddable langauges : Guile (scheme derivitive from GNU/FSF), TK/TCL, JAVA (don't
>ignore this one - it's very good for dynamic knowledge representation and supports late
>binding of classes so you can add new behaviour, e.g. unit types to the game easily),
>EMACS lisp (had to add that one ;-), BASIC (yes, but easy for players to tinker with)
You missed out Python - currently my favourite language. It is easily
embeded and extended and has been widely ported. Python syntax is very
simple and clean - it is one of the most readable languages I have
come across. Despite it its simplicity it is extremely powerful. It
supports full OOP, including multiple inheritance and operator
overloading. Unlike Java though it does not insist on OOP though - you
can still do procedural (and functional) programming.
There is also a version (JPython) implemented in Java that compiles
down to the JVM, so python and java code can be freely intermixed.
further information & downloads at http://www.python.org/
Dave K
---------------------------------------------------------------
Everything Is Deeply Intertwingled. (Ted Nelson, Computer Lib)
dkirby@ <-figure this out, spambots!-> Dave.Kirby@
bigfoot. My opinions are my own, psygnosis.
com but I'm willing to share. co.uk
Matt Kimberling
I mispoke - I spent a month implementing our scripting language - ie from
beginning to 98% bug free with a very rich feature set and semi-optimized
byte code generation.
Supposedly Carmack "whipped out" QuakeC in a short period of time, though I
dont recall any specifics - on the other handlookt at QuakeC - it's
terrible! UnrealScript, however, looks very impressive. Unless Tim Sweeney
had written object oriented languages before, It's hard to imagine that he
coded it in much less than a months time.
Matt Kimberling
Ashley Fryer
In article <35892576...@read.news.global.net.uk>,
dki...@see.sig.for.addr says...
>
> You missed out Python - currently my favourite language. It is easily
> embeded and extended and has been widely ported. Python syntax is very
I originally planned to use Python as my embedded scripting language
before turning to Lua. I read the Nutshell book, lurked the mailing list
for 4-5 months, downloaded the last 2 versions and wrote several Python
scripts. After all of that preparation, I abandoned Python for Lua.
Reasons I chose Lua over Python:
Lua is lighter. IIRC, basic Python compiled to ~500K versus ~100K for
Lua. Yes, some of the Python stuff can be ripped out if you don't need
it, but it's much easier if the stuff isn't there in the first place.
Lua is easier to embed. Python is more difficult to embed than Lua
because Python isn't _exclusively_ an embedded language. Python has
broad application, and it's better than Lua for many purposes, but it's
not easier to embed. Lua was designed from the ground up as an embedded
language, therefore it excels at embedding. I know that everyone always
says it's easy to embed, but it's just not as easy as Lua.
On the other hand, Python has many advantages over Lua:
Python is more object oriented.
Python has a vast collection of powerful support libraries ( FTP, HTTP,
.jpeg, etc. ), including a lot of networking code.
The Python crowd is very friendly and very supportive. They are cool
people to hang out with. Guido ( the author of Python ) is simply
amazing... he personally answers most questions that are posted.
So, bottom line, if you need what Python's got, go for it, but if you
want easy embedding, Lua's the right tool.
Regards,
ashley
Tiziano Lena
You all helped me a lot!!
Thank you very much...now I will be busy a month or two!
Greetings, Tiziano.
Mattias [remove spamguard] Fagerlund
>A tiny language (the size of a primitive desktop calculator) you
>could do in well under an hour, so I see no reason to doubt that
>you could do a moderately complex scripting language in just
>over a day.
When you say compiler, are you referring to a program
that compiles sourcecode to something that's executable?
Or are you referring to a tokenizer, that parses the sourcecode
and "re-writes" it into something that's easily executed by
an interpretator? (like VB used to do in the old days)
Because I can't see how you'd build a compiler (as the word's
usually used) by just specifying how the language is to be
interpreted? Unless yacc/lex contains the buildingblocks
a compiler needs?
Mattias
Peter Ashford
On Mon, 22 Jun 1998 11:10:47 +0200, "Mattias [remove spamguard]
Fagerlund" <ma...@spamguardacacia.se> wrote:
>>A tiny language (the size of a primitive desktop calculator) you
>>could do in well under an hour, so I see no reason to doubt that
>>you could do a moderately complex scripting language in just
>>over a day.
>
>
>When you say compiler, are you referring to a program
>that compiles sourcecode to something that's executable?
A compiler transforms it's input, 'compiling' it from one form to
another. It's output doesn't have to be an executable file.
>Or are you referring to a tokenizer, that parses the sourcecode
>and "re-writes" it into something that's easily executed by
>an interpretator? (like VB used to do in the old days)
What you are calling a 'tokenizer' _is_ a compiler.
>Because I can't see how you'd build a compiler (as the word's
>usually used) by just specifying how the language is to be
>interpreted? Unless yacc/lex contains the buildingblocks
>a compiler needs?
yacc/lex - or preferably bison/flex are all the tools neccessary to
write compilers. yacc = "Yet Another Compiler Compiler".
Peter.
Paul F. Snively
In article <35939b0b...@news.xtra.co.nz>,
kaff...@xtra.co.nz_DIE_SPAMMER_DIE (Peter Ashford) wrote:
>On Mon, 22 Jun 1998 11:10:47 +0200, "Mattias [remove spamguard]
>Fagerlund" <ma...@spamguardacacia.se> wrote:
>
>>>A tiny language (the size of a primitive desktop calculator) you
>>>could do in well under an hour, so I see no reason to doubt that
>>>you could do a moderately complex scripting language in just
>>>over a day.
>>
>>
>>When you say compiler, are you referring to a program
>>that compiles sourcecode to something that's executable?
>
>A compiler transforms it's input, 'compiling' it from one form to
>another. It's output doesn't have to be an executable file.
>
>>Or are you referring to a tokenizer, that parses the sourcecode
>>and "re-writes" it into something that's easily executed by
>>an interpretator? (like VB used to do in the old days)
>
>What you are calling a 'tokenizer' _is_ a compiler.
>
>>Because I can't see how you'd build a compiler (as the word's
>>usually used) by just specifying how the language is to be
>>interpreted? Unless yacc/lex contains the buildingblocks
>>a compiler needs?
Believe it or not, there is an approach to converting an interpreter to a
compiler: you need what's called a "self-applicable partial evaluator" for
target language T, and an interpreter I for source language S written in
language T. Applying partial evaluator P to itself with I as an input,
P(P(I)), produces a compiler from S -> T. Such partial evaluators are
available for Scheme, Standard ML, and most recently and probably most
interesting to most people, C.
>yacc/lex - or preferably bison/flex are all the tools neccessary to
>write compilers. yacc = "Yet Another Compiler Compiler".
This is categorically false, and the name has long been understood to be a
serious misnomer. yacc is a LALR(1) parser generator, no more, no less. Lex
is an OK lexical analyzer generator, no more, no less.
>Peter.
Paul
tel...@xenon.triode.net.au
In comp.ai.games Peter Ashford <kaff...@xtra.co.nz_DIE_SPAMMER_DIE> wrote:
> On Mon, 22 Jun 1998 11:10:47 +0200, "Mattias [remove spamguard]
> Fagerlund" <ma...@spamguardacacia.se> wrote:
> >>A tiny language (the size of a primitive desktop calculator) you
> >>could do in well under an hour, so I see no reason to doubt that
> >>you could do a moderately complex scripting language in just
> >>over a day.
> >
> >
> >When you say compiler, are you referring to a program
> >that compiles sourcecode to something that's executable?
> A compiler transforms it's input, 'compiling' it from one form to
> another. It's output doesn't have to be an executable file.
> >Or are you referring to a tokenizer, that parses the sourcecode
> >and "re-writes" it into something that's easily executed by
> >an interpretator? (like VB used to do in the old days)
> What you are calling a 'tokenizer' _is_ a compiler.
Kind of... have a look at the `guile' language or one of the
other scheme variants.
It reads it's input in plain text, converts it to lists which
are tokenised and work like normal memory linked lists but all of
the command pointers are already resolved (so it doesn't need to
do a lookup of each function name in a hash table at runtime, only
when loading up it's text files).
I wouldn't say it's blindingly fast but it is very flexible.
For those who remember Abuse, most of that was LISP code
(and you could modify the game by altering the LISP text files).
Am I repeating what has already been said?
- Tel
Mattias [remove spamguard] Fagerlund
>>When you say compiler, are you referring to a program
>>that compiles sourcecode to something that's executable?
>
>A compiler transforms it's input, 'compiling' it from one form to
>another. It's output doesn't have to be an executable file.
>
>>Or are you referring to a tokenizer, that parses the sourcecode
>>and "re-writes" it into something that's easily executed by
>>an interpretator? (like VB used to do in the old days)
>
>What you are calling a 'tokenizer' _is_ a compiler.
I suppose you're right, but that would mean Visual Basic 1-4
were compilers, which they were generally considered *not* to be
VB was said to be a tokenizer - it also needed an interpreter
to run.
Mattias
Amit Patel
"Mattias [remove spamguard] Fagerlund" <ma...@spamguardacacia.se> writes:
> I suppose you're right, but that would mean Visual Basic 1-4
> were compilers, which they were generally considered *not* to be
>
> VB was said to be a tokenizer - it also needed an interpreter
> to run.
All programs need an interpreter to run. It's just that many of them
run using an interpreter implemented in hardware. :-)
Amit
--
Amit J Patel, Computer Science Department, Stanford University
``Parkinson's Other Law: Perfection is achieved only
at the point of collapse.''
lennart...@uidesign.se
In article <w3667hf...@Ghoti.Stanford.EDU>,
Amit Patel <am...@Theory.Stanford.EDU> wrote:
>
> "Mattias [remove spamguard] Fagerlund" <ma...@spamguardacacia.se> writes:
>
> > VB was said to be a tokenizer - it also needed an interpreter
> > to run.
>
> All programs need an interpreter to run. It's just that many of them
> run using an interpreter implemented in hardware. :-)
>
> Amit
Hm.. guess this will be a long, off-topic thread :)
I guess the definition for a compiler is:
"... a program which translates a set of instructions ( a program ) in
one language into some other representation; typically the output of a
compiler is in the native binary language [...]"
A interpreter is
"A Program which reads instructions in a language ( a program ) and
decodes and acts on them ine at a time. [...]"
(From "lex & yacc", O'Reilly)
So, a lexer (scanner, tokenizer) is per definitionem a compiler -
since tokens (if provided together with a parse tree) are another
representation of the same set of instructions.
That would also mean, that a compiler front end is a compiler itself.
Same applies to the compiler back-end.
But I would never call VB4 a compiler... but that's maybe just a personal
problem :)
Lenny
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Kim Bruning
lennart...@uidesign.se heeft geschreven in bericht
<6nigv5$ucl$1...@nnrp1.dejanews.com>...
>In article <w3667hf...@Ghoti.Stanford.EDU>,
> Amit Patel <am...@Theory.Stanford.EDU> wrote:
>>
>> "Mattias [remove spamguard] Fagerlund" <ma...@spamguardacacia.se> writes:
>>
>> > VB was said to be a tokenizer - it also needed an interpreter
>> > to run.
>>
>> All programs need an interpreter to run. It's just that many of them
>> run using an interpreter implemented in hardware. :-)
>>
>> Amit
>
>Hm.. guess this will be a long, off-topic thread :)
<snip lots>
He's referring to a CPU, silly! :-)
Vriendelijke Groet,
Kim