Scripting language

[Blake]

Also, constants arent scripting. Costs and stuff can be put into text files so users can readily edit them. Same with AI priorities and stuff. This does allow modding, but isn't scripting.
So it's possible to have a game, where users can add new weapons or units or whatever, and without a scripting language. (rather like Civ3)

Such a system is a lot easier to use and has less potentional for a user to screw things up. It can also work with a scripting language.

I have the idea of a compiled rules set that is a single file containing all the values for everything... well, not original, because Civ3 does that.

[Rasbelin]

I understand and second Blake's suggestion. Earlier text files were planned to be the only way to modification (like e.g. Civ II), but things have developed since that. However I have to admit that nothing beats such easy editing as Windows' Notepad for StP.

[Vultur]

Originally posted by Blake
Also, constants arent scripting. Costs and stuff can be put into text files so users can readily edit them. Same with AI priorities and stuff. This does allow modding, but isn't scripting.

Ok, but modifing these text files will allow cheating in MP.
My idea is to protect the file with one of two methods posted above:
Method 1
The Script and the TXT files are sended by the server to the client during MP sessions. During SP the game will use local files.
Method 2
The Script and the TXT files are on client HD but codified and the key to decipher is sended by the server. Obviusly there is also an un-coded version (on client HD) of Script & TXT to allow moddability and Open Sourcing

Scriping is more simple because you have not to recompile 100 times the program to find the solution.

Do you agree with me?

[Rasbelin]

Interesting solutions, Vultur.

Method 1
The Script and the TXT files are sended by the server to the client during MP sessions. During SP the game will use local files.

+ the player doesn't have to download any scripts or other configuration in advance, so it makes it easier to join
- could take some additional bandwith, but I doubt it would be that much (small files after all)

Method 2
The Script and the TXT files are on client HD but codified and the [u]key[/b] to decipher is sended by the server. Obviusly there is also an un-coded version (on client HD) of Script & TXT to allow moddability and Open Sourcing

+ the files are stored on the player's PC, so it becomes easier to check the files yourself and you don't have to upload the files from the server
- however you still need to get files on your own, so it's maybe not that easy for newbies or if there's many different mods available

If someone would ask for my opinion, I would say the first alternative in which the server sends the files as it's more beneficial for players as they don't have to fool around with too many files. But you can have many opinions about this.

[Leland]

Method 1 sounds more sensible too... after all, scripts and mods are game-specific and only need to be sent once per game, even if game consists of several sessions. As for encryption, I don't see it as a crucial feature... even if the ruleset isn't encrypted, it should be fairly easy to verify that it's either "standard" (since standard rules are always delivered with the game binaries), or at least fair (the client could warn if some players have advantages others don't have, for instance).

[Blake]

Compile the rules (whether they be txt or scripts) into the save game file, much like civ3.... nuff said.

If someone is silly enough to edit this file, all they'll achieve is oddities like stuff they ordered to be built, not building.

[Martin the Dane]

Why all this talk about cheating, if the turns are resolved on the server, any changes made by the client will have no effect on other players. It is easy to verify that the player do not send back a turnfile with the wron number of eg. ships as they only change while the game is being resolved. The only thing the user should send back is a set of orders, these schould offcause be generated by the client. But if the player changes them, he/she is only changing the orders, and since thy are not given until thy are sent to the server, that is not cheating.

Let's take an example: The player designs a new ship, equiping it with weaponds he does not have the technology for, because he have edited the localy stored rules. Since the edited rules are not sent to the server the undeveloped weapons will not be added to the ship, and the player will get a ussless ship.

As for maps, I will recomend that you look at the ones used by FreeCiv, they have a section for each player, only containing the information known to that player, so again here, changing the map will be pointless. The map is not transmitted to the server and a new "local" map is generated each turn for the player.

To limit the bandwith usage, it's only nececarry to transmit the changes to the game file back to the player, again editing the gamefile will only result in illegeal orders, taht can't be carried out.

Naturally the server keeps a copy of the full game-file as well as copies of each players game-file.

