Scripting flexibility - how far?

[nonickch]

I was pondering today if I'll have a go at scripting for this game.

From a quick overview I had of the tool and the xml files it seems that mission design is quite straightforward but on the other hand somewhat limited.

I believe the lack of mission variety and static AI behaviour (move there, do that, always) is indicative of that shortcoming.

So it got me thinking the first thing that needs to be done is a series of scripting packages that give some element of "intelligence" for usage from mission designers.

For example, incorporating some basic tactics vs the now wave after wave approach the computer is employing.

Encirclement, flanking and breakthroughs are statically bound to areas and not to your units from the looks of it.

Usage of cover from the AI is almost non-existant again, apart from pre-scripted movements that usually land the hostile forces making a dash and then sitting still at the edge of the map.

It would be nice if it was possible to work on a level of abstraction higher than a few pre-designated areas and and checking for num of hostiles units in that block.

Since I am lazy and I don't want to spend a week of mine looking into something that most likely will proove not viable, I have to ask the wiser:

Is it possible for artificially covering for the AI by extensive scripting?

I know that tackling AI issues are suicide in a scripting language, but how far can one reach in the current state of the scripting language?

Are there chances of an enhanced ver of the script language?

How CPU intensive will it proove if one blows up the script size by say, 10-50 times (and processing time)in order to approximate some functionality that is otherwise unavailable? (for example grid the entire map into 100x100 and perform numerous calculations for flanking ability and possible covered routes)

[PFMM]

In my opion I think you're diving in too deep.

The first step you should make is a logical plan that can be coded in small steps based on small elements. Once you've done that, ask yourself how each element will respond to a threat and come up with codeable procedure.

If you're not exhausted by now you might consider the supporting relationships between each of the elements.

In short, not really.

[Webwing]

Actually scripting makes the AI more "intelligent" than the tactical AI found in CM. But its a trade off, the burden of planning the tactics is with the designer.

But you don't even need "extensive scripting" to achieve what you intend. With the tools at hand you can have varied and very complex opponent behavior.

The script itself doesn't do anything much different than a human player would do. Like if he sees x number of troops approaching from one side he will then do this and that.

You send a scout to check for the enemy in the area. You move your troops to one side, etc.

Most everything you do while playing you can script the AI to do as well. Plus there is the randomness that you can program to add some replayability to the mission.

But yes, it takes time to do it. I see it as a game in itself. And a lot of fun.

I would like to see more commands that would give even more control over units. Also some already incorporated seem not to be documented.

If you open some of the missions that shipped with TOW you will see many techniques that can be employed to do what you want.

-

[Destraex]

but can it be randomised

[Webwing]

Originally posted by Webwing:

Plus there is the randomness that you can program to add some replayability to the mission.

[Destraex]

ok so I did not read .....

[nonickch]

Well, you can't compare the sensory input of a human and a computer and assume they can reach similar conclusions.

I skimmed through the trigger coding doc and it provides the most basic concepts needed.

Not much you can do with just those, but they look like enough to build upon.

Building layer over layer of abstraction over those simple commands one can reach a much more advanced "language" in which "flank (Left, target, Army)" makes sense.

But still, that is quite an undertaking certainly done at the wrong level.

The scripting language such as this should be the end of the buildup, not the beggining.

Which brings me to one of my biggest concerns and original questions:

Processing power. If I throw at it 1k commands per second, can it take it?

EDIT:

Well, I got the first one I'll have a go from tommorow on. Simple, yet usefull by all mission designers:

Replenishing dead gun crews (possibly stealing?).

