Scripting language

[Rasbelin]

Scripting languages are something content developers seem to want as that allows them to fool around with the game and also develop more customised scenarios and modification packs. Scripting languages are something that have been mentioned several times earlier, but I assume as Kurilka mentioned it now again, that we should finally decide about the subject. CtP and CtP2 are the two titles that are most closely related to StP as for the theme, but also the issue with scripting languages. So why to have a scripting language included?

Well, after all the game is open source so the source code is anyway available and it might cause trouble, but it's also an opportunity. The options, if we go for a scripting language, is that we only have a SL for event programming (triggers, etc.) or a full scale SL like in CtP/CtP2. Of course it would require additional work.

I'm in favour for an event scripting language as I can't see the full advantage of a full scale SL.

Here's a nice quote from Immortal Wombat's signature regarding scripting languages (this was regarding SL in Civ III).

"I don't believe in giving scripting languages because the only additional power they give users is the power to create bugs." - Mike Breitkreutz, Firaxis

[Kurilka]

As i'm quite new to this subject could anyone point me to resources about game scripting?

[targon]

SL in fact is't suff for users. It's for developers, scenario editors, designers and sometimes even for graphics artists (as _real_ 3D engines need some scripting for animations and so on). It's way of removing of five-time-a-day changing things like AI or unit properties from core engine. It's a way of simplification, as SL may be very specialized and attuned to game aspects. It's way of extension, as SL may be used for easy-to-install plugins, scenario etc. BTW, almost any successful game employs some script, so we are. Game iself may be "simply" some language interpreter exposing its specific aspects (as resolution control, path finding or unit creation) for developer who writes control routines ang game logic at high level. Common way of "sandboxes" may be used to prevent some ugly presons from cheating, while others may use they occational creativity for extending game without need of reading 2Mb of Doxygen docs or hacking code itself. SCripting divides problem into two distinct parts: 1) robust game engine; 2) extensive collection of scripts that glue things together and create gameplay.

[Joeno]

If I recall the old discussions well enough, I believe there weren't going to be any extensive scripting languages. The program is open source, and so you can program in major things, while things like building definitions will be done in a format Blake can tell you more about (mainly because I can't remember everything about it).

But anyway, I remember it being agreed on from early discussions that there won't be any large scripting languages implemented.

[Kurilka]

One question:
as our game is client-server - will be there scripting on client side? I don't see this useful except of cheating

[targon]

Your desire, but statistics is against complex enough games w/o scripting support. Read some things from Gamasutra or any other games devoloper site. Hack some successful games out there. You'll find lots of scripts, indeed.

[Kurilka]

"Your desire, but statistics is against complex enough games w/o scripting support." - was that for me?
I don't say "no" to scripting, but as i see it, client side is almost just for rendering and user input all logic will be on server

[targon]

OK, but if you hack some graphics-intense engine, say, Q3, you'll find a lot of scripts regarding interface, models, animation, shaders. It's also a good idea to use the same script for both client and servers, so they may easily interoperate and share some code. Game engine must support scripting from its roots, as it may be completely useless if implemented as bag on the side.

[Kurilka]

That's quite a different story i think, i don't see much of such stuff in StP type of the game. The most obvious part for me to be implemented in SL is AI, but... stop... customizing governor behaviour could be quite interesting...
So i raise my question once again:
where do you want to use scripting?
Concrete.
I propose AI, but that's also not a small question...

[targon]

BTW, advance in game development will force coders rethink their ignorance to scripts, as thousands did, so I think I need to stop advertizing and draw some nice graphics.

[Rasbelin]

Originally posted by Kurilka

where do you want to use scripting?

I would say the AI, event and other triggers and as we get into the subject abit more deep, I would say the weather system as that would allow creating very armageddon like conditions for some nice doomsday scenarios. As the unit values are set in the text files, it's not needed for that, but how about the combat system? Maybe it could be used there for something.

[Michiel]

It was my understanding that the game should be completely modable. Doesn't that require a scripting language? Also, I think scripting should be encouraged. (well, not cheating off course ) It gives the game a greater replay-value if you can change all kinds of aspects of the game, or download/share mods for it.

I don't know how to prevent cheating, but maybe there could be some procedure before starting a multi-player game that checks if all players are using the same mod/script. (Cheating is fine if everyone agrees to it.)

[Rasbelin]

Also, I think scripting should be encouraged.

Well, that could come into question, but the idea is that the game itself is that good you don't have to make scripts ofr having a good game. This isn't buggy ol' CtP.

Cheating is fine if everyone agrees to it.

Cheating is strongly discourage in any form as it creates more bad cheating too and any cheating scripts/mods can be easily used for negative effects too. Case closed.

[vovan]

Originally posted by Rasbelin
Cheating is strongly discourage in any form ...

I think it's a matter of definition. If we actually want to make a fully modable game, it will be hard to say what is cheating and what is not. After all, if the user can mod the game however he wants, it would really be hard to draw the line between "modding for fun" and cheating.

Besides, this also brings up a very important question. Since this game is going to be distributed under the GNU General Public License, as it is said to be on SourceForge, that means that we will be giving the players the source code together with the executables. Now, in multiplayer games, how are we going to ensure that the player has not modified the code to gain unfair advantage? If we are going to somehow compare the engine files or what not (by engine here I mean the game logic, of course, not the graphical engine), it would take a long time to intialize the game for one thing, and for another that would actually discourage modifying the code.

[Rasbelin]

That's why we 1. encourage to download the latest files from official sources that are listed on the website 2. as Blake earlier suggested, files would be digitally signed with a PGP signature. That would be the proof it's a validated file release by SPDT. I agree with you that we can't have it comparing the core code as that would be almost dumb.