Hi, I wondered how (much) scripting is used for AI tasks. So far I always coded several AI classes in the engine (soldier, vehicle, monster, player, etc.). That works fast and easy, but tweaking AI or adding new classes afterwards is impossible this way. So, now I'm using Python scripts. Each object/entity/character can make use of several script functions. These script functions can request pathfinding, spawn bullets, trigger sound, apply physics, and so on. Basically the behavior of every object is done via scripting. So far so good, and the engine is free from most of the game-specific code. However, I know that scripting is relative slow compared to hard-coded functions inside the engine. The real difficult stuff such as physics or pathfinding is still done inside the engine, but yet I'm somewhat afraid of over-using the scripts. For example, would it be wise to control 100 individual characters via a script? Each object calls its update function in the script several times per second (via a lower priority thread though) and practically every decission or event (damage, checkpoint reached, fire weapon, etc.) is done via script functions. I know other games use scripts as well (Farcry used LUA for example), but ussually they only have a relative small(~10) number of enemies active at the same time. Neither do I know what these scripts actually do... regulate and trigger everything, or only take some global decissions? Anyone with some experience here? I bet :) Greetings, Rick

From my experience, having hundreds of objects each with their own lua script is not an issue.

If possible, try to have it message based instead of calling an update every frame on every objects. I'm guessing your update will do nothing most of the time on most of those objects.

That sounds good. Most probably I don't have hundreds of objects, but I always have worst case scenario's in my mind. Most of the script calls or based on triggers. I can tell for each object which triggers and updates to use. So, a cola bottle or a rifle won't call these time-based updates at all. Updating for the more complex objects is meant for making random deccisions. Stop walking, or pick a new path, handle if a value reaches a certain level, etc.

I can't make a trigger for each value, since the properties of each object are variable as well. Props such as 'health' or 'ammo' are not used by the engine itself. The engine only saves and loads these values. That makes it a little bit hard to make a predefined trigger for, let's say, "health < 20%" or "danger level > 50". That's why smart objects also might need a time based update (I was thinking about 2 or 4 updates per second).

Thanks for the tip!
Rick

The nice thing about optimizing a scripting system is that you can do it late in the development process without extra difficulty. Don't worry about it until it actually becomes a problem.

Than I should just stop worrying :) I wanted to make sure I didn't count too much on a scripting system. You don't need to spit through the entire engine to optimize scripting indeed, unless everything actually depends on scripts. But from what I read here, I think I'm safe. Which is good news :)

By the way, is scripting common for shooter games like Crysis or Halflife? And how about RTS games? I guess AI is somewhat different there since large quantities are conrolled, but with group behavior instead of individual AI.

Thanks,
Rick

Python runs something like 20X slower than native compiled code, so it then depends what percentage of all the behavior processing is done in the script, versus how much is in the compiled support code (engine itself or game mechanism specific functions).

The more complex your simulations and what your behavior does with it, the more your scripting logic will have to do (though the ratio may stay the same meaning you will be running that much more in the high speed non-script code as well). Object decision logic that considers alot of situational factors (and
has to interpret alot of data returned from the generic game mechanics) if it gets bigger will take that much more CPU resource.

Most games have well choreographed situations with well selected start positions (enter stage left...) so dont need adaptive/versatile AI. Its much easier writing scripts only for a force situation of limited duration (exit stage right...). The player just isnt given much leeway to do unexpected things that the AI logic cant handle (its usually very obvious when a player does unexpect things).

Usually you can get a way with not running more comprehensive decision logic too frequently (animation sequences lasting good fractions of seconds allow you to skip doing heavy AI when the object is already locked into actions).
The more complex decision processing can be done in a round robin manner, say once a second (but only for a fraction of the objects each frame cycle). Low level reactivity is much simpler and would be able to be run each cycle (or in between primitive animation snippets).