AI (another master thread request)

[gottagofish]

I too am glad you are putitng in the effort on the AI.
 
Something I've noticed is combat damaged ships all try to return to their home base and many sink along the way.  How about looking at re-setting to the nearest base to give them more of a chance to survive? 

[jwilkerson]

ORIGINAL: pad152

Can the player set a trigger/script to do an evacuation (troops, aircraft, ships in port)?

Well to be clear, the player cannot set triggers in the game. Only the modder can set triggers in the editor.


In thinking about how a modder could schedule an evacuation, off the top of my head, one way would be to have a defensive script end on a specified date and then to assign the same units to a different defensive script starting on a (slightly) later date. That would work.

[pad152]

ORIGINAL: jwilkerson


In thinking about how a modder could schedule an evacuation, off the top of my head, one way would be to have a defensive script end on a specified date and then to assign the same units to a different defensive script starting on a (slightly) later date. That would work.

Are the triggers/scripts just date driven or also event driven? I was thinking something more like (allies capture Tarawa (event), start Japanese evac of Makin (script to reassign assets troops/air groups to Kwajalein)! Is something like this possible?

[jwilkerson]

ORIGINAL: pad152

Are the triggers/scripts just date driven or also event driven?

[/quote]

Try starting at post 15 above and reading back down to here. That should catch you up.
[:)]

http://www.matrixgames.com/forums/fb.asp?m=1880180

[pad152]

Can triggers be based on enemy actions (bombardment, capture location, basesize, etc.)?

[Kull]

ORIGINAL: jwilkerson

The impetus for this idea is actually a desire I have one day to implement a true "Petri Net inspired" control mechanism for an AI. What we've done to date is a weak version of same, but it does leverage the basic idea.

For those unclear on the Petri Net, here's a short introduction:
http://en.wikipedia.org/wiki/Petri_net

I had to read it a few times, but to try and put this in layman's terms, the idea of the Petri Net is better than if/then, because it allows you a great deal of flexibility in establishing the value of "if". For example, let's say the idea is to create a script that causes the Japanese AI to taken action "X" if the Allies attack the Marshalls. The current AI script leaves you little choice other than to pick an island such as Kwajalein to serve as the "if" trigger (barring the use of "nested ifs", which I assume is not possible in the current AI, and is downright coding ugly even if it is). But a Petri Net allows you much more flexibility. You can code something like, "if any 2 of the following 5 islands are taken by the Allies, then implement action X". Obviously that is a much more "human-like" evaluation process, and, among other things, keeps the human player from either deliberately or accidentally "gaming the system" (in the example above, by taking every island EXCEPT Kwajalein).

[jwilkerson]

Actually implementing a processor for petri nets, is easier than you might think. Even a "colored" petri net processor is not too tough. In PN speak a "color" is a segregation of tokens into one or more mutually exclusive, collectively exhaustive sub-sets. They are called "colors" just for convenience. But can represent any segregation of types of entities which might be "processed" by the system. But a transition can ask "Is this a Yellow token?" If so let it through. Or if it is a pink token let it through half the time, or if it is a green token, then we must also have a purple token wanting to pass before we allow them both to come through to the next state. And these "if" statements are short and simple. So the "coding" is more in how the PN is structured and the mix of tokens flowing into the net. I've written fully functional PN processors in hours to days. But designing the nets you want to accomplish the task can take a lot longer. That is basically want happens in our current processor, the complexity is in designing the "scripts" to acheieve the effect you want in the game. The code that processes the scripts is - at a high level anyway - much simplier than the old hard coded script processing code was.

[jwilkerson]

ORIGINAL: pad152

Can triggers be based on enemy actions (bombardment, capture location, basesize, etc.)?

Base capture = yes. Bombardment, basesize no.

There are two types of triggers, date and predecessor.

[Kull]

ORIGINAL: jwilkerson

Actually implementing a processor for petri nets, is easier than you might think. Even a "colored" petri net processor is not too tough. In PN speak a "color" is a segregation of tokens into one or more mutually exclusive, collectively exhaustive sub-sets. They are called "colors" just for convenience. But can represent any segregation of types of entities which might be "processed" by the system. But a transition can ask "Is this a Yellow token?" If so let it through. Or if it is a pink token let it through half the time, or if it is a green token, then we must also have a purple token wanting to pass before we allow them both to come through to the next state. And these "if" statements are short and simple. So the "coding" is more in how the PN is structured and the mix of tokens flowing into the net. I've written fully functional PN processors in hours to days. But designing the nets you want to accomplish the task can take a lot longer. That is basically want happens in our current processor, the complexity is in designing the "scripts" to acheieve the effect you want in the game. The code that processes the scripts is - at a high level anyway - much simplier than the old hard coded script processing code was.

Holy sheisse! The new Strategic AI uses a COLORED Petri Net!!??? That's major BRAIN surgery!! Now I finally understand (well, "have a glimmer" is probably more like it) what's going on behind the scenes. I don't know how hard it is to recode the AI from primitive linear to Petri Net, but once that's done, it sounds like the REAL Everest is building a strong net that can handle the ebb and flow of events in something as vast and dynamic as the Pacific War. And maybe it's just as well the script can only trigger off of dates and base ownership - at least that reduces the total number of potential token combinations.

