Scripting

Ok, I see that it may take half a year before things we discuss here may find their use in actual code, but it seems separate scripting topic is nessessary. So far all issues concerning it have been scattered all over the board and I feel like gather them together.

There are several major questions we need to answer:

-Which language to choose?
So far two proposals have been given, namely Lua and Python and there are strong arguments for both of them.

-How to handle old ERM scripts?
Probably parsing the code is the easiest thing to do, what can be much worse is ‘fixing’ memory allocation which is pretty non-existent and makes them incompatibile as every scripter freely assigns his own variables to random from among limited ones.

-How to execute ERM scripts? Considered ptions are to handle directly withing game code or ‘convert’ them to scripts written in new language which will be the only one game actually processes. Since there are thousands of commands, better think twice before taking any actual steps.

I’m hoping to get some feedback from our new members who are familiar with ERM.

Is it necessary to choose one? SWIG seems like it could alleviate a lot of pain in implementing bindings, and it can do so for a large variety of languages. We could just make an interface for the variables and functions to be exported, and then have SWIG generate Python and Lua bindings.
It’s open source too. I don’t think there’s going to be any trouble with licenses.

Opensource hmm… but GPL? GPL needs incorporated parts to be GPL (with a few exceptions)

From what I see on their page it’s not GPL. It might be compatible with it, but the question is: does GPL allow GPL-compatible licenses, and is the SWIG license compatible?

SWIG uses a BSD license, so it’s GPL-compatible.

AFAIK it doesn’t matter anyway, since it’s the license of the SWIG code, not code generated by SWIG.

It will take probably even longer. Before starting actual work on script support I strongly want to have all significant parts of game mechanics working and quite stable.