Now it becomes the players own problem wether or not he moddifies the game, as it has absolutely no effect on other players. It only makes it much harder for himself. Think of a spaceship-weapond haveing the description and gaphics of a shovel.
Or the other way arround, if player A modifies the local rules, so that the id for a unit or weapond, has much higher stats, than in the rules on the server. His game will now tell him that he can attack player B with eg. the ods 10 to 1 where the real ods might be 1 to 10. Who cheated who?

My conclusion is: Don't be affarid of scripting languages on the grounds of cheating, if the game is optimized for low bandwith it will automatically make cheating impossible through changing the script.

As for costumizing the goveners well, arn't they just suppost to limit the micro-management?

[Vultur]

If you think at PBEM games, to the server will be sended datas like pop, bases, credits etc.
So there are a lot of things that can be "cheated".
There can be a third method to have some security, that can discover script/TXT cheats, but not "correct" them.
It's possible to assign a "string" to each Official Mod that is a "function" of the variables wrote in the files.
Checking the variables stored in the HD with the Official Mod string sended by the server.
It could seem a bit complicated, but is more efficient than decipher/send TXTs.
More details later.

[Leland]

Originally posted by Vultur
If you think at PBEM games, to the server will be sended datas like pop, bases, credits etc.
So there are a lot of things that can be "cheated".

Uh, no. Quite the opposite: the server sends the clients all the data they need, something in the lines of "you have X credits and N bases. What do you want to do with them?", after which the client sends the host his orders. If the orders don't match what the server knows about the players' resources (for example, client tells to spend 1000 credits when the player only has 100), then the host will notice it and not carry out impossible orders. So there will be no chance to cheat... compare it to a email chess for example: if you send the guy who hosts the chess match moves that involve pieces you don't have, you don't magically gain those pieces, but rather your turn gets disqualified. This game is of course a lot more complex and involves quite a few more details than chess, but the principle should be pretty much the same.

There can be a third method to have some security, that can discover script/TXT cheats, but not "correct" them.
It's possible to assign a "string" to each Official Mod that is a "function" of the variables wrote in the files.
Checking the variables stored in the HD with the Official Mod string sended by the server.
It could seem a bit complicated, but is more efficient than decipher/send TXTs.

Actually, this is exactly what Blake and others mean when they talk about digital signatures... you don't actually have to encrypt the stuff sent between clients and host (that would be a bit of an overkill for a computer game), but rather you use a hash function on the binary-coded ruleset (or the text-coded, but it's more efficient and safer to use the binaries I figure), then encrypt that and use it as a signature. If someone changes the ruleset, the new signature calculated from it won't match with the one provided with the game (or downloaded from official Stella website, or whatever).

Not that I think this is necessary, since comparing the rulesets directly does the job just as well. But if you insist on using signatures, that's the way they work.

[Kuciwalker]

I agree that players should be able to used customized AI's (for the player), because they're not gaining or losing anything; they're just cutting down on their micromanagement.

[targon]

Correct me if I'm wrong, but this thread seems to diverse slightly from its original direction, namely scripting languages.
Concerning previous post, I agreed that client must be "dumb" and unaware of general game position, the only thing it really needs is current turn player data, so cheating will be fruitless and pointless.
Returning to original thread, I have one opinion about unit design in general. In most games, units are described using limited number of options, like HP, to-hit, attack strength etc. This is good, but IMHO, not enough for interesting game. Some units/weapons/techs/locations/etc. may have very specific properties (examples: some unit is specialized predator for other units regardless of its "actual" attack power; some units may hide completely while on some surface and stick up like idiots on other tiles; some tech may be useful only for some player faction/planet type combinations; ...). Traditional table-driven approach seems unsuitable for such a special cases, so here scripting may be _very_ helpful....

[Kurilka]

Yeah it looks cool.
But as the discussion flows we have more and more features
I don't say that this is wrong, but it's more work

[targon]

That exactly scripting languages are up to.
Listen, the main purpose of scripting is't adding some eye candy or mods; it's separation of core engine from features implementation. So, core group of developers may work on game engine undisturbed while others (including annoying persons like me ) may add and remove features 50 times a day. Core + scripting lang = insert any successful big program here.

[Kurilka]