Possible params: min crew number, min crew skill, min free infantry in area, size of area (edit: nvm, it's supported), move_mode.

And in extension replenishing/stealing vehicle crews (I didn't see any commands for empty vehicles)

Still a leap in abstraction, but a good testing ground (for example a threat indicator needs to be defined in order not to have infantrymen dashing towards the gun in front of tanks)

God I need to stop babbling.

[ May 17, 2007, 05:35 AM: Message edited by: nonickch ]

[Webwing]

Originally posted by nonickch:

Well, you can't compare the sensory input of a human and a computer and assume they can reach similar conclusions.

I don't think the AI will be even close to a human opponent in games. At least in the near future.

Still, if you were not the mission designer and you play a well designed mission you will get the felling of an intelligent opponent controlling the enemy army.

Originally posted by nonickch:

abstraction over those simple commands one can reach a much more advanced "language" in which "flank (Left, target, Army)" makes sense.

The problem with this abstract concept is that in this case Army is too general. You have your forces spread all over the map. Which unit is the AI going to flank?

Also I think the most realistic way to script is to use the visibility function. So the AI only reacts to what it has seen in the area it has seen it. And that is not so much work with the language we have now.

But I understand what you are saying. It would be great to just tell the AI: "Hey, if the troops try to surround you, launch an all out attack in the center. " Instead of having to code endless lines of code to have it do just that. A modder with programing skills could do that. But will someone be willing?

-

[nonickch]

So ummm, I have just noticed.

Instead of functions you can run sync triggers.

But uhm... how does one pass variables to called triggers?

That's like a showstopper.

[nonickch]

Instead of having to code endless lines of code to have it do just that. A modder with programing skills could do that. But will someone be willing?

Well, that was exactly my point in the original thread.

I'm considering of having a go at creating an initial package like this. I just wanted to clear some questions I had with the scripting language.

I'm looking to provide some level of abstraction for mission designers that will include the programming side of common tasks in a package.

Designer includes the packages (asynch init the triggers he wants from the looks of it) with hopefully some params and voila, problem solved.

BUT the tools that can be provided are severely limited by the language. I'm trying to figure ways around them, but it doesn't look pretty.

Um, I guess laying hands of any type of code is right out of the question?

Even just for the scripting module?

EDIT: oooh, where are the russian forums? I guess those guys are light years ahead in the matter.

I guess I have to let babelfish burn through their modding pages. 1c page is not that english-friendly.

[Webwing]

Originally posted by nonickch:

But uhm... how does one pass variables to called triggers?

That's like a showstopper.

I strongly advise you to read the triggers reference .

3.1.5 - Parameters for Triggers IN and OUT.

This is what you are looking for to start your OOP coding.

--

[nonickch]

ah, there is the bugger.

thnx

[Oudy]

Webwing

I'm looking at the whole visibility issue as well, the enemy troops should only act on units they see or have been seen. The problem is that there is no easy way to determine what unit you see. You have to loop through every enemy group and check them individually. I've not found an elegant way to loop through all of the groups to test visibility. There are some workarounds I've thought of but as far as I can tell you can't easily loop through them all. I would love advice if anyone has found a good way to do this.

I would love a command like GetNUnits that would filter for visibility. That way you could add a rectangle around visible units and attack them.

The scripting language is fairly robust, but there are a few commands I would love to see.

Oudy

[Webwing]

Originally posted by Oudy:

Webwing

I'm looking at the whole visibility issue as well, the enemy troops should only act on units they see or have been seen. The problem is that there is no easy way to determine what unit you see. You have to loop through every enemy group and check them individually. I've not found an elegant way to loop through all of the groups to test visibility. There are some workarounds I've thought of but as far as I can tell you can't easily loop through them all. I would love advice if anyone has found a good way to do this.

I would love a command like GetNUnits that would filter for visibility. That way you could add a rectangle around visible units and attack them.

Oudy

You mean you want to know, if a unit sees an enemy unit what type of unit is that, a tank, inf, etc?

You need that in order to know what action to take against it... right?

TRUE or FALSE won't do....

Only way I can figure is the way you are doing.

If you do it like a function in a separate Trigger with IN and OUT the you do it only once and can use for all missions you make.

I guess even if there is a command to do this it would loop under the hood anyway.

Originally posted by Oudy:

The scripting language is fairly robust, but there are a few commands I would love to see.

Oudy

I agree. We could sure do with a half a dozen extra commands. Maybe we could start a wish list...

I'd like one to know if a specific soldier in a squad is still alive, among a few others...

[ May 17, 2007, 05:19 PM: Message edited by: Webwing ]

[nonickch]

Questions, questions, questions:

Delay ( <DelayMin> , <DelayMax> )

Does the min/max provide any loadbalancing for the cpu or is it random when the trigger goes off?

Loadbalancing would be very sweet to have otherwise I see the game making hops each time a large chunk of triggers go off together in asynch.

Savegames:

Does the entire trigger status get saved along with the savegames or are they re-initialized upon loading a game? (something tells me they're saved by looking at the submissions)

Soldier/unit stats:

Any way of determining a soldiers gunnery skill for example? Can't send just any soldier to steal a hostile tank.

Or otherwise, is my tank faster than the tank X?

[nonickch]

I'd like one to know if a specific soldier in a squad is still alive, among a few others...

How about checking the equipment of the squad?

It should suffice for checking if there is a specific unit type (like sniper) in the squad rather than checking for a specific person.

If you do it like a function in a separate Trigger with IN and OUT the you do it only once and can use for all missions you make.

I guess even if there is a command to do this it would loop under the hood anyway.

Well it is an overkill of resources, but given the nature of the language looping would probably be the only way (registering callbacks would be the proper way for something like this).

I'd recon a good way to go about doing this is to code a trigger that OUT's a "visible units" stringlist and give it a low-ish delay time.

Then you can quickly draw the visible units off the local var in the parent trigger (work against a copy of the local var because it may get updated while you're iterating through it).

You start trigger instances for each unit you want to check visibility on (I bet running something like this for all units would pretty much grind the game to a full halt), and for convenience ID the instance by the ID of the unit.

Don't forget to kill the instance once the unit is dead so you can save cpu cycles.

[ May 18, 2007, 12:43 AM: Message edited by: nonickch ]

[Webwing]

Originally posted by nonickch:

It's an idea... specially good if you are checking for a sniper or commander, which is the case I have in mind.

But I don't know of a reason to check for a common soldier anyway...

thanks.