I see only one “hard”, important issue with ERM handling (which will also affect other script languages of similar possibilities.
Should scripts be executed on the server on on the client?
Executing on client will allow fairly easy and practically unlimited cheating. It may also lead to desync problems or cause lags (depending whether script results will be applied first on the client or on the server).
Executing on server will be lagging and will create a lot of network bandwidth.

(We will probably have to think out some configurable hybrid solution.)
Unfortunately ERM interoperates heavily with GUI and user I/O on the one side and with game mechanics and state on the other.
ERM + Multiplayer = Problems :frowning:

maybe do a script parser for erm? I mean the program which ‘scans’ erm script and divides into two scripts (in lua or python) which first is gui only and the second is server only and communication is granted by additional code generated by the parser.

Is this possible? Is it hard to do? Is it wisely proposition? :unamused:

The issue is how to read this:
ERM
and end with something like this:
Lua (see H5 scripting manual for more)
Making this all affect original C++ engine.

I think most of functions should use the ones from GameCallback and similar. It’s pointless to translate inner memory management, synchronisation and client-server module as none of users is interested in that. They want to use simple, reliable and predictable commands and all technical details are hidden from them.
Well, as an experienced scripter I know what they need, the issue is to handle technical difficulties it in resonable way.

I like this tool.
The only problem is that we should support specific language as default. We can export VCMI to dozens of them, but what then? Scripts need to be organized and documented, not just present.

I`m afraid that using more than 1 scripting language could generate problems and some mess. I’d opt to choose one and stick to it.

As for ERM - well the best way would be to rewrite scripts from scratch. Simple parsing and translating to some other language would probably be possible but most probably ineffective. What I mean is that some things had to be done around in ERM to make up for some missing functionalities etc. Like storing variables in map squares variables because there are no arrays in ERM.

Other option would be to handle ERM as is but it’s well known that ERM is slow and takes up a lot of resources.

As for client-server issue - how about synchronizing the scripts that server and clients have running and in this way checking if they all have the same ones running when playing the game?

I’ve been thnking quite a lot of how to organize scripts in a flexible and effective way.

There are two possiblilities of changing game content:
-Mods are actually made of scripts. Every added or changed item of game is caused by specific script command.
-Scripts are embedded in main engine (for example inheriting / translating IGameCallback) and call original and already handled, not their own instructions. This ensures synchronizantion and maximum reliability.

I would defintely opt for Python. Its main advantages are:
-Explicit and powerful support for classes
-Popularity and continous development
-Large ready-to-use library
-Helpful community and amount of avaliable documentation

As to Lua, I suggested it mostly as language known from Heroes V. But now it appears obsolete and inferior.

Indeed, Python seems to be a better choice. I’d vote for it if we were picking a scripting language now but there is a lot of other tasks we should do before scripting support.

Nie mam doświadczenia w osadzaniu języków skryptowych, ale jest jeszcze coś takiego (chyba nawet używają tego w Might & Magic: The New Ordr mightnmagic.glt.pl/) :

angelcode.com/angelscript/

Składnia bardzo podobna do C/C++, więc powinno być proste dla wielu osób.

I jeszcze są siliniki javascript, np V8 (używany w google chrome) :

code.google.com/p/v8/

Damn, sorry, i didn’t realized that this topic was in English, so once again :stuck_out_tongue:

I don’t have experience in embedding scripting languages, but there are some more solutions, like:

angelcode.com/angelscript/

It has syntax very similar to C/C++, so it should be easy for many persons. AFAIK it’s used in Might Magic: The New Order mightnmagic.glt.pl

There are also engines for JavaScript, like V8 (which is used in Google chrome):

code.google.com/p/v8/

I’ve just played with SWIG and it failed as soon as found DLL_EXPORT macro. Probably this one can be fixed with some workaround, but it’s not a miraculous tool and wil require quite a lot of knowledge and effort.

So maybe you’re right, there are still some more urgent features to code :wink:

Ok, I made some progress. Actually created PythonHandler.dll file, which doesn’t make anything at the moment, but filling it with content is a matter of time. At least these two languages are now linked so C++ may use Python. Now it’s the time to do the opposite.

I think we should make a list of the functionality that should be provided to scripts. For starters, it would be good to be able to reproduce all the functionality of ERM-scripting. Then we could add other stuff to that.
A way to distinguish functions that change the game state and not might be needed to take into account. Only a script running on the server should be able to make such changes and when the client does this it either requests the server to do it, nothing happens or an error is presented.

I have another vision:

  1. Scripts extend / mimic behaviour of syncronous commands such like IGameCallback or combat functions (which I never touched btw). So they already have some kind of control and synchronization, using already existing NetPacks etc.
  2. They cannot be ‘typed’ into console but trigger only as a part of the mod or map script (such as ObjectHandler righ now). However as a next step I’m going to bind Python to console for testing purposes. Also, it may be enabled in singleplayer mode - proven to be very useful for mapmaking in H5.
  3. Mods are made of scripts. They need to be functions that add new content directly (creatures, artifacts, towns) when Python code is executed. Also, to make a mod it’s a good way to inherit / expand one of the basic class which will be also exported to Python. For example just edit the properties of new CCreature object, push_it_back and voila! new creature added.
  4. All scripts / mods / expansions need to be equal for all players, actually server forces to download and set-up them for all clients.
  5. ERM handler calls directly equivalent Python functions to make things consistent.

The main problem with scripting is that ERM support seems to conflict with cheat-proofness. When client can change gamestate in any way it wants, than we can prepare a modified version of VCMI that does not check if all clients run the same set of scripts and we can run a script that adds 100 archangels to our army every day. Server could, of course, check if commands like “add 100 archangels” make sense and reject doing this, but then every script that changes mechanics would need a “controller script” that adds a new action to list of actions that “make sense”. I think it makes scripting too complicated.

On the other hand we cannot let all scripts run on server, because some of them need a lot of information from client that are not in gamestate - like position of mouse (CM receiver). We cannot send position of mouse to server because the game would not be responsive when server is running on different machine.

It seems that we need 3 types of scripts: gamestate - changing that are running on server, non-intrusive that are running on client and unsafe that are running on client and modify gamestate. MP games could just ban unsafe scripts (that can be good for single player mode) and server will ignore all netpacks that are used by such scripts.

I think I’ve missed this post previously. I hope you know that we are far from having architecture that allows good implementation of scripts and all of your work on implementing script handling won’t be merged with trunk for months and even then will most probably be thrown away, so python - C++ bindings you do are just an exercise? We have already tried to implement scripts too early (map objects in Lua) and we failed.

Oh, don’t be so sceptical. Quite a lot of time passed since then and embedding scripts is just next logical step to move project forward. I can’t tell it will be finished soon or even in distant future as I’m just learning these, but it’s time to get down to scripts.