Implementing a Scripting language
Ron Hiler
Hi gang,
I'm about to start implementation on a level-designer for our engine. I
think it will use a scripting language to store the location and
behavior of objects in the world. This is, unfortunately, another one
of those areas I've never really played with before.
Although it doesn't seem like it should be too terribly difficult (hell,
compared with the 3D graphics routines, it looks almost trivial, hehe),
I'd like to take a look at any examples of scripting language
implementions that are floating around before I tackle it.
Anyone know of any good URLs?
Ron
--
So Brain, whatdya wanna do tonight?
Same thing we do every night, Pinky. Try to take over the world!
Steve McAndrewSmith
Ron Hiler (bnd...@pacbell.net) wrote:
: I'm about to start implementation on a level-designer for our engine. I
: think it will use a scripting language to store the location and
: behavior of objects in the world. This is, unfortunately, another one
: of those areas I've never really played with before.
You might want to checkout Tcl. It is (or, at least, was) intended as a
generic scpripting language, which could be linked as a library with any
executable. It provides for C->Tcl calls, Tcl->C calls, is fairly fast
(can be compiled to bytecode) and is free. There are versions for Mac,
Windows, and Unix (sadly, nothing for DOS, though I'm thinking of writing
a port).
If you're interested, checkout http://sunscript.sun.com for information
....
******************************************************************************
Steve McAndrewSmith EMAIL: ste...@niftytech.com
Drummer - Hacker - Minor Deity HTTP: //www.eecs.wsu.edu/~smcandre
------------------------------------------------------------------------------
You know you've been hacking too long when...
...you try to sleep, and think:
sleep(8 * 3600); /* sleep for 8 hours */
******************************************************************************
Niklas Konstenius
>Anyone know of any good URLs?
Try this exellent article on Gamasutra. Reallly interesting stuff.
http://www.gamasutra.com/features/programming/100397/languages1.htm
Niklas Konstenius
--
No .sig yet...
Andrew James Bednarz
Ron Hiler (bnd...@pacbell.net) wrote:
:
: I'm about to start implementation on a level-designer for our engine. I
: think it will use a scripting language to store the location and
: behavior of objects in the world. This is, unfortunately, another one
: of those areas I've never really played with before.
I'm implementing a simple scripting language for my platform
adventure game atm.. basically I parse text file and put all the data in
linked lists.. ie.. the script for an object made up of other objects might be
is working very well so far.. need to implement some script commands to handle
NPC's which'll be a bit trickier as they are more complicated than switches
and teleporting locations etc...
--
Bed
bed...@yallara.cs.rmit.edu.au
http://www.geocities.com/Hollywood/2430
"Loving you was like loving the dead" - Black No.1, Type O Negative
Thiadmer Riemersma
On Sun, 30 Nov 1997 18:51:53 -0800, Ron Hiler <bnd...@pacbell.net> wrote:
>I'm about to start implementation on a level-designer for our engine. I
>think it will use a scripting language to store the location and
>behavior of objects in the world. This is, unfortunately, another one
>of those areas I've never really played with before.
I am attempting to do something similar, based on the Small C compiler that
Dr. Dobb's published years ago. You can still find the source of Small C at
www.ddj.com, and you can get a CD-ROM from them (Dr. Dobb's) with the out-of
print book that thouroughly describes the design.
>Although it doesn't seem like it should be too terribly difficult (hell,
>compared with the 3D graphics routines, it looks almost trivial, hehe),
Do not underestimate the design and implementation of interpreters/compilers
(a compiler guru may find 3D graphics rather simple in concept).
Thiadmer
* * *
Note: My E-mail address has been altered to avoid spam.
Joshua J. Cantrell
% On Sun, 30 Nov 1997 18:51:53 -0800, Ron Hiler <bnd...@pacbell.net> wrote:
%
% >I'm about to start implementation on a level-designer for our engine. I
% >think it will use a scripting language to store the location and
% >behavior of objects in the world. This is, unfortunately, another one
% >of those areas I've never really played with before.
I'm taking a course in compiler design, and the hardest part about making
a compiler appears to be learning how to use the techniques that make it
easier to do, and the grunt work of error catching. :-)
% >Although it doesn't seem like it should be too terribly difficult (hell,
% >compared with the 3D graphics routines, it looks almost trivial, hehe),
If you don't know the techniques to make compiler writing easier, your
compiler might end up being messier (code wise) than it has to be, and
maybe not as flexible as it could have been (since you spent too much
time trying to make it simply work).
Joshua Cantrell
j...@cory.berkeley.edu
Ron Hiler
I really don't understand why everyone is making such a big deal (of
course, I haven't started implementation yet, so maybe I will find out
<grin>).
It's not like I'm about to write a whole compiler here (though I do see
the similarities). This script language will be for non-programmers,
and very simple. It won't be general at all, but will be very specific
for our game, so therefore it can have simple syntax and still be pretty
powerful (ie do what we want it to do).
The way I see it, there will be three parts
1) the Parser - scan the ASCII text. Big deal.
2) the Interpreter - compare the text against known words. If the
word is not known, give an error. If a known word is found, grab the
paramaters that go along with it. Check them for errors. If an error
is found, send it out. Otherwise store them in some mannor for the
compiler.
3) the Compiler - generate a file based on data given by the
interpreter in a format suitable for the game's use.
Seems pretty simple to me. Certainly not trivial, but nothing compared
to getting the 3D engine up and running.
I envision the language to be object based, with each object having a
set of paramaters, something like this:
OBJECT: Wall
LOCATION: 24,32,10
SIZE: 10,20,10
TEXTURE: 14
or somesuch. Of course, there could be optional parameters in there as
well, perhaps LINKED_TEXTURES (for mipmaps, perhaps), or ANIMATION,
stuff like that. The parser would pick up on the word "Wall", then
process the rest of the data based on that word. If it saw "Guard" for
instance, it would expect a totally different set of data.
So what do you think? Am I totally off base here?
Paul Miller
Ron Hiler wrote:
> Although it doesn't seem like it should be too terribly difficult (hell,
> compared with the 3D graphics routines, it looks almost trivial, hehe),
> I'd like to take a look at any examples of scripting language
> implementions that are floating around before I tackle it.
Check out Python - http://www.python.org
It's fast (compiles to byte code), free, easily embedded in C/C++
applications, easily extended with C/C++, powerful, object oriented,
much easier to read/understand than Perl or Tcl, etc. etc.
--
Paul Miller | st...@fxtech.com
Andrew James Bednarz
Ron Hiler (bnd...@pacbell.net) wrote:
: I envision the language to be object based, with each object having a
: set of paramaters, something like this:
: OBJECT: Wall
: LOCATION: 24,32,10
: SIZE: 10,20,10
: TEXTURE: 14
: or somesuch. Of course, there could be optional parameters in there as
: well, perhaps LINKED_TEXTURES (for mipmaps, perhaps), or ANIMATION,
: stuff like that. The parser would pick up on the word "Wall", then
: process the rest of the data based on that word. If it saw "Guard" for
: instance, it would expect a totally different set of data.
this is more or less what mine does... and it works beautifully
for what I need it to do. :)
Susan Peng
Do not underestimate the design and implementation of interpreters/compilers
> (a compiler guru may find 3D graphics rather simple in concept).
>
Yeah, Only the most evil kinds of math Are used in making compliers, programming
languages & just about everything in AI.
Jay Kint
I was reading some of the java newsgroups, and someone was integrating Java
into their program as a 'scripting' language. When it started, it created a
JVM and then loaded a class that it would call methods in as a way to extend
the application.
I'm not really sure how it was done (I didn't read the entire message since
I wasn't doing that yet, but since I may do it in the near future, I'd need
to go back to DejaNews). Java is fairly well supported, and there are many
JIT JVMs (how's that for acronyms :) coming out for the main microcomputer
platforms.
Jay
P.S. It's just a suggestion. I have no special love or hate of Java.
Mentioning Java is akin to mentioning OpenGL or Direct3D nowadays in this
newsgroup.
Ron Hiler
Jay Kint wrote:
>
> P.S. It's just a suggestion. I have no special love or hate of Java.
> Mentioning Java is akin to mentioning OpenGL or Direct3D nowadays in this
> newsgroup.
Mentioning just about anything on this NG is likely to get you into a
heated debate lately, it seems. I have never seen a NG so out of
control. There are definately some people here who need to take a pill
or something, and learn to mellow out. 125 messages today, 95% of them
the same boring crap as yesterday ("your're a jerk. No, you're an
idiot. I'm gonna call your employer. I'm gonna call my mommy. I'm
gonna call a lawyer!"). What a bunch of bullshit. It's too bad,
really, 'cause there are people here who are really trying to learn
stuff, and others with something genuinely useful to say, but they're
getting buried in all the BS going on around here. Sheesh.
Okay, done ranting about this dumb NG now :)
Joshua J. Cantrell
"Jay Kint" <j...@burgoyne.com> writes:
> I was reading some of the java newsgroups, and someone was integrating Java
> into their program as a 'scripting' language. When it started, it created a
> JVM and then loaded a class that it would call methods in as a way to extend
> the application.
This sounds feasible. The greatest reason to use Java is that the
programming of the compiler is more straightforward than for other
languages. The compiler, JVM, and other aspects of Java are also
well documented in books by SUN.
In a way, all you'd need is something to read and run the JVM and
just use a standard java compiler to do the initial compilation.
Joshua Cantrell
j...@cory.berkeley.edu
William Zero
>I was reading some of the java newsgroups, and someone was integrating Java
>into their program as a 'scripting' language. When it started, it created
a
>JVM and then loaded a class that it would call methods in as a way to
extend
>the application.
I don't like Java, I'd rather use VB. I don't know how to make your
application scriptable by Java, but I know make application scriptable by VB
use OLE Automation is not hard to do. Also Java is not a beginner's
langurage, hard to use by non-programmer.
John Hattan
"Jay Kint" <j...@burgoyne.com> wrote:
>I was reading some of the java newsgroups, and someone was integrating Java
>into their program as a 'scripting' language. When it started, it created a
>JVM and then loaded a class that it would call methods in as a way to extend
>the application.
If you want something similar to Java, but smaller and simpler to embed,
check out Dave Betz's Bob language. It's in the public domain, and the
source code is available on the DDJ web site. He's got a standalone
version and a DLL version that's designed to be used as an embedded
script language.
---
John Hattan High UberPopeness -The First Church of Shatnerology
The Code Zone Sweet Software for a Saturnine World
hat...@fastlane.net http://www.fastlane.net/~hattan/
Kalel
>Hi gang,
>
>I'm about to start implementation on a level-designer for our engine. I
>think it will use a scripting language to store the location and
>behavior of objects in the world. This is, unfortunately, another one
>of those areas I've never really played with before.
>
>Although it doesn't seem like it should be too terribly difficult (hell,
>compared with the 3D graphics routines, it looks almost trivial, hehe),
>I'd like to take a look at any examples of scripting language
>implementions that are floating around before I tackle it.
>
>Anyone know of any good URLs?
>
>Ron
I just finished doing this very same thing with "RETURN TO THE ABYSS",
the adventure game I'm writing for Sound Source Interactive. While I
agree that it is simple in concept, it turned out to be a real
hairball to implement. The tricks to watch out for are:
1. Try not to have a "source code" form if you can avoid
it. My language uses a line compiler, wherein the level designers
select actions from combo boxes and only have to type when they need a
function parameter. The rest is mouse driven. No source code to
lose, no way to screw up the syntax, no separate compile step, no
separate link step - all this is hidden from the level designers and
embedded in the World Builder.
2. Think about "transient objects" versus "persistent"
ones. Persistent objects are those in the player's inventory, or
objects that keep track of game conditions globally. If a door is
broken open on level one, and the player moves from level one to level
two and back again, the door should still be broken when he comes
back. If the player has picked up the Disruptor Beam with Optional
Phase Invertor, he should still have it when he progresses to the next
level.
3. Think about how scripts access resources. You will
probably need useage counts on resources so you don't load multiple
copies of the same thing over and over. This means you're probably
going to have to rewrite at least part of your resource manager, if
you're not starting this from scratch too.
4. Think about how you're going to debug your scripts.
Most scripting languages don't have any way of doing this. Mine
allows dumping status messages either to the gaming screen for
debugging scripts at runtime, or to a monochrome monitor or console
window for tracing command implementation internals.
Scripting languages touched damned near every single major subsystem
in your entire game engine in some way or other, and though the
language kernel itself may appear fairly elegant and straightforward,
its interaction with the rest of your system may be hideously complex.
From conceptual design to proof of concept, it took one man (me) about
five months. If you're just starting to work out your system
architecture you have an advantage: you can build language support
into your system now instead of retrofitting it later as I did, which
is lots harder.
Feel free to email me with more questions.
Gene Turnbow
Senior Programmer/Game Designer
Sound Source Interactive, Inc.
gtur...@ssiimail.com
Ron Hiler
> >Ron
>
> I just finished doing this very same thing with "RETURN TO THE ABYSS",
> the adventure game I'm writing for Sound Source Interactive. While I
> agree that it is simple in concept, it turned out to be a real
> hairball to implement. The tricks to watch out for are:
>
> 1. Try not to have a "source code" form if you can avoid
> it. My language uses a line compiler, wherein the level designers
> select actions from combo boxes and only have to type when they need a
> function parameter. The rest is mouse driven. No source code to
> lose, no way to screw up the syntax, no separate compile step, no
> separate link step - all this is hidden from the level designers and
> embedded in the World Builder.
Yeah, that's more or less the sort of thing I had in mind, though I want
the choices the designers make to come up as script in a window. Source
code was never in the plan, at least not entirely. It's going to be
basically mouse driven, with the coresponding script shown in a little
window off to the side. It will be there for "tweaks", like moving a
wall one or two pixels over after it's been placed with the mouse.
Other than that, I intend for the level designer not to have to "code"
at all (the person who will mainly be doing the levels doesn't know the
first thing about programming, hehe).
> 2. Think about "transient objects" versus "persistent"
> ones. Persistent objects are those in the player's inventory, or
> objects that keep track of game conditions globally. If a door is
> broken open on level one, and the player moves from level one to level
> two and back again, the door should still be broken when he comes
> back. If the player has picked up the Disruptor Beam with Optional
> Phase Invertor, he should still have it when he progresses to the next
> level.
Yeah, this is going to be tricky. I haven't figured out how to handle
it quite yet. We'll have to store the global conditions somehow, I
suppose, for each world area. Character inventory will be easier, I
think (I hope..).
> 3. Think about how scripts access resources. You will
> probably need useage counts on resources so you don't load multiple
> copies of the same thing over and over. This means you're probably
> going to have to rewrite at least part of your resource manager, if
> you're not starting this from scratch too.
Yes, I am going to put flags or somesuch tied to all the resources
(bitmaps, that sort of thing), saying whether they are loading in memory
or not. Can't have two of the same texture loaded :)
> 4. Think about how you're going to debug your scripts.
> Most scripting languages don't have any way of doing this. Mine
> allows dumping status messages either to the gaming screen for
> debugging scripts at runtime, or to a monochrome monitor or console
> window for tracing command implementation internals.
Well, what I *was* going to do was have an option for a fullscreen view
of the gameworld, essentially a mini-game within the level-builder, so
you could find bugs there, then flip back over to the level design area
and fix them (I don't yet know how feasable that is yet). I wasn't
planning on putting any real level debugging code in the game itself,
although I suppose I could.
What I really want to do is put everything the level-designer would need
to build a level in one program. A texture map editor, palette editor,
level design area, sound editor, object (3D mesh) editor, debug area,
etc., which would then be accessable through tabs at the top of the
screen. That way, they could just flip back and forth to design what
they need (e.g. designer working in the level design area, placing
walls, decides he needs a new texture, flips over, creates it, flips
back, the new texture is now available for use. That sort of thing).
Again, I don't know how feasable that is, but I'm hoping it'll work out
that way. (Jeez, put that way it sounds like a huge project, but a lot
of the code will come straight from the game engine itself, so it's not
as big a job as it sounds, hehe).
>
> Scripting languages touched damned near every single major subsystem
> in your entire game engine in some way or other, and though the
> language kernel itself may appear fairly elegant and straightforward,
> its interaction with the rest of your system may be hideously complex.
Yeah, I sort of expect that it will be. Eh, price of programming a
complex game like an RPG :)
> From conceptual design to proof of concept, it took one man (me) about
> five months. If you're just starting to work out your system
> architecture you have an advantage: you can build language support
> into your system now instead of retrofitting it later as I did, which
> is lots harder.
>
> Feel free to email me with more questions.
>
> Gene Turnbow
> Senior Programmer/Game Designer
> Sound Source Interactive, Inc.
> gtur...@ssiimail.com
Thanks a bunch for your comments Gene. They (and everyone else's) are
much appriciated.
Liam Phelan
hat...@fastlane.net (John Hattan) writes:
>"Jay Kint" <j...@burgoyne.com> wrote:
>If you want something similar to Java, but smaller and simpler to embed,
>check out Dave Betz's Bob language. It's in the public domain, and the
>source code is available on the DDJ web site. He's got a standalone
>version and a DLL version that's designed to be used as an embedded
>script language.
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.
Jan Kroken
li...@uow.edu.au (Liam Phelan) writes:
> hat...@fastlane.net (John Hattan) writes:
>
> >"Jay Kint" <j...@burgoyne.com> wrote:
>
> >If you want something similar to Java, but smaller and simpler to embed,
> >check out Dave Betz's Bob language. It's in the public domain, and the
> >source code is available on the DDJ web site. He's got a standalone
> >version and a DLL version that's designed to be used as an embedded
> >script language.
>
> 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. :)
Lex and yacc are definitively worth using. The only excuses for not
using lex is that you're not programming in C/C++ or that you're
using several parallell lexers in your program.
I don't know much about how to write things in yacc, but I guess
it's worth checking it out.
> 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.
That's the simplest way to do it. Use an array for data and another for
instruction. Translate variables into array indexes during compiling.
Simple as hell.
--
-jk
Wilbur Streett
I have a WIN32 port of Flex/BISON (AKA Lex/YACC) on my web site at
http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html
I've been getting about 10 downloads a week for the past 2 years, and I
haven't heard any complaints.. so I guess it's pretty stable. I've used it
for two projects, and it's worked pretty well..
Wilbur
William Zero
>This sounds feasible. The greatest reason to use Java is that the
>programming of the compiler is more straightforward than for other
>languages. The compiler, JVM, and other aspects of Java are also
>well documented in books by SUN.
But how to make application scriptable by Java, can you tell me?
Jason Hoffoss (Tclord)
On Thu, 04 Dec 1997 12:03:21 -0800, Ron Hiler <bnd...@pacbell.net>
wrote:
>I really don't understand why everyone is making such a big deal (of
>course, I haven't started implementation yet, so maybe I will find out
><grin>).
Isn't it always like that when you haven't really even thought about
it too much yet? And then when you try and get into it, you realize
how much more trouble it really is and can appreciate it. One of
those things you can always count on in programming. :)
>I envision the language to be object based, with each object having a
>set of paramaters, something like this:
>OBJECT: Wall
> LOCATION: 24,32,10
> SIZE: 10,20,10
> TEXTURE: 14
>or somesuch. Of course, there could be optional parameters in there as
>well, perhaps LINKED_TEXTURES (for mipmaps, perhaps), or ANIMATION,
>stuff like that. The parser would pick up on the word "Wall", then
>process the rest of the data based on that word. If it saw "Guard" for
>instance, it would expect a totally different set of data.
>
>So what do you think? Am I totally off base here?
No, but that's a pretty simple example, and if that's as complex as
you plan to get with it, then it should be pretty simple to implement.
However (speaking from experience here), if you give your designers a
language to mess with, they will try and squeeze more out of it than
you figured they would try to. Artists are like that too, actually.
You tell them the framerate is up, they will try and add more stuff if
and slow it down again. Consider this example:
Object: Wall
Location: 4 + (2 * 10), 8 * 4, 10
Size: 1*10, 2*10, 1*10
Texture: 14
Certainly might be easier on the designers to do something like this
so they don't have to have a calculator handy (depending on where they
get this data). And what about variables? They can give you a huge
amount of power to solve complex problems that are very hard to solve
otherwise. Making a language able to handle and deal with variables
makes things a lot more complex:
Location 4 + (x * 10), 8 * y, z
Size: xs*10, ys*10, zs*10
Texture: CurrentTexture
So, really it comes down to how much power you want this language to
have. The more power, the harder it is going to get to write it. If
you want it to not be much more than just a table of events or
something, it's pretty simple to write still.
-Jason
Jason Hoffoss (Tclord)
Do you have any really simple example programs to illustrate how one
uses it. Kind of like a tutorial. I've never been able to figure out
much about that anywhere, which is why I've never use it. Seems like
the learning curve is the real obsticle to using it for most people.
Maybe you could post it here and do a little news group tutorial
session and everyone can ask questions about what they don't
understand. Might be pretty cool. :)
-Jason
Wilbur Streett
hof...@volition-inc.com (Jason Hoffoss (Tclord)) wrote:
>Do you have any really simple example programs to illustrate how one
>uses it. Kind of like a tutorial. I've never been able to figure out
>much about that anywhere, which is why I've never use it. Seems like
>the learning curve is the real obsticle to using it for most people.
>Maybe you could post it here and do a little news group tutorial
>session and everyone can ask questions about what they don't
>understand. Might be pretty cool. :)
Sounds like a fun thing to do, but I don't think that I'd have the time
before Christmas to actually put together a tutorial. You can get answers
to a lot of questions about these sorts of things in the comp.compiler
newsgroup.
I'll be implementing a scripting lanaguage of my own shortly, so I'm
available to help a thread along, but I just don't have the time to work
out a full tutorial.. I don't have any really simple example code though,
I have written a MIB Compiler and an HTML parser with it. I've been
thinking about releasing the HTML parser, but that's part of a larger
system, and isn't a complete HTML parser, more of an <OBJECT> tag
manipulator, with a CGI wrapper to introduce session level into web pages..
I really recommend the O'Reilly book "Lex/YACC" written by John Levine,
it's a really simple introduction and covers quite a bit of the material in
the text. That's what I used to ease the learning curve. John Levine is
the moderator of the comp.compilers newsgroup.
You can find a compiler FAQ at
or
There are short on-line tutorials for lex and yacc at
http://www.ee.ic.ac.uk/course/advanced/intro.html.
Wilbur
Tess Snider
On Tue, 9 Dec 1997, Jason Hoffoss (Tclord) wrote:
> >I have a WIN32 port of Flex/BISON (AKA Lex/YACC) on my web site at
> >
> >http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html
> >
> >I've been getting about 10 downloads a week for the past 2 years, and I
> >haven't heard any complaints.. so I guess it's pretty stable. I've used it
> >for two projects, and it's worked pretty well..
>
> Do you have any really simple example programs to illustrate how one
> uses it. Kind of like a tutorial. I've never been able to figure out
> much about that anywhere, which is why I've never use it. Seems like
> the learning curve is the real obsticle to using it for most people.
> Maybe you could post it here and do a little news group tutorial
> session and everyone can ask questions about what they don't
> understand. Might be pretty cool. :)
We had to use Lex and Yacc in my compilers class back in school. I think
that we used the O'Reilly _Lex_and_Yacc_ book (the one with the two silly
looking birds on the front) to get a grasp on the tools, back then.
I don't have any *simple* examples on-hand, but I can give a quick
explanation of what the tools do, for those who don't know:
Lex enables you to set up a list of regular expressions, with associated
code. If you are using it to build a compiler, the code associated with
your regular expressions will output tokens, representing the source code
you are parsing. The tokens are then fed to Yacc. Yacc enables you to
set up a list of productions for your language grammar.
If you don't know what regular expressions or grammars are, it's time to
hit the books.
Hey, I saw that little (Tclord) in your name, dude. You a Tcl fan?
I had to use it quite a bit at my last job. A note of interest: one
of my colleagues recently embedded Tcl into the most recent version of
TinyMUSH to supplement the embedded language already available.
+--------------------------------+--------------------------------------------+
| Tess Snider | "Splendide mendax et in omne virgo |
| Software Engineer and Artist | Nobilis aevum." |
| mal...@radix.net | -- Horace, Of the Danaid Hypermestra |
+--------------------------------+--------------------------------------------+
Chris Palmer
In article <3490857c...@192.48.96.24>,
Jason Hoffoss (Tclord) <hof...@volition-inc.com> wrote about yacc:
>Do you have any really simple example programs to illustrate how one
>uses it. Kind of like a tutorial. I've never been able to figure out
>much about that anywhere, which is why I've never use it. Seems like
>the learning curve is the real obsticle to using it for most people.
>Maybe you could post it here and do a little news group tutorial
>session and everyone can ask questions about what they don't
>understand. Might be pretty cool. :)
There are a few simple examples in the gnu info pages that should be
distributed with Bison. The man page on unix for yacc lists a couple
of simple examples. For a sample scripting language, you might want to
look for ZMI. I have a reference to:
http://ourworld.compuserve.com/homepages/jussi/
Which is likely out of date. The yacc/bison source seems easy to
read and shows the translation from source language to an abstract
syntax tree. Not too abstract though...
Cheers,
Chris.
--
Mail: crpa...@undergrad.uwaterloo.ca
Homepage: http://www.undergrad.math.uwaterloo.ca/~crpalmer/
Michael Duffy
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
mdu...@studioblue.com