Scripting

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.

Don’t be so optimistic :). VCMI is definitely not ready for scripts. We still don’t have:

  • working Internet multiplayer - to test what happens when server is on different machine than client (and to see what problems it cause),
  • anti-cheating mechanisms - to don’t let scripts be used for cheating in multiplayer games, involves significant changes in the way that state of game is stored and modified,
  • better object support mechanisms - certain objects have the same functionality as buildings in towns, this duality has not been properly resolved,
  • an idea of script - AI interactions (I and Tow have a partial solution but it needs a lot of changes in current code)
  • stable codebase: we still add features and change the internals of already implemented features, so script handling would be an additional code to maintain while doing this.
    and maybe something I’ve forgotten.

Scripts will be a vital part of mod support. Scripts are why many players don’t like WoG for multiplayer games. We want script support to be as good as we can afford, so we want it to be implemented as late as possible - once it’s done people start writing scripts and expect us to maintain compatibility even if a certain feature occurs to be a design mistake. So I think it’s good to talk about scripts, brainstorm ideas and think about the perfect implementation of script support - but we should implement everything in proper order.

Some more ideas about scripts.

  1. Scripts should run on server side (at leasts they are loaded only by server, but UI related scripts could be transfered to client in order to increase performance ). All changes to game state are made by scripts on server side.

  2. To make VCMI “modding ready” most of game mechanics should be initially implemented with scripts (the rule is: anything that could be altered by script should be initially implemented with scripts).

Actually we were thinking about dividing scripts into three categories:

  1. server-side scripts with limited access to GUI actions
  2. client-side scripts that have no access to data not visible by player and cannot influence game mechanics
  3. client-side scripts with unlimited access to state of game and can influence game mechanics. These are supposed to be banned during online multiplayer games but could be useful for creating single player or hotseat maps or even online multiplayer games among people who trust each other. This category is needed because many of existing ERM scripts don’t fit first two categories.

It would be a nice-to-have feature but also impose a lot of additional work. We will start with more ERM-style scripting (that is, all mechanics is hardcoded and scripts can be executed between different actions).

I think that most of scripts could be (automatically) spitted into several parts (containing one or more whole triggers) that fit into categories 1 & 2 (depending on receivers in each trigger)

I agree or don’t, depending on what we understand by splitting and if we are concerned by security and responsiveness. Yes, it can be split if we allow communication between server-side scripts and client-side scripts. But this solution is insecure and quite slow. I really doubt there is a solution that fixes these problems without introducing the third kind of scripts. Actually any script that grabs user input (mouse position, keyboard strokes) and influences game mechanics (or accesses information that should be available to player) can’t be easily split.