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.
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.
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:
server-side scripts with limited access to GUI actions
client-side scripts that have no access to data not visible by player and cannot influence game mechanics
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.