plan_transport

plan_transport

[Peter Garrone]

 I thought I would review the current problems and proposed fixes.
 I originally planned on sending this only to some people, but I think
 others probably could provide some valuable feedback.

The problems are:
- ferries are not built as they should be
  because the normal pathway where the task return a TASK_FAILED when it
  can no longer go forward, the ai calls the impassable function and
  sets a flag so that a ferry is assigned for construction, no longer
  works. The reasons why this no longer works as well are:
  - There is a bug in the path code so transportation is forbidden
  - The pathfinding returns impassable if no ferries are available, so
    they are never scheduled to be built because no paths ever require them.
- ferries are not assigned as they should be.
  (Actually this was a problem with the pre-path code.)
  - ferries are often assigned to react to enemy intrusions, even air
    attacks over impassable terrain, or to attack battleships and
    aircraft carriers.
  - A task is assigned to a full ferry before it calls the function that
    checks where all the current occupants are going and it goes to the
    middle of an ocean before returning to drop off its occupants.
  - ferries sometimes move a hex when an occupant has been scheduled to
    board, causing the occupant to disappear into the ocean.

Proposed solution.
 A solution to these problems (attribution to Hans here) would be as follows.
 - implement a PLAN_TRANSPORT for ferries, so they are permanently
   assigned to transportation duties, though of course offensive units
   will be transported by them.
 - implement a TRANSPORT_TASK as well, so that human players can asign a
   unit to ferrying, and units will move across islands and seas without
   all that bookkeeping. So a PLAN_TRANSPORT will activate a
   TRANSPORT_TASK.
 - Have only two tasks that do movement, the moveto task and the pickup
   task. The pickup task is only used by the ferry. The hit-unit and
   occupy tasks push moveto tasks. Only the moveto task hails a ferry.
 - When the moveto task needs to board a ferry, it hails it in the task
   code, scheduling a ferry if one exists. If one doesnt, it returns a
   TASK_FAILED and higher level ai code determines the failure reason
   and schedules a ferry to be built, and reassigns the unit to another
   task.
 - ai code also inspects the schedule of units waiting for a ferry, and
   if there is too much of a queue, or any sort of a queue, ensures that
   enough ferries are being build to handle them.
 - If a ferry has been waiting round for some large number of moves
   without any action, it returns a TASK_FAILED and gets reassigned to
   something offensive.
 - Something needs to be added to the ai code so that it can distinguish
   a simple ferry from something offensive, like an aircraft carrier or
   bireme/trireme. This is asking a lot but perhaps some simple
   heuristic could fix this. So a bireme would not go onto
   PLAN_TRANSPORT, but instead grab an archer to help it in sea-battles.
 - The pathfinding would need to be somewhat extended here. It need so
   consider going from A to B using ferry type C, extending the state
   space it explores for possible solutions from simple x,y position.
 - consideration could be given to implementing refueling behavior, 
   a boring detail for the human player,
   while extending the pathfinding state space.

   This is my "wishlist". I will attempt to implement it in stages, so
   that a partial implementation may suffice for a 7.5 release, comments
   invited,
    Peter.
   

Re: plan_transport

[Eric McDonald]

Hi Peter, Hans, others,

I agree with most of your points.

On Sun, 7 Dec 2003, Peter Garrone wrote:

>  - Something needs to be added to the ai code so that it can distinguish
>    a simple ferry from something offensive, like an aircraft carrier or
>    bireme/trireme. This is asking a lot but perhaps some simple
>    heuristic could fix this. So a bireme would not go onto
>    PLAN_TRANSPORT, but instead grab an archer to help it in sea-battles.

Perhaps this could be an additional U_PROP or UU_TABLE rather than 
an AI heuristic. That way the game designer has the flexibility 
to designate units in some 'ai-occupant-helps-transport' table. 
Another thing that I have been thinking about for a couple of 
months now is whether 'ai-peace-garrison' and 'ai-war-garrison' 
are really the best ways to go about specifying occupant/transport 
recommendations to the AI. I think that perhaps these should be 
TableUU things, so that the AI (with proper coding added) can be 
more discriminating about which units to garrison with.

>  - consideration could be given to implementing refueling behavior, 
>    a boring detail for the human player,
>    while extending the pathfinding state space.

Sounds good.

>    This is my "wishlist". I will attempt to implement it in stages, so
>    that a partial implementation may suffice for a 7.5 release, comments
>    invited,

Thanks,
  Eric

Re: plan_transport

[Hans Ronne]

> I thought I would review the current problems and proposed fixes.
> I originally planned on sending this only to some people, but I think
> others probably could provide some valuable feedback.
>
>The problems are:

To that I would add that AI-controlled occupants do not disembark when they
should. This was a problem also with the old code, but it seems worse now.

