seems odd but every tut ive seen on scripting goes on about how to implement but not on why whys isnt this for every other tutorial anywho what is the point of a scripting lenguage thingymamob? why cant all this be contained within some file and then read upon start up/level load can someone plz tell me what im missing here? what is it that a script thing can do that there is need for so much complexity for it thanx in advance if anyone botheres to answer

so waht u mean is that its useful for others so that they have access to the engines things without the need to know ... bahh
but what i dont get is whats with all the complinig and turning it into byte code
why not just load it into something in the proggy
that way u wont get that slow down
why not that?

also what is the point of it if ure a one man team like me
and only do it for fun?

I don''t get that. Why should plain text be faster than compiled byte code? The text would have to be parsed over and over again, where bytecode tells the virtual machine in a computer friendly way what to do. Compilation only happens once (at build time of the script or at load time of the script,...). So you have to parse the text one time and can store all your stuff in a way that your programm can deal with it without doing a lot of additional work.

I think the two most important reasons for scripting languages are:

- they are Dynamic.
Meaning you can have the game running and change around code, without having to recompile. This speeds up development.
Scripting languages do not need to be fast. ie 90%/10% rule. where 90% of time is spent in 10% of your code. If something is too slow in the scripting language, rewrite it in a faster language.
- Scripting languages are usually easier to learn.
Especially if it is one of the allready known ones(eg python, lua, perl etc) where there are lots of docs/books on it allready.



-- Suffer in your jocks, dick head.

There''s only one book on Lua, as far as I know

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

argh noone seems to answer my question

VolkerG
my point was that id have some structs classes etc that handle everything
so why jnot just read in a text file and its all ready
no need to re read and re read
its in the code but not hard coded

but then annon says scripts can chagne at run time
but how can they if u have to recompile them ?

cmonn ppl

quote: Original post by Do00d
but then annon says scripts can chagne at run time
but how can they if u have to recompile them ?

Not compile, interpret.

Look it up on Google.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

I''m using scripting (with Python) in my project for the following reasons:

- Development time. For most tasks, it''s much faster to write something in a higher level language. If your game has a lot of game logic (by that I mean a lot of different enemies or objects to interact with), you''ll save a serious amount of time. Additionally, by having a language that''s closer to the problem domain than a general purpose language, you save even more time.

- Flexible. With a scripting language (at least the way I have mine set up) it''s easy to extend the system by adding a new script file. I can quickly change and tweak various bits of game logic on the fly, without rebuilding the project.

- Dynamic. If you do your game logic in C/C++, you pretty much have to decide ahead of time how that logic is going to work. As you said, you''d store all of that info in structures, which are then fairly static. With a scripting language, it''s easy to add custom behavior to any object in the system. For instance, in my editor, I can select an object and add some custom code to it, that will affect just that one object, not the entire class of objects.

There seems to be some confusion over compiling vs interpretting. Typically, a script file is interpretted. Most systems only read a file once, storing a tokenized version in memory for the next use. It *is* slower than native compiled code, but this is rarely a bottle neck.
Some games have used a scripting language which does need to be compiled. I think QuakeC worked that way, and a few games that chose Java as the scripting language. In my mind, this defeats some (but not all) of the benefits of using a scripting language.

If you have a very simple game, then it''s probably not worth it to worry about a scripting language. Otherwise, it''s definately worth the time.

Hope this helps.

Take care,
Bill

in-game scripting allows you to separate programmatic development of the game from design and implementation of that design. In a one man team, scripting probably is overkill. Where it adds value is in a large team with people that don''t have well developed programming skills. An in-game scripting language provides them with a more limited set of functionality (when compared to what C++ gives you) tailored specifically to their needs and the needs of the game itself. Scripting can make testing and tweaking game balance easier as well. I''d even go so far as to say storing easily modifiable game properties in text files that get read in during initialization is the most rudimentary form of scripting (such as a text file that defines player speed, weapon damage, player health, etc.) Expanding this analogy to why bytecode is preferable over text parsing is the same as storing this values in a struct or array instead of reading them from the text file every time you use that value in your code. It''s simply a speed issue.