Jump to content

  • Log In with Google      Sign In   
  • Create Account

AI architecture: core and scripting support


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 hawkeye_de   Members   -  Reputation: 197

Like
0Likes
Like

Posted 27 May 2013 - 10:51 AM

So, I'm currently in the process of creating a simulation and 'state of the art' technique is to provide also scripting-support to override unit behavior. I'd also see scripting as a possibility for prototyping AI behavior.

 

Since I plan to have different AI layers (at least strategic and tactical AI): is there any pattern for separating the core of the AI, which would be part of the framework and the scripting (e.g. Python) support? I've thought about it and it is not so easy IMO since I'm not so sure about the interaction model between the core and the scripting engine. My current very first implementation of the AI is that the actual units are agents (also crew members of units), which communicate via messages; thus they are decoupled from each other.

 

In a couple of simulations, the scripting support is weird: Sometimes the core takes over (regardless what you are doing in your script) since it gives certain actions a very high priority to ensure the consistency etc. but on the other hand this is completely in-transparent and error prone when you are developing scripts. Also, often you can only control the current unit (each unit is an instance of a script) but you cannot influence other units...this is usually done in the core AI, which limit considerably what you can do in the AI script.

 

So, maybe somebody has already some general experience on this topic, which he might wanna share. Or a good example of a game, which does do it well?

 

Thanks.


Edited by hawkeye_de, 27 May 2013 - 10:54 AM.


Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 15699

Like
2Likes
Like

Posted 27 May 2013 - 04:12 PM

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 :-)

#3 hawkeye_de   Members   -  Reputation: 197

Like
0Likes
Like

Posted 28 May 2013 - 12:00 AM

Thanks for your input!...I think I take a defensive approach for the time being and let scripts only do some specific micro-managing tasks e.g. functions for evading threads and that kind of stuff and see how this works out.



#4 wodinoneeye   Members   -  Reputation: 818

Like
0Likes
Like

Posted 28 May 2013 - 07:22 AM

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.


Edited by wodinoneeye, 28 May 2013 - 07:25 AM.

--------------------------------------------Ratings are Opinion, not Fact

#5 hawkeye_de   Members   -  Reputation: 197

Like
0Likes
Like

Posted 28 May 2013 - 10:55 AM

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#)


Edited by hawkeye_de, 28 May 2013 - 10:57 AM.


#6 wodinoneeye   Members   -  Reputation: 818

Like
0Likes
Like

Posted 06 June 2013 - 07:23 AM

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 )


Edited by wodinoneeye, 06 June 2013 - 07:32 AM.

--------------------------------------------Ratings are Opinion, not Fact




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS