Article 162034 of rec.games.programmer:
Path: nntp.Stanford.EDU!Xenon.Stanford.EDU!amitp
From: amitp@Xenon.Stanford.EDU (Amit Patel)
Newsgroups: rec.games.programmer
Subject: Rule based languages
Date: 9 Dec 1997 22:15:22 GMT
Jay Kint <jay@burgoyne.com> wrote:
>Has anyone ever considered alternate types of programming languages for
>games? It seems that all games are procedurally written. Has anyone used a
>rule based or functional programming language for a game? These types of
>languages are great for AI (supposedly, I'm not an expert in that arena). I
>know LISP was used to write part of Abuse (using C primitives for graphics).
Given the current state of compilers for languages, I don't think an
entire commercial-quality high-end game can be written in an alternate
programming language, BUT I think that a lot of games could benefit
greatly from having a portion written in some alternate language.
You mention rule based languages .. I think this would be a great way
to set up a scripting language for a game. An RPG, for example, might
have rules like
Meeting[Noble,Thief] --> Steals[Thief,Random[Noble.contents]]
In my game (mostly environmental simulation so far), I might have
rules like:
Water > 0 AND Fire > 0 --> Fire := 0
Water > 10 AND Trees > 0 --> Trees := Trees-1
I think that these languages need to be small and specialized rather
than general purpose, so that (1) it's easy to write the things you
want specifically for your game, and (2) the language compiler can be
small, fast, and generate good code. One option could be to compile
to C[++], and then compile your C[++] code. For example, my rules
could be compiled into:
for(x=0; x<MAX_X; x++)
for(y=0; y<MAX_Y; y++)
{
if(water[x][y] > 0 && fire[x][y] > 0)
fire[x][y] = 0;
if(water[x][y] > 10 && trees[x][y] > 0)
trees[x][y] = trees[x][y]-1;
}
That way, you could get good run-time performance (both by getting
native code and by taking advantage of your compiler's optimizer), and
you could also have rules that are easy to read, write, and modify.
In fact, your message has convinced me to consider doing this. :-)
- Amit
Article 162177 of rec.games.programmer:
From: dave@see.sig.for.address (Dave Kirby)
Newsgroups: rec.games.programmer
Subject: Re: Rule based languages
Date: Wed, 10 Dec 1997 21:34:27 GMT
Jay Kint <jay@burgoyne.com> wrote:
>Has anyone ever considered alternate types of programming languages for
>games? It seems that all games are procedurally written. Has anyone used a
>rule based or functional programming language for a game? These types of
>languages are great for AI (supposedly, I'm not an expert in that arena). I
>know LISP was used to write part of Abuse (using C primitives for graphics).
I am currently working on the AI for a game and we are using a tiny
Prolog interpreter for the mission controller. This handles things
like deciding if a mission has been completed and if it was
successful, triggering special events, etc. This is work in progress,
so I can't tell you how successful it is (partly because its company
confidential, but mainly because I don't know yet).
We have a separate prolog compiler that reads a set of prolog rules
and compiles it into a set of bytecodes which is then loaded by the
main program and interpreted. The prolog can call predefined C
functions to interrogate the state of the game. The version of prolog
we use was written from scratch, but there are public domain prologs
out there that could be modified to the same purpose. there is also at
least one company (Amzil I think) that produces commercial embeded
prologs.
Although prolog is fine for the mission controller, which is only
executed every few seconds, it would be too inefficient for the main
game AI.
Dave K
________________________________________________
Communication is only possible between equals.
dave@ <-figure this out, spambots!-> Dave.Kirby@
dkirby. psygnosis.
demon. My opinions are my own, co.uk
co.uk but I'm willing to share.
Article 162509 of rec.games.programmer:
From: dave@see.sig.for.address (Dave Kirby)
Newsgroups: rec.games.programmer
Subject: Re: The BEST Programming Language
Date: Fri, 12 Dec 1997 21:00:21 GMT
On Thu, 11 Dec 1997 14:40:51 -0500, Michael Bennett
<Michael@TFX-Online.com> wrote:
>P.S. wrote:
>
>> Did you ever get sick and tired of all the bullshit that you had to do to
>> just produce a half decent program. All of the unneeded jargon and constant
>> repetitous code refering to the same commands? I hate all of that crap.
>> Tell me. As a question for discussion. What is the easiest AND most
>> versitile programming language out there. We are talking easy as in your 10
>> year old kid could be developing the next operating system with and
>> versitile in the sense that it could produce ANYTHING.
>>
>> Consider the options now...C, C++, Java, Perl, etc...
>
> Perl?
>Perl?
>HAHAHAHAHAHAHAHA!!
>
>making games in perl :)
I love Perl and use it a lot, but I don't write games IN it - I write
games WITH it. It is a superb language for text processing, and I
often use it for writing small support utilities, sometimes producing
in minutes something that would take a couple of hours in C or C++.
I also use it as an intermediate language, for example I define my own
language dedicated to a particular task, then write a translator in
Perl to convert from that language into a data file that can be
interpreted by the C or C++ program. I have done this for a fuzzy
logic system, a finite state machine system and various script
languages. I have found that this technique pays off time and time
again.
To answer the original question:
> What is the easiest AND most versitile programming language out there.
there isn't any, since these two goals are mutually exclusive. If a
language is easy to learn then it has to sacrifice power and
versatility. If a language is versatile then it will be difficult to
learn. C++ is the best general purpose language I know, but it is a
total bitch to learn, since it is so big and complex. I have been
using it for years, but I am still finding out new things about the
language or better ways of doing things. There is also no universal
language that is the best one for _everything_ - since a general
purpose language will be worse at a particular task than a language
that has been tailor made to do that job.
I recommend that anyone serious about programming should learn as many
languages as they can get their hands on, and try to learn as many
different kinds of languages as possible - OO, procedural,
logic-based, functional, list-processing etc. The language(s) you
learn mould the way you think about a problem. If you only ever learn
one language then your mind-set will be very limited and you will miss
solutions that would be obvious to a programmer in a different
language.
No doubt there will be posts in this thread that will argue that
Java/C/C++/VB/Whatever is THE best language and the only one you will
need to learn. I strongly suspect that people who post these do it
because that is the only language they know, and are deeply insecure
about it. Ignore them. The truth is that there is no BEST language,
but some languages are better than others _at_certain_tasks_ and worse
at other tasks. Learn many languages so that you can choose the best
tool for the job at hand.
Dave K [sick to death of all these language wars]
________________________________________________
Communication is only possible between equals.
dave@ <-figure this out, spambots!-> Dave.Kirby@
dkirby. psygnosis.
demon. My opinions are my own, co.uk
co.uk but I'm willing to share.
Article 162561 of rec.games.programmer:
From: Michael Duffy <mduffy@ionet.net>
Newsgroups: rec.games.programmer
Subject: Re: Implementing a Scripting language
Date: Sat, 13 Dec 1997 00:45:31 -0500
Organization: Studio Blue
Liam Phelan wrote:
> I was wondering if it is worth using Lex and Yacc to make a script complier.
> I found a site which has the C spec's for Lex and Yacc. Mail me if you want
> it and I will post it. I can't at present becasue I am not in my office. :)
>
> What I was thinking of, but don't know how to do it yet would be to use
> Lex and Yacc to generate op codes for a virtual CPU. The CPU would simply
> have commands like mov, jmp, cmp, add etc. Is it possible to use Lex and
> Yacc to do this, or am I barking up the wrong tree.
Egads, yes! I'm implementing an RPG with script support in it right now, and
I'm using the MS-DOS (I think) versions of Lex and Yacc for creation of the
script parsers. Once you learn the syntax, it is soooooooooo much easier than
writing the parsers on your own (I've done that too.) I do use my own parsers
for some of my script files, especially those that are parsed during the game,
as opposed to during setup/loading. This includes such things as conversation
"trees" which can be built on the fly, and which might not be entirely parsed
depending on where the user branches in the conversation.
The book I used to learn Lex and Yacc (errr... actually Flex and Bison) syntax
and use is "lex & yacc", published by O'Reilly & Associates, Inc. It's in the
UNIX Programming Tools series. I think it took me just under a week to really
get under way with Flex and Bison, though actually developing my parser(s) took
longer.
The way I'm using scripts is that my game uses several types of scripts.
Essentially, I have data definition scripts, and game code scripts. For the
data definition scripts, I just use Flex and Bison to create the data objects as
the script is parsed. Data definition scripts are used to define the attributes
for a character or object, define which sprites are used in a tileset, etc.
Note that the scripts are only used to input data into the game; this saves me
from having to write a graphical editor for entering the data (read, code
faster.) Once the data is in the game, I can (and do) store and use it in a
binary format. If I need to be able to change the data, then I need to instruct
the engine to re-parse the newly modified script.
For the game code scripts, I use Flex and Bison to create parse trees which I
then turn into a bytecode interpreted language. The scripts have a very C like
syntax, and I used those free C Flex and Bison templates to get my script parser
going. Since I'm familiar with Intel assembly, my bytecodes resemble a lot of
Intel instructions. I also have special bytecodes for doing things that could
be done with multiple bytecodes, but are done in real code instead since real
code will be a lot faster than the bytecode. Then I have a virtual stack
machine which runs the bytecodes.
For the language itself, I wound up implementing a lot of the C syntax, local
variables, function calls, #defines, etc. I still have to implement arrays,
#includes, and some other stuff. Don't try to implement all of C (or C++)
because you probably won't need it, and it would be wasted development time. I
am using a single size for variables (32 bits), and variables can hold either
data or pointers. Note that my scripts do no type checking whatsoever, so it is
up to the script writer not to screw things up. This makes the scripts more
prone to crashing (a lot more prone than regular C code I would suspect), but I
don't have the development time to devote to creating a full fledged compiler.
This is my first time at compiler writing, but I've managed to get everything
working like a charm (so far!) I know that my bytecode interpreter (virtual
CPU) could be a LOT faster, but I will cross that bridge when it comes time to
profile and optimize the final code. I also need to finish more of the game and
thus utilize scripts more before I can decide where scripts need to be made
faster.
Hope this helps!
Michael Duffy
Studio Blue
mduffy@studioblue.com
Article 165963 of rec.games.programmer:
From: Michael Duffy <mduffy@ionet.net>
Newsgroups: rec.games.programmer
Subject: Re: Scripts and AI in games...????
Date: Sat, 03 Jan 1998 16:12:47 -0500
Organization: Studio Blue
Greetings,
Well, I'm not working on a real time strategy game, but I have recently
implemented a script system in my RPG engine. So let's have a go at the
questions..... (^_^)
Vic wrote:
> Hello...there have been some threads about AI and scripting languages
> lately...So I started thinking about it...
> How should one do this? How can you make your game interact with the
> scripts and the scripts with the game?
Well, you need something to turn the text scripts into something your
computer can run. I wrote a parser that uses C-like syntax, and turns the
scripts into compiled bytecodes. Then I have a stack based virtual machine
(easy concept, difficult name) that I wrote to execute the bytecodes. I
used the lex/yacc (actually flex/bison) combination to create the parser
which generates a parse tree from the script. Then I turn the parse tree
into the byte codes.
> How do you control a guy with a script?
Each object in my engine can have one or more scripts associated with it.
When it comes time for the object to do something or react to something, I
pass the script name to the script engine, and if that script exists it is
called.
For example, if the object was touched, I call the "Touched" script with a
single parameter. In the text script file I have something like
script Touched
(
ULONG pvParametersIn
)
{
// C style code for handling the object being touched goes here.
}
The pvParametersIn variable is actually a pointer to a structure with all
the inputs to the script, but my engine only supports 4 byte unsigned longs
since it was quicker to implement that than trying to worry about type
casting and conversion. (It might open my scripts up to lots of hard to
find bugs though.)
Scripts can do calculations themselves, call other scripts, or call certain
functions that the engine has made available to the scripts. This way I can
perform processor intensive functions (path finding algorithms, graphics
functions, and the like) in compiled code, but control it all from scripts.
Scripts can access any data in the parent object through a generic
interface. By this I mean I store most of the object's data (statistic,
characteristics, etc.) in a continuous buffer of memory. Then the script
can get or set any info by calling certain routines and passing it the
offset into the block of data and the size of the data it is accessing.
> How modular do you make your game? Should you be able to add a
> completely new guy, with graphics etc? or just to modify the behaviour
> of currently available guys?
My system is designed to be flexible, so I want to be able to add entire new
characters without problems. Of course graphics, sounds, and other binary
data is stored in a binary format, not in a script. But I set up my game
engine to scan the current directory for all types of files that it knows,
then these are loaded in. Therefore all files with a *.scr ending are
parsed as scripts. Other files are parsed as graphics, or sound. Since the
graphics and other binary data has a text name associated with it, my
scripts can reference those separate graphic files. Therefore I can set my
game up so that any new characters' files simply need to be added to the
directory that is scanned for the character to be included in the game. Of
course your engine will have to be set up so it knows how to handle newly
added data (where to put it, how to make it accessable, how to use it, etc.)
> I know there are a lot of questions here :). I'd appreciate it if you
> (real time strategy gurus :) could answer at least some of my questions,
> or point me to more resources on the net about this.
> thanx :)
Hope this helps,
Michael Duffy
mduffy@ionet.net
Article 166000 of rec.games.programmer:
From: Michael Duffy <mduffy@ionet.net>
Newsgroups: rec.games.programmer
Subject: Re: Scripts and AI in games...????
Date: Sat, 03 Jan 1998 21:02:01 -0500
Organization: Studio Blue
Jason Hoffoss (Tclord) wrote:
> What I did with my language is make it so the script can call "system"
> functions. Since my language is quite similar to C, it works a lot
> like library functions in C, such as strcmp(), getch(), strcpy(), etc.
> You can pass variables into the system functions, and it can return a
> value back to your script. I also have this sort of alias thing like
> C++ has (though it works the opposite way.. You specify an alias in
> the function call rather than the function declaration). If you
> design your scripting language right, you should be able to expand it
> easily, adding more system functions or removing some, or changing
> what is passed to some, etc. I think it should work out great for
> what I'm doing.
How did you handle the actual calling of the system routines?
In my script language I specify templates for functions with one, two, three,
four, or five parameters. All parameters are unsigned longs, since that
parameter can also hold a 32 bit pointer. When I register a system (engine)
function, it must match one of the templates. Registered functions are
stored in a structure which holds a function pointer to the function, the
type of function (ie how many parameters), the name of the function in an
ASCIIZ string, and a hash value for making searching through the strings
faster. These structures are stored in a linked list.
When I have to make a call to an engine function, the script bytecodes store
the name of the function, it's hash value for quick lookup, and the number of
parameters on the stack. The actual call is made by searching through the
linked list for the correct function, then calling the function via the
function pointer and using the template according to the number of parameters
as stored in the structure. (You can compare the number of parameters in the
byte code and the function structure to make sure they match for error
checking.) Parameters can be passed back to the script either through
passing a pointer to the variable to change, or by a return value, since all
functions are defined to return an unsigned long.
Remember everyone: Post signal, not noise. (^_^)
Later,
Michael Duffy
mduffy@ionet.net