>Proposed solution.
> A solution to these problems (attribution to Hans here) would be as follows.
> - implement a PLAN_TRANSPORT for ferries, so they are permanently
>   assigned to transportation duties, though of course offensive units
>   will be transported by them.
> - implement a TRANSPORT_TASK as well, so that human players can asign a
>   unit to ferrying, and units will move across islands and seas without
>   all that bookkeeping. So a PLAN_TRANSPORT will activate a
>   TRANSPORT_TASK.

A player-settable TRANSPORT_TASK might be a good idea. But it would work
only for one ferry round. It would be even better to be able to set a
PLAN_TRANSPORT and let ferries run on automatic. However, this would
require a semi-automatic mode where it is possible to set (and keep) plans
also for player-controlled units. I experimented with this two years ago,
and I think it was discussed on the list. It would also make it possible to
assign PLAN_OFFENSIVE or PLAN_DEFENSIVE to units and then have the AI run
them according to a set plan (right now, the AI will replan as soon as you
turn over a unit to it, so setting plans has no effect even if it can be
done). Something to consider post-7.5, I think.

> - Something needs to be added to the ai code so that it can distinguish
>   a simple ferry from something offensive, like an aircraft carrier or
>   bireme/trireme. This is asking a lot but perhaps some simple
>   heuristic could fix this. So a bireme would not go onto
>   PLAN_TRANSPORT, but instead grab an archer to help it in sea-battles.

This one is easy. We would just need to define a precomputed u_ferry_worth
that measures ferry capacity and weighs it into mplayer_decide_plan.
Similarly for the build code. There is already basic_transport_worth but it
is rather crude. I would like something better.

> - The pathfinding would need to be somewhat extended here. It need so
>   consider going from A to B using ferry type C, extending the state
>   space it explores for possible solutions from simple x,y position.
> - consideration could be given to implementing refueling behavior,
>   a boring detail for the human player,
>   while extending the pathfinding state space.
>
>   This is my "wishlist". I will attempt to implement it in stages, so
>   that a partial implementation may suffice for a 7.5 release, comments
>   invited,

I agree with the other points on your list.

Hans

Re: plan_transport

[Peter Garrone]

On Sat, Dec 06, 2003 at 07:59:29PM -0500, Eric McDonald wrote:
> On Sun, 7 Dec 2003, Peter Garrone wrote:
> 
> >  - Something needs to be added to the ai code so that it can distinguish
> >    a simple ferry from something offensive, like an aircraft carrier or
> >    bireme/trireme. This is asking a lot but perhaps some simple
> >    heuristic could fix this. So a bireme would not go onto
> >    PLAN_TRANSPORT, but instead grab an archer to help it in sea-battles.
> 
> Perhaps this could be an additional U_PROP or UU_TABLE rather than 
> an AI heuristic. That way the game designer has the flexibility 
> to designate units in some 'ai-occupant-helps-transport' table. 
> Another thing that I have been thinking about for a couple of 
> months now is whether 'ai-peace-garrison' and 'ai-war-garrison' 
> are really the best ways to go about specifying occupant/transport 
> recommendations to the AI. I think that perhaps these should be 
> TableUU things, so that the AI (with proper coding added) can be 
> more discriminating about which units to garrison with.
> 
I thought it would be better to have the AI analyse the basic
capabilities of all the units and have it do it itself, rather than
embed it in the GDL. However I am not yet very familiar with the GDL so
I cant really comment. for the moment, I dont really propose to extend
the GDL anyway.

Peter

Re: plan_transport

[Peter Garrone]

On Sun, Dec 07, 2003 at 03:02:06AM +0100, Hans Ronne wrote:
> > I thought I would review the current problems and proposed fixes.
> > I originally planned on sending this only to some people, but I think
> > others probably could provide some valuable feedback.
> >
> >The problems are:
> 
> To that I would add that AI-controlled occupants do not disembark when they
> should. This was a problem also with the old code, but it seems worse now.

I did have some problems with the test/transport.g game, but it is
addressed now. The ferry drops each unit off at its requested position.
But if the unit has had its task changed, it tries to jump back in the
ferry. But if the moveto task returns TASK_INCOMPLETE while waiting for
a ferry, then it will not get a new task, or shouldnt.