This is fantastic news on two levels. First, it means you guys are creating an AI that can make a game of things for a while (and if the AI is the Allies, possibly even win), and at a minimum, can and will throw some surprises at the human player. Secondly, an accessible colored Petri Net means that modders have at least the opportunity to really work on the AI ina meaningful way - either by increasing the size of the existing Net, or by coming up with something different (God help that person!)

ORIGINAL: jwilkerson

Basically we are implementing a kind of "Forest" structure (no relation to our very own Forest ... a Forest in this sense - being a collection of trees. A "root node" of a tree in this forest is triggered by a start date, and subsequent nodes in a tree are triggered by successor relationships. A node in this tree we call a script, though actually it is pretty much what we were calling a script before - and it might more properly be called a "module". But this includes lists of attacking units, target bases, and defending units, and several other attributes.

The idea of the "Forest" is very intriguing. On the simplest level, presumably one could have a tree called "Java" to run the Dutch AI on or near that island. And depending upon where (and when) the Japanese chose to land, the AI could be given a different set of responses. And once Java is completely conquered by Japan, that would "close out" that tree - but not completely. Because if Japanese ownership of all Java occurs, that "predecessor" could now be used as a token by other scripts (for example, the launch of the "Timor" module).

This gets extremely cool, because there's probably no such thing as the human Allied Player holding out in "Fortress Wake" or "Fortress Luzon" anymore. You could try, but the AI's need to close out those trees is going to trigger - potentially - an increasingly massive response. Likewise, Japanese completion of the "Solomons" node could trigger a "Caledonia" tree (or - as in history - the "Midway" tree) while Singapore could lead the AI to the Andamans and then on to Ceylon, etc.

The real trick is, how do you prevent two different nodes for making simultaneous calls on KB? Or any other set of forces that are called upon by a triggering event? Sounds like serious headache potential.

[Kull]

(oops!)

[jwilkerson]

ORIGINAL: Kull

Holy sheisse! The new Strategic AI uses a COLORED Petri Net!!???

No, no , no, sorry, I was forwarding up to where I "want" to take this when are able to do a real PN implementation. The current "surgery, is a weak substitute, aligned with these ideas in spirit but not in form.

[Kull]

ORIGINAL: jwilkerson

No, no , no, sorry, I was forwarding up to where I "want" to take this when are able to do a real PN implementation. The current "surgery, is a weak substitute, aligned with these ideas in spirit but not in form.

Ahhh. Well, that's OK. A colored Petri Net was so far beyond expectations that I was gasping like a fish on the floor of the boat! The fact that you DO have a node forest is still very cool. So can I assume the new AI processor can handle multiple tokens, even if at can't weight them? That would still allow a lot of flexibility - MUCH better than a linear if/then.

Obviously this next question takes us beyond the current release, but do you envision an AE upgrade that features the colored PN? There have been hints that the team is at least considering something beyond AE, and it sort of sounds like more than a patch.

First things first, of course, and all things being equal I'd much rather hear a bit more about the workings of the "forest".

[jwilkerson]

ORIGINAL: Kull
So can I assume the new AI processor can handle multiple tokens...

Yes

do you envision an AE upgrade that features the colored PN?

No I'd say the full blown CPN implementation will have to wait for WITPII or equivalent.

I'd much rather hear a bit more about the workings of the "forest".

Well really the fancy word "forest" in this case just means that I think it is helpful to think of a tree of script nodes, linked by predecessor links to a root note which has no predecessor node, but does have a start date. This root node the "fires" the tree. And of course, since we can have many such root nodes, we have a forest.

[herwin]

Game engines should do a couple of things if they are to support a realistic AI.

Firstly and most importantly, they should produce realistic numerical outcomes both on a turn-to-turn and a campaign basis. By this, I mean they should damp out numerical errors and other noise over time rather than propagate them and when the turn length is shortened, the results should get more realistic. The standard approach is a version of Euler integration and tends to have trouble with stiffness--different kinds of combat have different time scales over which they become non-linear--land combat over days, naval combat over hours, and air combat over minutes--and noise and other errors tend to be propagated and inflated over time. The WiTP engine attempts to deal with this by fiddling with the willingness of units to engage in combat to limit the tempo--if the tempo is too high, it inflates early random advantages massively over a number of turns. This is necessary if the AI is to be able to predict future outcomes of current actions.

Secondly, a good game AI needs to be able to generate plans, both starting at the current position and backtracking from a goal. The forward planning or prediction mechanism allows the game to identify possibilities, while the backward planning mechanism allows the game to produce goal-oriented behaviour. The basic idea in backward planning is to come up with values for current actions that reflect the eventual rewards of various plans. Then the engine can follow up with the best possible current actions, and it can abandon plans that have lost their value. This planning is not possible unless the game engine is predictable in the sense of generating realistic numerical outcomes.

I guess those are the issues.