public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Peter Garrone <pgarrone@acay.com.au>
To: Hans Ronne <hronne@comhem.se>
Cc: xconq7@sources.redhat.com
Subject: Re: plan_transport
Date: Mon, 08 Dec 2003 00:50:00 -0000	[thread overview]
Message-ID: <20031207222718.GA1151@leonardo> (raw)
In-Reply-To: <l03130300bbf8346adb4c@[212.181.162.155]>

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

  reply	other threads:[~2003-12-07 23:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07  0:59 plan_transport Peter Garrone
2003-12-07  2:02 ` plan_transport Eric McDonald
2003-12-08  0:28   ` plan_transport Peter Garrone
2003-12-08  1:23     ` plan_transport Hans Ronne
2003-12-07  8:26 ` plan_transport Hans Ronne
2003-12-08  0:50   ` Peter Garrone [this message]
2003-12-08  3:26     ` plan_transport Hans Ronne
2003-12-08  3:55       ` plan_transport Hans Ronne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031207222718.GA1151@leonardo \
    --to=pgarrone@acay.com.au \
    --cc=hronne@comhem.se \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).