Scripting systems
by Peyton McCullough · in Technical Issues · 09/03/2003 (1:06 pm) · 6 replies
I notice many games and such use scripting systems. I am aiming to create a 2d MMORPG using Java ( applet ) and want to use a scripting system for everything. Any ideas on how to create one?
#2
If you only make certain kinds of scripts (like I am), it won't be as much work.
The advantage is that you can customize everything. The disadvantage is that you have to do the work yourself.
To save on the work, I just made it a simple list of text commands, one on each line. I made a simple gui-driven program to allow the user to type the script in.
09/04/2003 (6:12 pm)
I made a scripting system for the RPG I'm making in Java, but it's only for NPCs and signs.If you only make certain kinds of scripts (like I am), it won't be as much work.
The advantage is that you can customize everything. The disadvantage is that you have to do the work yourself.
To save on the work, I just made it a simple list of text commands, one on each line. I made a simple gui-driven program to allow the user to type the script in.
#3
09/04/2003 (7:13 pm)
Exactly, why use a pre-built one when you can customize one to your needs, eliminating overhead and such :S
#4
1. Because it saves you from reinventing all infrastructure common to scripting engines.
2. Because most scripting systems are accompanied by extensive libraries for common functionality such as file system and database access and so on, saving you from having to write these on your own.
3. Because scripting systems usually have excellent support for user extensions, such that no customization benefit accrues from rolling your own.
4. Because many scripting systems contain optimizations, such as intermediate forms for execution.
5. Because there are low overhead scripting systems such as Lua.
6. Because the popular scripting systems are battle-tested, have been used in hundreds of applications, including commercial games, so you can assume they work and cut out testing and debugging.
7. Because scripting systems typically have a consistent and well-thought out syntax (excluding Perl :P ) and efficient and highly optimized parsers.
In short, you'll burn a lot of time creating your own scripting system, and testing it, and debugging it, and end up with something that is feature poor, idiosyncratic, and probably far less efficient than existing systems. In short, you'll burn a lot of time to create something that isn't nearly as good as something you could have downloaded in a few minutes. Homegrown scripting languages are like goto statements -- they should be avoided except as a last resort. About the ony valid reason for doing such a thing is personal amusement. If you are absolutely determined to do this, look into JavaCC (I like JavaCC because it builds recursive descent parsers, which can be entered from any point in the syntax, whereas with shift-reduce parsers you must plan out your set of start terminal tokens) or the Java version of ANTLR.
Although with Steve's post I thought we might not be sharing definitions of scripting, which to me must include a general purpose language with all the usual control constructs. What Steve appears to be describing is a data language. If I just wanted a syntax for data specification, I'd use XML, since it is fairly semantically neutral, there are excellent parsers available (look at the Jakarta project), and it is fairly easy to cobble together data instantiation from the SAX or DOM API, or you can use JAXB to do most of heavy lifting of binding XML to Java. And XML is Web-friendly and has decent dedicated editors and support in many general editors.
The dollar cost is zero. The time cost to learn an existing system is orders of magnitude less than the time cost to create anything nearly as robust and comprehensive.
09/05/2003 (9:41 am)
Quote:
Exactly, why use a pre-built one when you can customize one to your needs, eliminating overhead and such :S
1. Because it saves you from reinventing all infrastructure common to scripting engines.
2. Because most scripting systems are accompanied by extensive libraries for common functionality such as file system and database access and so on, saving you from having to write these on your own.
3. Because scripting systems usually have excellent support for user extensions, such that no customization benefit accrues from rolling your own.
4. Because many scripting systems contain optimizations, such as intermediate forms for execution.
5. Because there are low overhead scripting systems such as Lua.
6. Because the popular scripting systems are battle-tested, have been used in hundreds of applications, including commercial games, so you can assume they work and cut out testing and debugging.
7. Because scripting systems typically have a consistent and well-thought out syntax (excluding Perl :P ) and efficient and highly optimized parsers.
In short, you'll burn a lot of time creating your own scripting system, and testing it, and debugging it, and end up with something that is feature poor, idiosyncratic, and probably far less efficient than existing systems. In short, you'll burn a lot of time to create something that isn't nearly as good as something you could have downloaded in a few minutes. Homegrown scripting languages are like goto statements -- they should be avoided except as a last resort. About the ony valid reason for doing such a thing is personal amusement. If you are absolutely determined to do this, look into JavaCC (I like JavaCC because it builds recursive descent parsers, which can be entered from any point in the syntax, whereas with shift-reduce parsers you must plan out your set of start terminal tokens) or the Java version of ANTLR.
Although with Steve's post I thought we might not be sharing definitions of scripting, which to me must include a general purpose language with all the usual control constructs. What Steve appears to be describing is a data language. If I just wanted a syntax for data specification, I'd use XML, since it is fairly semantically neutral, there are excellent parsers available (look at the Jakarta project), and it is fairly easy to cobble together data instantiation from the SAX or DOM API, or you can use JAXB to do most of heavy lifting of binding XML to Java. And XML is Web-friendly and has decent dedicated editors and support in many general editors.
The dollar cost is zero. The time cost to learn an existing system is orders of magnitude less than the time cost to create anything nearly as robust and comprehensive.
#5
09/05/2003 (11:55 am)
Still - I could be in control of everything and customize it for what I want, making it small, etc, etc.
#6
You have to decide if you want to trade power for ease of use. Compilers take away from the raw power of assembly, in return giving you a much easier development experience - which is important when you're working on larger projects.
If you're just doing straight-out NPC control and such, you don't need to write your own language; you can get along fine with Rhino or Jython or even embedded Java...
If you are doing something sufficiently clever, like Torque does with datablocks, then it might be worthwhile to look into writing your own interpreter... but it is a lot of work, especially to get that last 10% of usefulness.
09/05/2003 (12:54 pm)
Sure, but that's a lot of power.You have to decide if you want to trade power for ease of use. Compilers take away from the raw power of assembly, in return giving you a much easier development experience - which is important when you're working on larger projects.
If you're just doing straight-out NPC control and such, you don't need to write your own language; you can get along fine with Rhino or Jython or even embedded Java...
If you are doing something sufficiently clever, like Torque does with datablocks, then it might be worthwhile to look into writing your own interpreter... but it is a lot of work, especially to get that last 10% of usefulness.
Torque Owner Brad Shapcott
The longer answer is to use an existing extensible scripting framework. BSF for example.
Generally there is no advantage to creating a new language syntax unless you make application-level functionality part of the language. Rarely is that necessary.
The only other reason might be that you cannot find a suitable language that isn't encumbered with an unsuitable license. Rarely is that the case.
MMORPGs require fairly extensive server implementations. Your client implementation should be fairly thin. Javascript might be a better choice for the client side. You especially want to be performing most data access and downselecting server-side to reduce network load.