Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
🔒 Locked
Making a Script Interpreter/Parser/Whatever
Advertisement
Original Post
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.
Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
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
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
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).
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).
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.
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."
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.
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.
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!
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!
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.
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.
Please excuse me now while I get the kick the sh*t out of this f**kin monitor.
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
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
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.
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.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement