quote:Original post by The Keymaster
I see most people''s points here, but what still eludes me is how recompiling, testing and debug is considered a burden scripting doesn''t suffer from. If you change a script, you''ll -also- have to recompile, test, an debug it.

Not necessarily. In my game engine, scripts can be changed without recompiling. They can even be changed while the game is running.

In short, embedded scripting allows me to prototype more quickly and gives me more power while building content. It''s not a requirement for every game, but it''s a great tool in any game where robust, extensible content is a requisite feature.

quote:Original post by The Keymaster
Since the bytecode is rather unwieldy and confusing, you''d have to write the script in a ''normal'' language, and then convert it to bytecode, e.g. compile.

Which is usually done transparently when the script is loaded in the interpreter.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

A game''s shelf life is prolonged by a strong online community, a straitforward, tailor-made programming language makes modding much easier, without forcing modders to rip the guts out of the engine figuring out how it works.

Anti-crack code can be embedded in vast game scripts (without calling an engines "anti-crack" functions), severely delaying the release of a sucessful pirate copy.

If the editing tools have simple short cuts for "if the player enters this area, spawn enemies back here" type stuff, level designers are less dependant on the programmers.

Inversely, programmers aren''t so much pestered by level designers for trivial "can you make this happen" tasks.

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

I think we can all agree that its generally bad style to have game data in the games code. You dont write C++ code for each and every piece of game data( i hope? ), be it a level, a 3d model, an image or other resources, you just program a simple way to load a resource into the game.
For example, you dont hardcode key-bindings, you put them in a text-file and load it at runtime. Basicly it would be unwielding to recompile the game in order to change the key bindings.
Similarily, you wouldnt want to reprogram warcraft III to use a custom map, would you?
Now, scripting takes this just one step further by factoring not only data itself but also code that is specific to a given piece of data (for example an AI script, or a map trigger for a specific quest etc ) out of the game.
With this improvement you can now add custom spells or monsters with new AI or abilities to an RPG without re-compiling the game.

If you wanted to do something similar without scripting you could of course resort to dynamic loaded libraries(or perhaps more elegant dynamic class loading in Java) to handle such additions,but these are not platform independent for example. Also it would again require that the people modifying what is almost game data(in that it "belongs" to a specific piece of resource data) would have to program in C++. This is harder for most people, and its also worth remembering that many script languages(&#106avascript/lua) include automatic garbage collection, which does make things simpler.

With lua or &#106avascript as scripting language even a webprogrammer can make considerable progress &#111;n the game without needing a programmer, and without even recompiling the game.<br><br>Im trying to make an RPG and ill be damned if im gonna write all the dialogue scripts myself/define all the items monsters etc, i dont have the creative talent for that. With easy scripting the more creative people can help the development.<br><br>Sorry if i was a bit unstructured/repeated myself a bit in the above, but thats the nature of a rant <img src="smile.gif" width=15 height=15 align=middle><br><br>

Keymaster,

I think you are missing an important fact about script engines... Scripting engines are easy to implement. It took me about 4 hours to have a working version of LUA integrated into my game after reading the LUA Doc. You don't have to design your own language and you don't have to create your own compiler. I find Lua to be very easy to learn and use. Of course there are other choices such as Python, but Lua is the most friendly and provides the best API for integrating with C functions (in my oppinion). After you have the script engine implemented it's a matter of exposing functions to the Lua environment using glue code, etc.

There are tons of other reasons for having a scripting environment that you might not have thought of. For example, the console of any game should be the front-end to a scripting language such as Lua. Otherwise you would be writing your own interpretter for commands that the user types in. It might as well be a scripting language that allows full control.

The biggest factor of all I think for using a scripting language is that it gives the game user a chance to modify the game. Without scripting you would have to compile DLL's or something to modify the game and most users don't have the tools or knowledge to create DLL's.

There are plenty of other reasons to use a scripting engine, but most of them have been touched on by other people in this thread.



--- COMPUTABILITY ---


[edited by - Computability on April 7, 2003 3:24:18 PM]

Possibly one of the most important aspects of scripting languages is the way they can make coding easier.

UnrealScript had inbuilt states for classes, it had garbage collection, latent functions, and tonnes of code features that were important to games. In the scripting language you could express these things easily, however to do the same thing in a language like c++ is much harder, more error prone and takes more time.

Scripting languages for games enable the game to be coded in its own terms, easing the coding and making a lot more possible in a given time.

It's like difference between writing code in Assembly and C++, which is easier to implement object oriented code in?

There are also all the other benifits people have mentioned, moddability, robustness, etc, but a major benifit is the ability to code game content with greater simplicity and in less time. This is a huge benifit in the industry where time/money and features are critical.

[edited by - Satook on April 8, 2003 1:41:54 AM]

Using a scripting language is simmilar to making a program data driven. Why not hardcode the coordinates for every polygon in all the models/levels etc into the exe? You use a scripting language for some of the same reasons you use external resources like map files, texture files, etc.

A scripting language is better than a general language because (if custom made) it is designed for a much narrower domain than a language like C++ and can leave out any and all features that don't make something easier.

If you design your scripting language well, you can edit scripts in realtime as you play the game (in development mode), so you can see changes very quickly.

It also allows locality so that code and data are near eachother and are isolated together. For example, a script to control a button in a level will be embedded in the level itsel rather than the main executable, and a good world editor might let you double click on the button to bring up the script window etc to make it easier to access.

Also, scripting languages are usually less complicated that more generic languages and are thus easier for non-programmers to learn. This allows level designers, modders, etc to modify your game more easily than if it was all hard coded.

[edited by - Extrarius on April 8, 2003 4:05:14 AM]