I actually wrote a chapter for an AI book on exactly this subject, but sadly the book hasn't hit the shelves yet, or I'd recommend you pick up a copy :-)


The basic principle you want to follow is to choose a role for your scripts. I refer to the options as "master" or "servant" roles. In the Master role, scripts are used to determine what other AI mechanisms will be used to actually control agents. The Servant role uses scripts only as "glue" to achieve specific one-off behavior that other systems cannot provide.

It comes down a lot to the game design and the personalities of your actual script-writers to choose a good approach. A master script system typically works best when you have a lot of good AI components you can stitch together and choose from in various game scenarios; the master is basically in charge of deciding which concrete AI algorithms will be "turned on" to control various agents. This works nicely in RTS type games and beautifully in sandbox games.

Servant scripting is far more common, though, where you let generalized AI behavior do its thing 99% of the time and then use scripts for highly specialized routines or actions that can't be done in a generalized way. Storylines are often implemented this way, for instance.


The danger comes when you blend these two approaches. If your scripts can jump it at arbitrary times and do arbitrary things, it will become extremely confusing and hard to manage, as you noted. Generally speaking you want to confine scripts to managing either the "big picture" or the micro-details as much as possible.

(This is not to say you can't use both tricks in the same game, e.g. have a master script that occasionally delegates to servant scripts for story purposes, etc. The point is you need to keep the two very separate - even going as far as to provide entirely different scripting APIs or DSLs for each layer.)


The specific details again highly depend on what kind of game/simulation you want to make, and what kinds of possibilities you want to enable for design purposes. I will warn you now that creating a good scripting solution for "general purpose" simulation is a very, very sticky problem :-)

How complex is your 'script' ? (what data does it manipulate and what functions)

Sounded mainly was manipulating a Unit's own state, issuing action initiation for the unit , getting game (map?) situational data...

Python may be overkill (and pulling/pushing data/calls to your 'core' might be extensive code (plus python is notoriously slow).

As you would do in Python you would have high level calls calling native functions that do extensive data crunching (like sensor scan/sort).

---

Something I did a few years ago was to build a script language using C macros, C preprocessor to convert it to native C code and then quick compiling it into a DLL. The 'toolchain' would do all the conversion steps required with a single activation.

The macros allow you to pull game object attributes directly via the names in the core data structures ( via a string substitution in a C macro)

You can also build distinct named macros for specific Standard attributes and functions (which are obbvious in the script language what they do)

To limit what can be accessed, the generated C code can be forced to run within a DLL or class file for an allowed subset.of data access/calling

The macros can if needed be made to do any thing you could do in C for debug purposes without the extra mapping layer Python->Core

(logging macro turns on text trace so that the 'print method of debug can be done if all else fails, beside using the standard C debugger)

One of the AI Gem books had an article on implementing FSM using C macros for a tailored script 'language' with inbuilt FSM features (which gets rid of alot of ugly wrapper code structure FSMs need) and I incorporated that method also.

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 )