> 
> >Proposed solution.
> > A solution to these problems (attribution to Hans here) would be as follows.
> > - implement a PLAN_TRANSPORT for ferries, so they are permanently
> >   assigned to transportation duties, though of course offensive units
> >   will be transported by them.
> > - implement a TRANSPORT_TASK as well, so that human players can asign a
> >   unit to ferrying, and units will move across islands and seas without
> >   all that bookkeeping. So a PLAN_TRANSPORT will activate a
> >   TRANSPORT_TASK.
> 
> A player-settable TRANSPORT_TASK might be a good idea. But it would work
> only for one ferry round. It would be even better to be able to set a
> PLAN_TRANSPORT and let ferries run on automatic. However, this would
> require a semi-automatic mode where it is possible to set (and keep) plans
> also for player-controlled units. I experimented with this two years ago,
> and I think it was discussed on the list. It would also make it possible to
> assign PLAN_OFFENSIVE or PLAN_DEFENSIVE to units and then have the AI run
> them according to a set plan (right now, the AI will replan as soon as you
> turn over a unit to it, so setting plans has no effect even if it can be
> done). Something to consider post-7.5, I think.

In the current setup the human controlled units have PLAN_PASSIVE.
But tasks can be assigned to units. So I thought it would be better to
keep this structure if possible for now, so the "helper ai" is
implemented as a task. The human assigns a ferry to a ferry task,
which just waits for passengers, doing random walks if no work, until
some move limit is reached, where it returns a task-complete, starts
blinking, and a new task is assigned. The ai will assign PLAN_TRANSPORT
which assigns a TRANSPORT_TASK, so it keeps with the current structure.
For the ai, if a TRANSPORT_TASK is complete, it will just set it again.
This approach keeps with the existing structure, and adds
considerable functionality.

On a side note, having PLAN_OFFENSIVE and PLAN_DEFENSIVE is a bit
artificial, and it is easy to imagine different AI setups. The most
defensive of modern weapons is probably a fighter aircraft, because it
operates only out of a fixed base, while the most offensive weapons are
aircraft carriers and troop carriers, because they can project.

> 
> > - Something needs to be added to the ai code so that it can distinguish
> >   a simple ferry from something offensive, like an aircraft carrier or
> >   bireme/trireme. This is asking a lot but perhaps some simple
> >   heuristic could fix this. So a bireme would not go onto
> >   PLAN_TRANSPORT, but instead grab an archer to help it in sea-battles.
> 
> This one is easy. We would just need to define a precomputed u_ferry_worth
> that measures ferry capacity and weighs it into mplayer_decide_plan.
> Similarly for the build code. There is already basic_transport_worth but it
> is rather crude. I would like something better.

It is fairly complex actually. Need to account for aircraft carriers
which are quite offensive, but which shouldnt really have much
hit-pointage in themselves, bireme/trireme which take units to help them
fight, transports and barges which enable land units to be seaborne, and
cargo planes that take paratroopers. It would be nice to have the ai put
together complete invasion packages with carriers, troop transports, and
protection units like destroyers, battleships and minesweepers.

However for the present it is easier to assign transports to
PLAN_TRANSPORT based on the existing arrangement. The existing code has
a tendency to assign ferries to offensive duties which is inappropriate.
So it a ferry or cargo plane stays in PLAN_TRANSPORT rather than
attacking something it would be better.

Another note. These worths are a number starting at 0 and extending
upwards. If they were scaled from 0 to say 100, then we could carry out
fuzzy logic calculations, with fuzzy AND as a MIN operation, fuzzy OR as
a MAX operation, and fuzzy NOT as a (100 -x) operation. Might help the
AI think better.

 Peter

Re: plan_transport

[Hans Ronne]

>> Perhaps this could be an additional U_PROP or UU_TABLE rather than
>> an AI heuristic. That way the game designer has the flexibility
>> to designate units in some 'ai-occupant-helps-transport' table.
>> Another thing that I have been thinking about for a couple of
>> months now is whether 'ai-peace-garrison' and 'ai-war-garrison'
>> are really the best ways to go about specifying occupant/transport
>> recommendations to the AI. I think that perhaps these should be
>> TableUU things, so that the AI (with proper coding added) can be
>> more discriminating about which units to garrison with.
>>
>I thought it would be better to have the AI analyse the basic
>capabilities of all the units and have it do it itself, rather than
>embed it in the GDL. However I am not yet very familiar with the GDL so
>I cant really comment. for the moment, I dont really propose to extend
>the GDL anyway.

The main reason why we have things like ai-peace-garrison and
ai-war-garrison (and also doctrines) is that the AI is not smart enough to
handle all possible situations in all possible games. Usually, the game
designer understands the game better than the AI will ever do, and this is
one way for him to help the AI. If we had a really good all-purpose AI, we
would not need this kind of stuff.

Hans

Re: plan_transport

[Hans Ronne]

>> To that I would add that AI-controlled occupants do not disembark when they
>> should. This was a problem also with the old code, but it seems worse now.
>
>I did have some problems with the test/transport.g game, but it is
>addressed now. The ferry drops each unit off at its requested position.

Excellent.