Originally posted by targon
That exactly scripting languages are up to.

Yes, of course, my reply was not about scripting, but about the whole picture of the game...

[targon]

It's good. If your want game without much of "features" you may play tic-tac-toe.

[Rasbelin]

Hmmm... maybe we should make Stella Polaris into an OpenGL powered 3D tic-tac-toe game.

[targon]

OK, but make it without me

[Blake]

I can definitely see the merits of a SL. What about Lua with tuLua (tolua is a tool that greatly simplifies the integration of C/C++ code with Lua)

[Kurilka]

Seems good to me, but i'm not an expert (is there any in StPDT?)...

[targon]

OK, Lua is't worst script out there.
I may suggest you Guile, as it's good example of real rather than toy language, but I figured out its Scheme syntax (S-expressions that is) may terrify most of StPDT. It's pity, but I can't change the way of things: most people think they know programming while they actualy do't know any Lisp dialect.
So Lua may be used, it is't bad as is, but you should know that its "upvalues" are very downgraded variant of Lisp closures. In fact, Lua may be viewed as "Lisp for lazy", excuse me.
Python, on other hand, seems to be 1) successful language used in many successful projects 2) implementation rather than language in its own right 3) way to heavy in runtime and not much elegant in syntax.
New candidate languages for public dissection?

[Kurilka]

Tcl?

[targon]

Tcl? Just say No!

[Kurilka]

that was just an option,
maybe Perl ?

[targon]

Nice language, very _elegant_ syntax
It's sometimes hard to bind Perl to non-trivial applications, and it was designed for deals other than game logic.

[Kurilka]

Yeah, so i see almost just 2 alternatives:
1. Lua
2. Guile

there a mor languages(e.g. http://www.elasticworld.org/), but we'd better use something robust and wide-accepted
Lua is a bit simpler so I vote for it (it's not that I can't youse scheme, but it's better that "ordinary" user could use scripting)

[targon]

In fact, Guile and Scheme ist something so "unordinary", it's used in Gimp, for example. BTW, we may in fact use distinct langs for server or client side scripting, while it is't 100% good (but client scripts must be keept at clients side as security measure and server side scripts are simply pointless for client). I'm artist, not a coder, so while my personal preference is Guile (among other things it has true threading support, BTW) I know that most of burden of coding is on your shoulders so final selection is yours.

[Vultur]

Sorry, but I think I'm bit confused...
C++ (+ some scripting done from us) is not enough to code all the core?
I'm building a class to handle Menus: I know that it can be done using SDL routines, but I prefer use customized class to have a better graphic...
If there are libraries to do this things faster pls explain well all the features. An example: I've found 4 libraries to handle Zooming/Textures, but only one has a complete documentation with a stable code:SGE (can be found on SDL page)
It's totally useless propose dozen of programs known only by a people or two, only because "they look nice". It's a matter of time: no one can read all the documentation of all libraries, learn to use them and discover that they are totally "useless/obsolete/cannot do that thing I desire to add"...
Or not?
I suggest to Blake to post a topped closed thread where to put all the official libraries/programs used and their specific use.
Example:

Core: C++ & "Scripting language"
Graphic:SDL+SDL_image(for .png format)+SGE
Event handling:SDL
...

[targon]

C/C++ is enough for the core, but game itself is't just a core. We need some higher abstraction layer to explain game logic and other things. It's too boring to code all this stuff on C++.

According to image loading, did you try DevIL (Developer Image library), it integrates seamlessly with OpenGL. And that about making GUI via GL textures rather than ordinary blits, it's faster for modern cards and promotes good things like automagic scaling, blending etc.

[Kurilka]

And by the way didn't we agree that we will use OpenGL?
Shouldn't be there some voting?
And about scripting also.

[targon]

OpenGL and no voting. Game is meant to be cross-platform so forgot about DirectX and friends. I said about OpenGL for _menu_ system. It ist very common but some games seems to use it in that manner; at least, you will have consistent system and clean Z buffer. Bah, one more: do't forget about poor souls owning 3D goggles (it's cheap nowdays). 2D menu system with some 3D in background/main window/PiP looks _really_ wierd in that goggles.