* plan_transport @ 2003-12-07 0:59 Peter Garrone 2003-12-07 2:02 ` plan_transport Eric McDonald 2003-12-07 8:26 ` plan_transport Hans Ronne 0 siblings, 2 replies; 8+ messages in thread From: Peter Garrone @ 2003-12-07 0:59 UTC (permalink / raw) To: xconq7; +Cc: 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: - 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-07 0:59 plan_transport Peter Garrone @ 2003-12-07 2:02 ` Eric McDonald 2003-12-08 0:28 ` plan_transport Peter Garrone 2003-12-07 8:26 ` plan_transport Hans Ronne 1 sibling, 1 reply; 8+ messages in thread From: Eric McDonald @ 2003-12-07 2:02 UTC (permalink / raw) To: Peter Garrone; +Cc: xconq7, Hans Ronne 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-07 2:02 ` plan_transport Eric McDonald @ 2003-12-08 0:28 ` Peter Garrone 2003-12-08 1:23 ` plan_transport Hans Ronne 0 siblings, 1 reply; 8+ messages in thread From: Peter Garrone @ 2003-12-08 0:28 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-08 0:28 ` plan_transport Peter Garrone @ 2003-12-08 1:23 ` Hans Ronne 0 siblings, 0 replies; 8+ messages in thread From: Hans Ronne @ 2003-12-08 1:23 UTC (permalink / raw) To: Peter Garrone; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-07 0:59 plan_transport Peter Garrone 2003-12-07 2:02 ` plan_transport Eric McDonald @ 2003-12-07 8:26 ` Hans Ronne 2003-12-08 0:50 ` plan_transport Peter Garrone 1 sibling, 1 reply; 8+ messages in thread From: Hans Ronne @ 2003-12-07 8:26 UTC (permalink / raw) To: Peter Garrone; +Cc: xconq7 > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-07 8:26 ` plan_transport Hans Ronne @ 2003-12-08 0:50 ` Peter Garrone 2003-12-08 3:26 ` plan_transport Hans Ronne 0 siblings, 1 reply; 8+ messages in thread From: Peter Garrone @ 2003-12-08 0:50 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-08 0:50 ` plan_transport Peter Garrone @ 2003-12-08 3:26 ` Hans Ronne 2003-12-08 3:55 ` plan_transport Hans Ronne 0 siblings, 1 reply; 8+ messages in thread From: Hans Ronne @ 2003-12-08 3:26 UTC (permalink / raw) To: Peter Garrone; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: plan_transport 2003-12-08 3:26 ` plan_transport Hans Ronne @ 2003-12-08 3:55 ` Hans Ronne 0 siblings, 0 replies; 8+ messages in thread From: Hans Ronne @ 2003-12-08 3:55 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 >>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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-12-08 1:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` plan_transport Peter Garrone 2003-12-08 3:26 ` plan_transport Hans Ronne 2003-12-08 3:55 ` plan_transport Hans Ronne
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).