Scripting

1.) for the artists and designers who don''t know the programming language.

2.) to make changes and tweaks that do not require any compiling.

The Tyr project is here.

like Octdev sed it''s for developers who don''t knwo the programming language, it also makes things like maps(that may contain/be linked to scripts) more portable as the game it self may have had to be ported to another language/system, even though this is the case the scripting language it self won''t be changed.

this also makes things easier for modders etc...

u gotta remember that it''s a lot better to have as little hardcoded things like as possible, technically u shouldn''t have any, just the game and it''s engine itself to manage things liek events etc...

Chris

The artists and designers shouldn''t be messing with programming at all. That includes scripting. Also, who cares about compiling a few extra times, rather than going through the hassle of creating and implementing a scripting engine, and learning its syntax?

quote:

---

Original post by poisonfruitloops
like Octdev sed it''s for developers who don''t knwo the programming language, it also makes things like maps(that may contain/be linked to scripts) more portable as the game it self may have had to be ported to another language/system, even though this is the case the scripting language it self won''t be changed.

this also makes things easier for modders etc...

---

If developers don''t know the programming language, should they really be developers? I can see the portability advantage... but the modding aspect would be irrelevant in, say, an adventure game.

quote:

---

Original post by poisonfruitloops
u gotta remember that it''s a lot better to have as little hardcoded things like as possible, technically u shouldn''t have any, just the game and it''s engine itself to manage things liek events etc...

---

Why? The scripts would have to be compiled to bytecode anyway, if I''d want them to be fast. So they would be hardcoded as well. So what''s the difference in compiling c++ code and compiling custom script code?

A scripting language is one more level of abstraction above the game code. Sure, you can hard code in all those events and everything, but if you make a mistake, you''ve introduced a bug into game code. If you write a scripting language, the engine itself can have robust error checking, essentially making it impossible to crash the game or introduce unpredictable behavior. And the compiling issue is another thing. Why recompile every time you have a new level done.

---

Gamedev for learning.
libGDN for putting it all together.
An opensource, cross platform, cross API game development library.

Quote:

If developers don't know the programming language, should they really be developers? I can see the portability advantage... but the modding aspect would be irrelevant in, say, an adventure game.


true, i meant more along the lines of artists/designers etc..

i was basically trying to say what CpMan sed of course it's slower, but i guess i'd prefer to sacrifice some speed for robustness..

anyways thats just my opinon



[edited by - poisonfruitloops on April 6, 2003 6:54:36 AM]

We use script languages becaue programmers shouldnt be needed to write game *content* (dialogue scripts, triggers, weapons, monsters etc), thats the job of level designers etc.
With scripting you create your game, and then the content designers do the "rest".

As to your question regarding scripts also needing to be pre-compiled:
It shouldnt really be needed, because scripts only do very high level stuff(ie simple checks/comparisons and call native functions all other stuff), so it doesnt matter if they run slow or not. And anyway, compiling a script will be independent of recompiling the whole game code base.

quote:

---

Original post by CpMan
A scripting language is one more level of abstraction above the game code. Sure, you can hard code in all those events and everything, but if you make a mistake, you've introduced a bug into game code. If you write a scripting language, the engine itself can have robust error checking, essentially making it impossible to crash the game or introduce unpredictable behavior. And the compiling issue is another thing. Why recompile every time you have a new level done.

---

Hmm.. I can see the abstraction advantage, but not the bug-issue. You say that you can make it impossible to introduce unpredictable behavior. However... When I make a mistake in a script, I can either ignore the script or produce an error message. If I choose the first, the game does not do what it is supposed to do (spawn more enemies, etc). If I choose the latter, I get a nice error message. Both seem as bad to me as a bug in game code. Yet with a bug in game code, I can use all sorts of debugging tools such as watches and breakpoints to figure out what's wrong.