>> A player-settable TRANSPORT_TASK might be a good idea. But it would work
>> only for one ferry round. It would be even better to be able to set a
>> PLAN_TRANSPORT and let ferries run on automatic. However, this would
>> require a semi-automatic mode where it is possible to set (and keep) plans
>> also for player-controlled units. I experimented with this two years ago,
>> and I think it was discussed on the list. It would also make it possible to
>> assign PLAN_OFFENSIVE or PLAN_DEFENSIVE to units and then have the AI run
>> them according to a set plan (right now, the AI will replan as soon as you
>> turn over a unit to it, so setting plans has no effect even if it can be
>> done). Something to consider post-7.5, I think.
>
>In the current setup the human controlled units have PLAN_PASSIVE.
>But tasks can be assigned to units. So I thought it would be better to
>keep this structure if possible for now, so the "helper ai" is
>implemented as a task.

Exactly. That was my point. There has been a lot of confusion on this list
about plans and what happens if you set them for a human-controlled unit. I
therfore wanted to clarify this point.

>On a side note, having PLAN_OFFENSIVE and PLAN_DEFENSIVE is a bit
>artificial, and it is easy to imagine different AI setups. The most
>defensive of modern weapons is probably a fighter aircraft, because it
>operates only out of a fixed base, while the most offensive weapons are
>aircraft carriers and troop carriers, because they can project.

The difference between PLAN_OFFENSIVE and PLAN_DEFENSIVE is not that big
with respect to combat since the action-reaction code will handle combat in
both cases. The main difference is rather if the unit tries to go somewhere
(PLAN_OFFENSIVE) or stays where it is (PLAN_DEFENSIVE). Making this kind of
strategic assignment is, however, frequently what the human player would
like to do.

>> This one is easy. We would just need to define a precomputed u_ferry_worth
>> that measures ferry capacity and weighs it into mplayer_decide_plan.
>> Similarly for the build code. There is already basic_transport_worth but it
>> is rather crude. I would like something better.
>
>It is fairly complex actually. Need to account for aircraft carriers
>which are quite offensive, but which shouldnt really have much
>hit-pointage in themselves, bireme/trireme which take units to help them
>fight, transports and barges which enable land units to be seaborne, and
>cargo planes that take paratroopers. It would be nice to have the ai put
>together complete invasion packages with carriers, troop transports, and
>protection units like destroyers, battleships and minesweepers.

Writing a good u_ferry_worth can certainly be rather complicated. My point
was that the problem is easily dealt with in principle.

>However for the present it is easier to assign transports to
>PLAN_TRANSPORT based on the existing arrangement. The existing code has
>a tendency to assign ferries to offensive duties which is inappropriate.
>So it a ferry or cargo plane stays in PLAN_TRANSPORT rather than
>attacking something it would be better.

Precisely.

>Another note. These worths are a number starting at 0 and extending
>upwards. If they were scaled from 0 to say 100, then we could carry out
>fuzzy logic calculations, with fuzzy AND as a MIN operation, fuzzy OR as
>a MAX operation, and fuzzy NOT as a (100 -x) operation. Might help the
>AI think better.

The main reason why the worth function return relative (and open-ended)
rather than absolute values is generality. It is very difficult to get
worth functions that return absolute values to work with many different
games that have very different units. You could let the game designer
assign appropriate absolute values in each game, but then we are back in a
situation where the game designer rather than the AI is playing the AI
side, as discussed above.

We could take another look at this post-7.5, though. I'm not very happy
with the current worth functions.

Hans

Re: plan_transport

[Hans Ronne]

>>Another note. These worths are a number starting at 0 and extending
>>upwards. If they were scaled from 0 to say 100, then we could carry out
>>fuzzy logic calculations, with fuzzy AND as a MIN operation, fuzzy OR as
>>a MAX operation, and fuzzy NOT as a (100 -x) operation. Might help the
>>AI think better.
>
>The main reason why the worth function return relative (and open-ended)
>rather than absolute values is generality. It is very difficult to get
>worth functions that return absolute values to work with many different
>games that have very different units. You could let the game designer
>assign appropriate absolute values in each game, but then we are back in a
>situation where the game designer rather than the AI is playing the AI
>side, as discussed above.
>
>We could take another look at this post-7.5, though. I'm not very happy
>with the current worth functions.

This is a followup since I realize that my comment about the worth
functions was somewhat misleading. The problem is not as much relative vs.
absolute values, since it is possible to normalize the values, but rather
how to factor in different components. Here is a link to the relevant
discussion on the list last year:

http://sources.redhat.com/ml/xconq7/2002/msg00556.html

Since it is possible to normalize the return value over all units in the
game, I think what you propose may work. We would of course still face the
problem to decide if a ferry_worth of 60 beats a colonizer_worth of 50,
i.e. how to compare apples and pears.

Hans