Skip to main content
gamedev.net
🔒 Locked

Making a Script Interpreter/Parser/Whatever

Started by Exellon2000 Jan 6, 2002 at 5:51 PM 16 replies 5k views
Original Post
Exellon2000
Exellon2000
I am having trouble finding resources on the topic. I''m making a simple scripting language for my game and I have no idea where to start. I''m basing it on JScript and I can''t find any resources on making compilers, interpreters, etc.
Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
[small]:P I'll lick it if you lick it first :P[small]
S1CA
S1CA
search the web for LEX and YACC

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site
Brannon
Brannon
A really cool project that you might find interesting is LCC.

LCC is basically a C/C++ compiler front end. You write the back end that outputs the assembly/bytecode/machinecode. Carmack and co. used LCC as the compiler for the Quake3 VM. It spits out Q3 ASM (custom bytecode), and then he has a utility called q3asm that compiles the ASM to the custom bytecode. Parsing is slow and error prone (though YACC and FLEX are great tools for doing it). If you have the time to spend to use LCC and write a VM, do it!

Just my .02.

-Brannon
-Brannon
MiNDHiVE
MiNDHiVE
I think the whole point of his post was that he doesn''t know where to begin in writing his own interpreter or virtual machine... I''d like to see some information on this topic too to be honest.
http://www.deakin.edu.au/~bradleyj/unsanity/
Kippesoep
Kippesoep
Just for the record, I would like to state that writing a complete scripting engine from scratch is probably an awful waste of time. Writing a toy engine is, of course, a nice exercise and it''s nice to know you can . Any more than that, though, and you''re doing little more than reinventing the wheel yet again.

If you''re not doing this for personal satisfation, but actually want a usable engine, I would suggest using an existing engine. For J(ava)Script, there''s the rather good SpiderMonkey engine. It''s part of the Mozilla codebase (but can also be used stand-alone) and is licensed under the LGPL (which I prefer infinitely to the GPL).

Kippesoep
NickB
NickB
Another lexer/parser project to try is ANTLR - this is rather more sopisticated than Lex and Yacc - it''s quite easy to pick up - but like Kippesoep I might suggest that it''ll may not be justified in terms of time & that you might be able to find a ready-to-use script engine on the net somewhere.
Omaha
Omaha
This "reinventing the wheel" nonsense... There''s no substitute for experience, and when I''m sitting on the other side of that desk and the employer asks, "So, what have you been doing?" I''d like to say, "Oh, I developed a brisk scripting language and a virtual machine to interpret the generated code, and implemented it in this engine I developed over the past couple years." than "I downloaded this script code here and worked it into this other stuff I downloaded and cut/pasted into my project."
Jim_Ross
Jim_Ross
First things first. If you want to write an interpreted scripting language for your game you will not have to write a compiler of any sort. So lex, yacc, and antlr are out the door. Search for design patterns, there''s a pattern called the interpreter pattern which should suit your game just fine. Also consider using Python. Writing custom Python functions to hook into your game is as admirable as writing your own scripting language. At the very least it shows that you know when to use the right tool for the right job.
Exellon2000
Exellon2000
quote:
Original post by MiNDHiVE
I think the whole point of his post was that he doesn''t know where to begin in writing his own interpreter or virtual machine... I''d like to see some information on this topic too to be honest.


Yeah




Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
[small]:P I'll lick it if you lick it first :P[small]
Kippesoep
Kippesoep
Omaha, there''s something to be said for writing something yourself, to get experience. But when I interview somebody who wants to work for me as a programmer, I think it''s at least as important that they know how to integrate other people''s work with their own. This tells me they can work in a team and that they''re smart enough to save time and effort that can be better spent elsewhere.

Using an existing, proven technology or developing your own engine can make the difference between making a deadline and missing it by several months. (And it can save tens of thousands of dollars that I would have to pay to a programmer to do this job).

As I mentioned in my post: it''s a nice exercise to do it yourself (and the experience is valuable, of course), but it doesn''t make sense to do everything yourself if you ever want to complete a project in this increasingly hectic business...

If other people have done the work for you, take advantage of it!

Kippesoep
Exellon2000
Exellon2000
quote:
Original post by Jim_Ross
First things first. If you want to write an interpreted scripting language for your game you will not have to write a compiler of any sort. So lex, yacc, and antlr are out the door. Search for design patterns, there''s a pattern called the interpreter pattern which should suit your game just fine. Also consider using Python. Writing custom Python functions to hook into your game is as admirable as writing your own scripting language. At the very least it shows that you know when to use the right tool for the right job.


Reinventing the wheel is one of my favorite hobbies. That''s how I learn. I try to reinvent the wheel and I fail but in that time I learn some important stuff and then when I try again and fail I learn a little bit more. That''s how I learned to program. I definitely want to make my own scripting language. It''s not going to have classes. Maybe struct equivs. It''s main function will be to write AI routines and conditional config files and stuff like that. I probably should learn how to make an interpreter for a language that is similar to mine so I can learn how to write an interpreter and stuff.



Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
[small]:P I'll lick it if you lick it first :P[small]
Exellon2000
Exellon2000
I''m doing this game by myself.



Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
[small]:P I'll lick it if you lick it first :P[small]
Brannon
Brannon
The reason I posted about LCC is because parsing sucks, especially a language like C/C++. It sucks even if you are using LEX/YACC.

LCC does the parsing for you and gives you the output. Then you can do whatever you want with it. Save it as is, and interpret it later, or compile it to a bytecode and interpret that.

Maybe it''s just me, but writing a bytecode interpreter is far more interesting and something you''d practically have to do anyway (the state machine) if you were parsing and executing on the fly.

LCC is a good compromise between "reinventing the wheel" and using an existing solution. Someone else did the "common" work for you, and now you get to use that and customize it for your specific needs.




-Brannon
-Brannon
Minion
Minion
Hello.

There is actually a series on this over on flipCode in the tutorials section. It looks prettty good.

Minion
jacksonh
jacksonh
The tutorial on Flipcode is very good. It is on creating virtual machines instead of interpreting at runtime though.
Arakon
Arakon
I agree - the flipcode tutorial is very nice. Byte code is definitly the way to go. A long long time ago I made an interpreter for a BBS door game I was working on. I learned an awful lot about language design, and ended up switching to bytecode later just for the seperation and debugging.

For scripting needs though, I would highly suggest Lua. It has an active community, patches for cooperative multitasking, and it is -very- easy to integrate.
NickB
NickB
Weather you write your own compiler & bytecode engine or just write an interpreted script engine, you will still need at some stage to write & parser of some sort - unless you use a prewritten solution

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.