Also, the compiling issue... You'd have to compile the scripts to bytecode as well. What's the difference between compiling a .cpp file (you don't need to recompile the -entire- game, after all) and compiling a script file?

I see some advantages in scripting, but most just seem to be too much hassle for too little extra advantage.

[edited by - The Keymaster on April 6, 2003 7:15:12 AM]

actually u have a good point keymaster, i''m currently werkin on a script engine for a uni project, i''ll be keen to see how bugs in the script affects the actual game itself.

chances are i''ll post here for help


chris

I don''t think he has a good point.
Well it depends on the type of your project, resources and aims.
If you''re making something simple like Pacman or Tetris clone u certanly have no need for a scripting engine. If you don''t have time to develop a scripting engine see no real use for it u can do without it.
But any bigger project should have a scriting engine in it. There are a few reasons why I am for a scripting engine in most cases:

1. Scripting engine prolongens the life of project and aids its popularity.
Think about it, would Starcraft be as popular if it wasn''t for tons of user made maps, most of them heavily using Starcraft script or would Quake be around as long if it wasn''t for all of the mods which are only possible trough the scripting engine.

2. When logic behind a game gets very complicated like in adventures, RPGs or even RTSs it gets very hard to hardcode it and keep track of all the relationships. For the project I''m starting I have to develop an engine for implementing and applying all of the traffic rules. Imagine hardcoding it. I''d end up with huge branch structures crossreferencing to tons of flags. Instead I will probably go for a sort of a prolog like scritpting language with realions between rules and calls to engine procedures to apply the right rule.

3. Lets say you''re game is out and its some kind of a FPS. Now, loads of buyer are sending numerous complaints saying that they can''t get out of level 23 because there is to many water elementals coming out of the well and they don''t have a flame thrower. Designers say to u:"Right, make the rock next to the well unsteady so it falls off when you hit it with a grenade and makes the ground crack and molten lava comes poring out which evaporates the elementals."

You would make the changes(after you manage to find the right procedure for that level) recompile the game and ship off the new exe on a CD to all the buyers, or you could make a small change to the script and make a simple patch downloadable from ur website.

Choice is yours.

I find your first two points interesting. I can definately see the advantages there. However...

quote:

---

Original post by A Guy from CRO
You would make the changes(after you manage to find the right procedure for that level) recompile the game and ship off the new exe on a CD to all the buyers, or you could make a small change to the script and make a simple patch downloadable from ur website.

---

That''s not true: Why would I have to ship the exe on a cd? I could also just recompile the exe and post -that- on my website for download. It''s just one exe, not all that huge. Wether they download a patch with a new script or a patch with a new exe, it''s basically the same thing. No real advantage at all.

Anyway, I guess the two biggest advantages for scripting are data abstraction (as you said, most useful in RPG''s/Adventure games) and expansibility, for FPS/RTS games.

Don''t forget reusability. Code the engine, refine it, let it rest. All of the remaining work can be done with scripts, with possible minor additions made to the core engine. You can''t fail to see that this will speed up development time. You mentioned that artists don''t have any reason to be messing with code, but what if that "artist" on your RPG project happens to have 15+ years of P&P RPG experience and is intelligent enough to grasp scripting?

Anyway, you could have multiple games all designed around the same engine, with the scripts defining the behavior. If you code the scripting engine well enough you can hook everything down to the UI, like Dungeon Siege.

Care.

Florida, USA
RTS Engine in Development
http://www.knology.net/~heaven
Jesus is LORD!

quote:

---

Original post by The Keymaster
That''s not true: Why would I have to ship the exe on a cd? I could also just recompile the exe and post -that- on my website for download. It''s just one exe, not all that huge. Wether they download a patch with a new script or a patch with a new exe, it''s basically the same thing. No real advantage at all.

---

If ur entire game logic, all the levels and object behaviour is hardcoded into the exe it wouldn''t be such a small exe after all!!

I only read the first two posts. But I have to say I HATE hardcoding things. It makes the code less messy, but I guess that''s justme.

A lot of scripting uses microthreads, which lets your script do its own thing rather than deal with a loop cycle. For example, you might want your script to wait for 20 seconds and then do something. Script engine microthreads aren''t necessarily as much of a CPU burdon as a full thread. I made a script engine that used up to 30 such microthreads, and the overhead for them had no perceivable impact. With this and other benefits, scripting is often the way to go.

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy

It''s good to have if you want to have a moddable game. That way you don''t have to give modders your source, and they won''t have to compile etc. Unreal Tournament did this, and by God, that game has some great mods.

A scripting language would benefit the game buyers as well. The game buyer can tweak the game stuff and make sure his/her computer can run the game properly. If Counter-Strike didn''t have scripting i''d be entirely screwed because my computer isn''t a huge game playing machine. I think it''s a bit unfair to tell someone that if their machine isn''t good enough that they have to buy a new machine.

I also think scripting is good for games because it allows games to have a larger community. The mod community is very large with Half Life, UT, and Quake games and normally i thot game developers wanted huge communiies.

Also, wouldn''t it be a lot easier to go and fix scripts rather than having to go back and recompile all this code, debug, make sure it works properly and everything else?

*agrees with heaven*

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.