The AI will be complex but I have not decided yet, what complexity I put into scripting. For the time being it will be more like micromanaging the units in terms reacting to threats and that stuff...but I need experience. Also for weapons like missiles and torpedoes the AI could be completely written in scripts - since their behavior is not so complex like manned vessels.
I'm implementing the sim in .NET...so by using IronPython there would be no penalty concerning performance - since it uses the same runtime as my core (C#)
Micromanaging units ... will then depend what the units can do actionwise (including possibly cooperation or maybe simpler conflict avoidance of the units doing their own thing)
Torpedoes/drones/missiles they can have more behavior than simple ballistics.
One thing made clear when I did a state driven system with target priority selection etc script logic driven was :
That there can be definite phases of 'the turn' where distinct chunks of the current state run.
Sensor Phase - parameters cause processing of targets/objects_of_interest (range sets/filtering/etc..)
(this all takes place when the data is static so you can skip read/write locks) Much of this was parameterizing directives to the Unit core sensor logic (modes/ranges/object attribute filtering and even complex AND/OR evaluations) often with several different kinds of scans scheduled depending on the objects current state -- IE- when idle the object may look for many different 'opportunities' and when on a task much more narrow...
Action Selection Phase - Deciding which action is the best depending on what sensor data was collected (also continuation of already in progress action which may take several 'turns' to carry out - and possibly including interuptions of that action if needed/allowed)
This was where I included logic to check which objects were already busy and couldnt yet be interacted with - much of that is part of the object execution system, but directives to that could be controls by unique 'scripting'.
Action Initiation and Execution Phase - Initiate action (to game mechanics to carry out) and set object into waiting state.
For my simulation this also included animation scripting with delays and keyframe animations queued up so objects looked like they were doing things while the 'action' was in progress -- but because that was done by the scripting I could have abort points in the animation sequences.
It was very useful in my Macro driven scripting that the C macro definitions could mutate the State code specified in a clustered lump (coded together to keep them cohesive) with Phase1/Phase2/Phase3 prefix 'command' that would cause the Preprocessor to extract only the relevant part when each Phases Finite State Machine was compiled (largely a big switch/case for each phase). Otherwise the state code would have to be written in different files/locations and would be hard to understand/follow how they interrelated.
You could forseeably create a 'scripting' Wizard Tool which the use would use to Edit/Modify scripting and IT would put the chunks in the correct places for the 3 Phases of execution. If your scripting is simple then Wizard templates can help the player/game-maker create valid code (pulldowns with existing attribute names, If-Then tests composed of appropriate flag 'constants' or range values and test forms and useable functions, etc...
You would learn more about scripting by having to create such a wizard tool (and it would greatly improve the script generation process)
AND as I mentioned you want native code to be used if possible and the Wizard would carry out all the tedious parts of stitching its result into Native Code form (ie build a DLL or even all the classes for typical object oriented programming )