Sign in to follow this  
Gumgo

Best way to interprete scripts

Recommended Posts

Gumgo    968
For a game I'm making (or attempting to make), I've amazed myself and have actually written a very basic scripting system with some commands and the ability to add very basic functions. I don't actually know the "correct" way to make this, but I'm doing my best. Anyways... Currently the way I'm doing this is loading scripts into memory and reading until the first : (the : symbol represents the "end of a command", for example, ScrLoad:blah.txt|1) to find the command, and matching the resulting string to an enumeration in a std::map (so that it works with switch). Then to get my parameters, I have to apply several functions to get the different parts of the string in between the "|" symbols (like commas in C++). Often I have to convert the string to an int. So far there haven't been any speed issues at all but that's only because I haven't executed many many commands at once. I could easily see all the string converting and reading and weirdness slowing down the game in the future though, so I'm posting to ask, What is a better way of interpreting scripts? I'm planning (hopefully) in the end to write a quick program to change all the command names and such to things like "aa, ab, ac" just to make it so there is less to read, but I'm still a bit concerned. Is there a reason I should be concerned about this? Any tips on the topic? Thanks One thing that confuses me (somewhat) is that the game RuneScape is written in Java, which is interpreted. Then again, I suppose the server would be written in something else. [Edited by - Gumgo on May 6, 2007 3:49:33 PM]

Share this post


Link to post
Share on other sites
Spoonbender    1258
Couple of things here.
First, in interpreted languages, there's only so much you can do. You read code and data as strings, and you have to parse them. There aren't many magic tricks to work around that.

Second, there's interpreted, and then there's interpreted. In the old days, when Java was really slow, it was compiled to bytecode, which was then interpreted. That's a lot faster than interpreting the high-level language (it resembles a kind of assembly, and is equally simple to interpret)

That might be a good way to go if you want to both simplify your interpreter, and speed things up as well.

Third, these days, Java is JIT'ed (Just In Time compilation). So instead of generating a bunch of bytecode that your interpreter has to read when executing the program, you feed the bytecode to a small compiler embedded in the virtual machine. This compiles the bytecode to proper machine code, which can be executed directly. .NET does the same, and in both cases, it means performance very close to what you get with "old-fashioned" compiled languages.

Anyway, you might want to read up a bit on how compilers are implemented. There are a lot of similarities between compilers and interpreters, and it's a well-understood subject which means there exists clear procedures for How To Make A Compiler.


Oh, and finally, most likely, not that much scripting code will execute per second, so you may not experience any performance issues at all.

Share this post


Link to post
Share on other sites
Gumgo    968
Thanks for all the info, I'll look into it and do some research (one thing is I don't know a bit of assembly...)

Share this post


Link to post
Share on other sites
Sneftel    1788
A wise programmer does not implement a scripting language unless he absolutely has to. (Hint: You don't absolutely have to.) Instead, he uses one of the many languages which have already been written for him by people who know much, much more about writing languages than he does. A couple of these are Python and Lua.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this