Just say no to bungee paratroopers.

Just say no to bungee paratroopers.

[Henry J. Cobb]

I've gotten rather tired of the bungee paratrooper trick of having a
bomber fly around somebody's coastline capturing towns with the same
infantry unit over and over again so I wrote a patch that applies two
rules:

If you capture something and you can fit inside it then you move in as
part of the capture.

If you attempt to capture something from inside a transport and you fail
then you drop out on the ground or sea under the transport as you're
pushed back.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Eric McDonald]

Henry J. Cobb wrote:

> I've gotten rather tired of the bungee paratrooper trick of having a
> bomber fly around somebody's coastline capturing towns with the same
> infantry unit over and over again 

I assume you're referring to the Standard game.

>so I wrote a patch that applies two
> rules:
> 
> If you capture something and you can fit inside it then you move in as
> part of the capture.

I am not sure that this would be desired behavior in all cases, but for 
want of a good counterexample, your proposal does sound fairly reasonable.

> If you attempt to capture something from inside a transport and you fail
> then you drop out on the ground or sea under the transport as you're
> pushed back.

I don't know about this. Consider troops attempting a capture from a 
helicopter unit; they ought to be able to return to the helicopters if 
the capture fails....

   Regards,
      Eric

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>>so I wrote a patch that applies two
>> rules:
>>
>> If you capture something and you can fit inside it then you move in as
>> part of the capture.
>
>I am not sure that this would be desired behavior in all cases, but for
>want of a good counterexample, your proposal does sound fairly reasonable.

I would concur. Even in non-paratrooper games, it makes sense for a
capturing unit to move inside. Right now, it will wait outside for one turn
or even move away, until the capture task has been changed to an occupy
task. I've been planning to improve how the AI handles such cases. A lot
can happen in one turn ...

>> If you attempt to capture something from inside a transport and you fail
>> then you drop out on the ground or sea under the transport as you're
>> pushed back.
>
>I don't know about this. Consider troops attempting a capture from a
>helicopter unit; they ought to be able to return to the helicopters if
>the capture fails....

The key question is if captures (or attacks) from inside transports should
be allowed at all. In principle, I think not. Paratroopers should jump into
an empty cell, then attack on the ground from there. Jumping on top of
enemy positions is suicide, as several examples from history show, so it
should not be supported as a viable attack mode in Xconq.

You could argue that troop transports at a fortified beach or marines in a
spaceship outside a planet are cases where attacks from inside transports
should be allowed, since there is no empty cell into which they first can
land. However, also in this case, the troops are committed once they attack
and cannot return to their transports. Only overrun actions should be
allowed in such cases, and the attackers should perish if they fail.

These were some general thoughts on the subject. I'm not sure it can all be
easily implemented. Changes to the AI might be necessary as well.

Hans

Re: Just say no to bungee paratroopers.

[Eric McDonald]

Hans Ronne wrote:

> I would concur. Even in non-paratrooper games, it makes sense for a
> capturing unit to move inside. Right now, it will wait outside for one turn
> or even move away, until the capture task has been changed to an occupy
> task. I've been planning to improve how the AI handles such cases. A lot
> can happen in one turn ...

Are we talking about teaching the AI to do something or are we talking 
about an implicit action. I was under the impression that we were 
talking about the latter and not necessarily the former.

As I mentioned to Henry off-list, I am not sure that it is wise to 
impose a certain action "granularity" or time scale on game designers. 
Some games may dictate the kind of implicit action we are talking about, 
but others may not. I am not sure that capture always implies a forceful 
overrun followed by garrisoning. It may imply that the defender felt 
forced into surrender by the immediate presence of the capturing unit 
(independent of surrender chances).

> The key question is if captures (or attacks) from inside transports should
> be allowed at all. In principle, I think not. Paratroopers should jump into
> an empty cell, then attack on the ground from there. Jumping on top of
> enemy positions is suicide, as several examples from history show, so it
> should not be supported as a viable attack mode in Xconq.

That is one perspective. However, a game with a somewhat different time 
scale and different take on actions may be better served by having, say, 
the troops leave a helicopter, attempt capture, and then get back on the 
helicopter all as part of the capture action.

Here again, I think we can ultimately be better served by a modular 
combat system that gives us the flexibility of turning on or off such 
behavior, instead of hacking an entire combat model and telling everyone 
that they have to do things the same way.

Eric

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>Hans Ronne wrote:
>
>> I would concur. Even in non-paratrooper games, it makes sense for a
>> capturing unit to move inside. Right now, it will wait outside for one turn
>> or even move away, until the capture task has been changed to an occupy
>> task. I've been planning to improve how the AI handles such cases. A lot
>> can happen in one turn ...
>
>Are we talking about teaching the AI to do something or are we talking
>about an implicit action. I was under the impression that we were
>talking about the latter and not necessarily the former.

My point was that the AI is too slow in occupying captured units. I have
been thinking about fixing this, but if captured units are occupied
automatically, the AI problem would be fixed anyway.

Hans

Re: Just say no to bungee paratroopers.

[Jim Kingdon]

> I've gotten rather tired of the bungee paratrooper trick of having a
> bomber fly around somebody's coastline capturing towns with the same
> infantry unit over and over again

Yes.  I'm quite a heavy user of that trick, but I'll agree that it
throws off the game balance.  I suppose if my opponents (currently
AIs) were better at keeping enough fighters around to shoot down said
bombers, it wouldn't seem so lopsided, but the AI isn't smart enough
to do this with enough consistency.

> If you capture something and you can fit inside it then you move in as
> part of the capture.

Sounds fair.  Note that this also brings up new possibilities, for
example an armor captures a coast town with their first ACP, and then
uses their second ACP to capture a town one in from the coast.  I'm
not sure whether this is good or bad.

However, what really makes the bungee paratrooper trick powerful is
the failure case, so we'll proceed to that one:

> If you attempt to capture something from inside a transport and you fail
> then you drop out on the ground or sea under the transport as you're
> pushed back.

Well, if the goal is to make attacking from a transport harder, this
would have that effect.  It would put a premium on finding a
beachhead, so you can land your infantry/armor, rather than just
attacking from a transport ship (or bomber which is over water).

I kind of suspect the show-stopper here would be the AI.  Unless it is
smart enough to look for beachheads, this change might make the AI
even less of a contender than it is now.

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

Jim Kingdon wrote:
> However, what really makes the bungee paratrooper trick powerful is
> the failure case, so we'll proceed to that one:
>
>> If you attempt to capture something from inside a transport and you fail
>> then you drop out on the ground or sea under the transport as you're
>> pushed back.
>
> Well, if the goal is to make attacking from a transport harder, this
> would have that effect.  It would put a premium on finding a
> beachhead, so you can land your infantry/armor, rather than just
> attacking from a transport ship (or bomber which is over water).
>
> I kind of suspect the show-stopper here would be the AI.  Unless it is
> smart enough to look for beachheads, this change might make the AI
> even less of a contender than it is now.

Actually it seems to do OK, but that may do with the Makin Island patch I
put on the standard scenario giving subs the ability to transport 1 Inf.

It keeps grabbing my coastal bases and towns.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

OK, here's my patch.

combat.c
	    capture_unit(atker, other, H_UNIT_CAPTURED);
        if(valid(check_enter_action(atker, atker, other)))
            do_enter_action(atker, atker, other);
...
	    report_combat(atker, other, "resist");
        if(alive(atker) && atker->transport &&
type_can_occupy_cell(atker->type,atker->transport->x,
atker->transport->y))
            do_move_action(atker,atker,atker->transport->x,
atker->transport->y,atker->transport->z);


-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Hans Ronne]

I have checked in your first patch. Thanks for submitting it. I made two
changes. First, I moved it inside capture_unit (which is called from
several places). Second, I added code for trying to enter the same cell if
the capturing unit is unable to enter the captured unit itself.

The second problem (what to do if an attack from within a transport fails)
is a little more complicated and requires additional thought. Perhaps we
should make the fate of such units a GDL option, as Eric suggested.

Hans

Re: Just say no to bungee paratroopers.

[Jim Kingdon]

> First, I moved it inside capture_unit (which is called from several
> places). Second, I added code for trying to enter the same cell if the
> capturing unit is unable to enter the captured unit itself.

One interesting feature of this patch (both versions) is that entering
the captured unit uses up whatever ACP would have been needed to do
the enter action.

In the case of the standard game, this means that an armor which
captures from a troop transport will not have an ACP left when it gets
inside the town which it captured.

I'm not sure whether this is better or worse than the other choice,
which would be to give the enter action for free, but I thought it was
worth noting.

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>> First, I moved it inside capture_unit (which is called from several
>> places). Second, I added code for trying to enter the same cell if the
>> capturing unit is unable to enter the captured unit itself.
>
>One interesting feature of this patch (both versions) is that entering
>the captured unit uses up whatever ACP would have been needed to do
>the enter action.
>
>In the case of the standard game, this means that an armor which
>captures from a troop transport will not have an ACP left when it gets
>inside the town which it captured.
>
>I'm not sure whether this is better or worse than the other choice,
>which would be to give the enter action for free, but I thought it was
>worth noting.

You are abolutely right, and I think this is the correct way to do things.
There are actually some freebies in the kernel code, too. One example is
the ACP-less counterattack, and even counter-capture, that an attacked unit
may engage in. Another, I think, is the ACP-less escape of occupants into
an adjacent cell when the transport is captured.

But I have always regarded these freebies as aberrations. It makes much
more sense to charge the full price whenever you do something. There may be
restrictions built in by the game designer, such as if the enter action
requires more ACPs than the unit can possess. In that case, ACP-less entry
by capture would clearly be a bug. Anyway, the fact that the captured unit
is occupied immediately, and not the next turn, is in itself an advantage
to the attacking side. Doing it free of charge would be too much of an
advantage.

What this means, of course, is that the attacker will not be able to enter
the captured unit if it has used up all its ACPs for the turn. This, I
think makes for a more interesting game. Situations like that are not
uncommon in Civ.

Hans

Re: Just say no to bungee paratroopers.

[mskala]

On Sun, 4 Jul 2004, Hans Ronne wrote:
> But I have always regarded these freebies as aberrations. It makes much
> more sense to charge the full price whenever you do something. There may be
> restrictions built in by the game designer, such as if the enter action
> requires more ACPs than the unit can possess. In that case, ACP-less entry

In fairness, the designer may also be intentionally exploiting the freebie
behaviour.  I've been off doing other things instead of xconq for the last
several weeks, but I remember in my game where I had the inanimate
counters, at one point attempting to set them up so that certain units
could not deliberately drop their counters, but the counters would escape
to terrain on capture or destruction of the transporting unit.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>On Sun, 4 Jul 2004, Hans Ronne wrote:
>> But I have always regarded these freebies as aberrations. It makes much
>> more sense to charge the full price whenever you do something. There may be
>> restrictions built in by the game designer, such as if the enter action
>> requires more ACPs than the unit can possess. In that case, ACP-less entry
>
>In fairness, the designer may also be intentionally exploiting the freebie
>behaviour.

True. Provided that he knows about them, of course. But I doubt that many
game designers were aware of the kernel freebies, at least not before this
thread got started :-).

Hans

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

Even with this patch I can still take down any star empire in galaxy2 that
I can get a loaded transport within 5 hexes of one core planet.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

> Henry J. Cobb wrote:
>> Even with this patch I can still take down any star empire in galaxy2
>> that
>> I can get a loaded transport within 5 hexes of one core planet.
>
> I'm not a galaxy2 player. Are you saying there is a problem with the
> galaxy2 game module or a more general problem with Xconq? And, what
> exactly is it that you don't think is right?
>
> Eric

My patch would help galaxy2 a bit if troopers died in space.

The basic problem is that a loaded transport is almost 100 percent certain
to take any world in time to land itself and avoid counterfire.

It's also nice to take light cruisers, move out four hexes, take one shot
at somebody then launch a fighter that pounds on them (fighters don't have
working ammo limits.)

Then the fighter returns to the cruiser and the cruiser returns to the
planet and the AIs then take their turns without targets.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

>> My patch would help galaxy2 a bit if troopers died in space.
>>
>> The basic problem is that a loaded transport is almost 100 percent
>> certain
>> to take any world in time to land itself and avoid counterfire.
>>
>> It's also nice to take light cruisers, move out four hexes, take one
>> shot
>> at somebody then launch a fighter that pounds on them (fighters don't
>> have
>> working ammo limits.)
>>
>> Then the fighter returns to the cruiser and the cruiser returns to the
>> planet and the AIs then take their turns without targets.
>
> OK, thanks for the more detailed analysis. If I get some time this
> weekend, I will try to figure out what to do about this (either a change
> to galaxy2 or more changes to the capture logic).
>
> Eric

Both these cases have the same problem.

Time is being used twice, once by the transport and again by the passengers.

So the transport gets to use the entire time of the turn and then each
passenger gets a full turn.

The fix is to count the transport's movement against the passengers as well.

So if the transport uses up half it's movement before launching a
passenger then the passenger has only half of its own movement remaining.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>Both these cases have the same problem.
>
>Time is being used twice, once by the transport and again by the passengers.
>
>So the transport gets to use the entire time of the turn and then each
>passenger gets a full turn.
>
>The fix is to count the transport's movement against the passengers as well.
>
>So if the transport uses up half it's movement before launching a
>passenger then the passenger has only half of its own movement remaining.

I'm not sure I agree with that. Many games depend on this feature, see for
example the Flattops game where the ability to launch an air strike after
forward deployment of a carrier is important. The mplayer is also quite
good at using this strategy.

I rather think that it is the galaxy2 game that needs some fixes. It should
be harder to capture planets, particularly if they are adequately defended.
We could probably use some GDL tables from the advances game which is very
much about defending important transports (in tha case cities).

Hans

Re: Just say no to bungee paratroopers.

[Henry J. Cobb]

>>Both these cases have the same problem.
>>
>>Time is being used twice, once by the transport and again by the
>> passengers.
>>
>>So the transport gets to use the entire time of the turn and then each
>>passenger gets a full turn.
>>
>>The fix is to count the transport's movement against the passengers as
>> well.
>>
>>So if the transport uses up half it's movement before launching a
>>passenger then the passenger has only half of its own movement remaining.
>
> I'm not sure I agree with that. Many games depend on this feature, see for
> example the Flattops game where the ability to launch an air strike after
> forward deployment of a carrier is important. The mplayer is also quite
> good at using this strategy.
>
> I rather think that it is the galaxy2 game that needs some fixes. It
> should
> be harder to capture planets, particularly if they are adequately
> defended.
> We could probably use some GDL tables from the advances game which is very
> much about defending important transports (in tha case cities).
>
> Hans

Just change the AI to run occupants first then the carrier so it does its
air strike, returns the aircraft and pulls out of range of the surface
forces.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Carrier groups

[Henry J. Cobb]

Every time I see a lone empty unescorted aircraft carrier wandering around
my coastline my respect for the AI goes down a bit.

While I don't have a full topology and fractal fix for the AI I think we
ought to be able to define standard unit combinations for it in the game
files.

So a carrier strike group would be defined as a group of units centered on
a carrier.  (With a full load of fighters and a battleship.)

The entire group moves with the carrier and withdraws with it when the
carrier is low on fuel, ammo or aircraft.

When a carrier is first built it recruits the rest of the strike group to
it and marks up a scorecard for priority production if it can't get enough
aircraft or escorts.

The aircraft assigned to the carrier will always return to it if they can
and no other aircraft will land on the carrier except if they are assigned
to a free slot.  (This keeps the carrier from launching a strike then
filling up with land based aircraft that will then crowd out the returning
airwing.)

Once the aircraft carriers are survivable we can worry about making amphib
operations work correctly.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Carrier groups

[Hans Ronne]

>So a carrier strike group would be defined as a group of units centered on
>a carrier.  (With a full load of fighters and a battleship.)
>
>The entire group moves with the carrier and withdraws with it when the
>carrier is low on fuel, ammo or aircraft.

What you are suggesting is in effect the possibility of having side
doctrines for setting formations. This would certainly be possible.
However, the AI doesn't know how to use formations, so one would first have
to write some new AI code.

Hans

Re: Carrier groups

[Henry J. Cobb]

>>So a carrier strike group would be defined as a group of units centered
>> on
>>a carrier.  (With a full load of fighters and a battleship.)
>>
>>The entire group moves with the carrier and withdraws with it when the
>>carrier is low on fuel, ammo or aircraft.
>
> What you are suggesting is in effect the possibility of having side
> doctrines for setting formations. This would certainly be possible.
> However, the AI doesn't know how to use formations, so one would first
> have
> to write some new AI code.
>
> Hans

Yeah, but nothing really heavy, just subordinate certain units to follow a
leader around.

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Just say no to bungee paratroopers.

[Jim Kingdon]

> So the transport gets to use the entire time of the turn and then each
> passenger gets a full turn.
> 
> The fix is to count the transport's movement against the passengers as well.

That's a very interesting suggestion.

I guess in the case of an infantry in a bomber in the standard game,
it would mean the bomber could move zero to two hexes, and the
infantry would still have an ACP.  That's assuming a particular
rounding rule - other ways of rounding would get 0-5, 0-3, or 0 only.

Assuming the 1-2 rule, it wouldn't make the bungee paratrooper tactic
totally go away, but it would constrain it.

This seems worth considering.

Re: Just say no to bungee paratroopers.

[Elijah Meeks]

--- Jim Kingdon <kingdon@panix.com> wrote:
> > So the transport gets to use the entire time of
> the turn and then each
> > passenger gets a full turn.
> > 
> > The fix is to count the transport's movement
> against the passengers as well.
> 
> That's a very interesting suggestion.
> 
> I guess in the case of an infantry in a bomber in
> the standard game,
> it would mean the bomber could move zero to two
> hexes, and the
> infantry would still have an ACP.  That's assuming a
> particular
> rounding rule - other ways of rounding would get
> 0-5, 0-3, or 0 only.
> 
> Assuming the 1-2 rule, it wouldn't make the bungee
> paratrooper tactic
> totally go away, but it would constrain it.
> 
> This seems worth considering.
> 


If this was introduced as a true/false table, it
should work fine.  This way it could be turned on in
cases where it made sense and left alone in games
where it doesn't.  Right?


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Wrecking Issues

[Elijah Meeks]

Is there any chance someone could patch the wrecking
code so that a half-built unit doesn't wreck into a
fully functional version of its wreck-type?  Maybe a
wreck-type-if-insufficient-cp or something?



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: Wrecking Issues

[Eric McDonald]

On Fri, 9 Jul 2004, Elijah Meeks wrote:

> Is there any chance someone could patch the wrecking
> code so that a half-built unit doesn't wreck into a
> fully functional version of its wreck-type?  

Sounds like a bug. I'll take care of it.

Thanks for the report,
  Eric

Re: Wrecking Issues

[Eric McDonald]

Elijah Meeks wrote:

> Is there any chance someone could patch the wrecking
> code so that a half-built unit doesn't wreck into a
> fully functional version of its wreck-type?  Maybe a
> wreck-type-if-insufficient-cp or something?

I just checked in what I think is probably a suitable fix. If the unit 
being wrecked is incomplete, then the damage code simply disposes of it.

If there are cases where this is unsuitable, then the alternative would 
be to make the change-type code (used by wrecking) to scale the wrecked 
type's CP to the unwrecked type's CP, in a manner similar to what is 
already done with ACP and HP. But, I'll leave the fix like it is for now.

Eric

AI Help

[Elijah Meeks]

Managing to build an AI that can function as well for
games involving zombies as it can for games involving
battlefleets is a daunting task.  I'm wondering,
though, if there's a way to take a little pressure off
the coders and put it into the hands of the designers.
 As it stands, the AI pretty much analyzes everything
and comes up with its own ideas based on that (With a
little help from tags like, 'air' and 'naval', but it
doesn't seem like much).  

So maybe there could be some Roshambo tables to give
the AI a little help.  I say Roshambo, or
rock-paper-scissors, because much of game design
follows a strategy of X beats Y.  You could have a
preferred-opponent table that reads something like
this:

(table preferred-opponent
   (infantry archers 100)
   (infantry infantry 75)
   (infantry cavalry 50)
   (infantry killer-robot 0)
)

This would be an override to the AI decision code, so
that in this case, if the infantry unit ever had a
chance to attack an archer unit, it'd take it, while
it would have a 25% chance to consider a different
course of action for other infantry units (Which may
still result in an attack, but may result in
continuing to move somewhere else or attacking a
different unit).  While a table like the example would
reduce XConq to mob warfare, a less aggressive table
like:

(table preferred-opponent
   (army place-types 15)
   (army aircraft-types 10)
   (army evil-dictator-types 20)
)

Would make the AI a little more opportunistic on the
unit level, where I see it avoiding easily destroyed
and expensive units in favor of, apparently, some
earlier plan.  This would also help with AI for some
more esoteric games, such as if you want to make
Zombies or the Borg or whatever and you want them to
be utterly singleminded:

(table preferred-opponent
   (zombies has-brains-types 100)
   (borg redshirt 50)
   (borg junior-officer 75)
   (borg important-guy 100)
)

I'm looking at this not from an ai-tactical-range
view, but from a purely adjacent, target of
opportunity view (Which may be a better name for this
table).

I think the idea would also be good for unit building,
to create a table that forces the AI to build based on
set guidelines, rather than overarching strategy.

(table ai-build-queue
   (city legion 50)
   (city fleet 10)
   (city facility-types 10)
   (city wonder 5)
)

Again, this would be a suggestion table, so that the
AI would first check through each of the entries and
if it came false, it would instead choose to build
what it wanted on its own.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: AI Help

[Hans Ronne]

>Managing to build an AI that can function as well for
>games involving zombies as it can for games involving
>battlefleets is a daunting task.  I'm wondering,
>though, if there's a way to take a little pressure off
>the coders and put it into the hands of the designers.
> As it stands, the AI pretty much analyzes everything
>and comes up with its own ideas based on that (With a
>little help from tags like, 'air' and 'naval', but it
>doesn't seem like much).
>
>So maybe there could be some Roshambo tables to give
>the AI a little help.  I say Roshambo, or
>rock-paper-scissors, because much of game design
>follows a strategy of X beats Y.  You could have a
>preferred-opponent table that reads something like
>this:

<snip>

>I think the idea would also be good for unit building,
>to create a table that forces the AI to build based on
>set guidelines, rather than overarching strategy.
>
>(table ai-build-queue
>   (city legion 50)
>   (city fleet 10)
>   (city facility-types 10)
>   (city wonder 5)
>)

I think there is a lot of merit to your suggestion. Basically, it would be
an extension of the side doctrines to cover more than just construction run
lengths and resupply trigger levels. This is something we already discussed
on the list, and I am in favour of it. In fact, I suggested something very
similar for the same reason: that the game designer usually has a better
idea of what various unit types are best at than the AI can ever have using
its standardized unit worth functions.

Hans

Re: AI Help

[Eric McDonald]

On Fri, 9 Jul 2004, Hans Ronne wrote:

> I think there is a lot of merit to your suggestion. 

As do I. And, these thoughts have certainly crossed my mind 
before.

Also, I have been contemplating weighted garrison tables, as well. 
I don't think it is enough just to set a few unit props that give 
a quantity. There should also be some way to determine proper unit 
types with which to garrison.

>Basically, it would be
> an extension of the side doctrines to cover more than just construction run
> lengths and resupply trigger levels. This is something we already discussed
> on the list, and I am in favour of it. In fact, I suggested something very
> similar for the same reason: that the game designer usually has a better
> idea of what various unit types are best at than the AI can ever have using
> its standardized unit worth functions.

I agree, even if it does take some of the fun out of trying to 
design good standardized unit worth functions... :-)

Eric

Re: AI Help

[Elijah Meeks]

> >Basically, it would be
> > an extension of the side doctrines to cover more
> than just construction run
> > lengths and resupply trigger levels. This is
> something we already discussed
> > on the list, and I am in favour of it. In fact, I
> suggested something very
> > similar for the same reason: that the game
> designer usually has a better
> > idea of what various unit types are best at than
> the AI can ever have using
> > its standardized unit worth functions.
> 
> I agree, even if it does take some of the fun out of
> trying to 
> design good standardized unit worth functions... :-)
> 
> Eric

I agree that the best solution would be AI code that
figured it out based on the game setup but I've
noticed that the AI is leery of building some units. 
In some cases won't build them for no discernable
reason, but will build them when you make what seems
to an unrelated change, as an example, in Korea-2006,
the AI refuseed to build Air Wings but, when I gave it
the option of building Air Defense Networks, it
suddenly started building Air Wings just fine (And
won't build ADNs).  I don't get it and I know it's
indicative of some internal procedure that should be
fixed, I'm sure, but a suggestion table would give it
a push in the right direction.

If the table was side-specific, that'd be great, but
if it was AI-specific, that'd be even better.  I'm
pretty happy with mplayer, but if you could have, say,
six mplayers, then you could use the tables to set up
mplayer-1 to be "naval-oriented", mplayer-2 to be
"armor-oriented", mplayer-3 to be "random".  It would
resemble, I suppose, something like this:

(set mplayer-1-name "Standard AI")
(set mplayer-2-name "Naval Oriented")
(table mplayer-2-build-preference
   (destroyer 50)
   (cruiser 25)
   (battleship 15)
   (carrier 10)
)

Just theorizing.




	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Side Selection Bugs

[Elijah Meeks]

There are two issues with side selection, both
regarding inactive sides:

1.  If a side is set to 'inactive' and you cycle
through the list of available sides once, then you'll
switch the AI to nobody after you've cycled past the
inactive side.

2.  If side #1 is set to inactive then starting a game
and hitting the 'exchange' button will result in a crash.


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Side Selection Bugs

[Hans Ronne]

>There are two issues with side selection, both
>regarding inactive sides:
>
>1.  If a side is set to 'inactive' and you cycle
>through the list of available sides once, then you'll
>switch the AI to nobody after you've cycled past the
>inactive side.

You should not be able to cycle into an inactive side (and you cannot in
those games that I tested). What may happen is that you cycle into the
Independent side which is usually hidden in the list. Click "Reveal
Indepside" to see what actually happens.

>2.  If side #1 is set to inactive then starting a game
>and hitting the 'exchange' button will result in a crash.

Anything that crashes the game is a bug by definition. Probably the bug in
this case is assigning the human player to side 1 by defualt without first
checking that it is active.

Hans

AWLS: Korea 2006

[Eric McDonald]

I did some playing on the updated Korean War game earlier. It seems that 
the American/S. Korean/Japanese alliance is now quite a bit stronger and 
more aggressive. The N. Koreans and Chinese have a much tougher slog 
than last time I played.

One thing that I noticed is that, for some reason, N. Korean armor 
cannot attack S. Korean armor, or so it seemed. Made it a bit of a 
nightmare trying to contain the S. Korean armor without taking massive 
infantry casualties. (A S. Korean armor had already broken through 
earlier and taken out N. Korea's only air support.) Aside from this 
problem (and some issues with ZOC's being exerted by unseen units, which 
is a Xconq problem, not a game module problem), the game seemed to be 
quite fun.

Eric

Re: AWLS: Korea 2006

[Elijah Meeks]

--- Eric McDonald <mcdonald@phy.cmich.edu> wrote:
> I did some playing on the updated Korean War game
> earlier. It seems that 
> the American/S. Korean/Japanese alliance is now
> quite a bit stronger and 
> more aggressive. The N. Koreans and Chinese have a
> much tougher slog 
> than last time I played.

Try it with the Aggressive China option, where half
the Chinese military just happens to be stationed on
the PRC/DPRK border.  I find that option, along with
turning off the American support, to make for a tough
game as Japan.  Of course, the American AI doesn't
send the Nimitz in, just the surface vessels, but if I
can't figure out why, I'll station it closer, until it
finally takes advantage of it.


> One thing that I noticed is that, for some reason,
> N. Korean armor 
> cannot attack S. Korean armor, or so it seemed. Made
> it a bit of a 
> nightmare trying to contain the S. Korean armor
> without taking massive 
> infantry casualties. 

I just looked through awls-rules.g and noticed that
the following line:

(armor-types armor-types 3)

was missing from the acp-to-attack table.  I'll check
in a fix tonight.

> Aside from this 
> problem (and some issues with ZOC's being exerted by
> unseen units, which 
> is a Xconq problem, not a game module problem), the
> game seemed to be 
> quite fun.

I'm glad you liked it.  The next one will be a ground
war between Russia and China, which should pose less
problems with the AI.

Elijah


		
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 

More Feedback on AWLS: Korea 2006

[Eric McDonald]

I see that Hans checked in the armor vs. armor stuff. That helped game 
play some.

One of the most annoying things that I am encountering now is Chinese 
units being garrisoned in N. Korean cities by the Chinese AI. This 
prevents the N. Korea player from producing anything since the 
capacities of cities seem to be 1. Perhaps they could be made to be 
larger; even 2 would be a big improvement as long as the damn Chinese 
don't hog both slots (set the 'ai-war-garrison' at 1) and actually let 
their ally produce something. I would actually garrison the cities with 
N. Korean forces if they had a greater capacity.

Also, the Kitty Hawk's improved carrier group seems to be pretty strong. 
I had a N. Korean coastal sub blasting it with torpedo after torpedo, 
but it didn't seem to be getting any weaker.

And, finally, it seems that the big American submarines can very easily 
dispatch coastal subs even if the coastal subs are striking first. 
(Perhaps the sub counterattack modifiers should be lowered to something 
less than 100% in the 'counterattack' table.) When I played the N. 
Korean side, I had a problem with the American subs coming up and 
attacking my one port city (with cruise missiles presumably, even though 
those would probably be classified as firing), and I really couldn't do 
a whole lot about it.

Eric

Re: More Feedback on AWLS: Korea 2006

[Elijah Meeks]

> One of the most annoying things that I am
> encountering now is Chinese 
> units being garrisoned in N. Korean cities by the
> Chinese AI. This 
> prevents the N. Korea player from producing anything
> since the 
> capacities of cities seem to be 1. Perhaps they
> could be made to be 
> larger; even 2 would be a big improvement as long as
> the damn Chinese 
> don't hog both slots (set the 'ai-war-garrison' at
> 1) and actually let 
> their ally produce something. I would actually
> garrison the cities with 
> N. Korean forces if they had a greater capacity.

I just tested this, and even if your city is occupied,
it should be able to produce ground units, because
places have a terrain size of 12, while units have a
terrain size of 50 (The unit, rather than being placed
in the city, would be placed in the same hex but
outside the city).  I'm loathe to have more than one
unit in a place, because of how XConq handles occupant
combat.  The problem that I see with this is in the
creation of new naval units, which need to be placed
in the city since, obviously, they can't go on the
ground.


> Also, the Kitty Hawk's improved carrier group seems
> to be pretty strong. 
> I had a N. Korean coastal sub blasting it with
> torpedo after torpedo, 
> but it didn't seem to be getting any weaker.

I'm going to create wrecked-type table entries for
sub-ship combat, to represent that a sub isn't
fighting a carrier air wing when it hits a carrier
group.  I've already done this with air wings and adns
in regard to damage from armor and infantry, (I'm not
sure if the most recent check-in has this, though).

There is, though, a method to this.  Trying to sink
the USS Kitty Hawk with a diesel sub is a poor bet at
best.
 
> And, finally, it seems that the big American
> submarines can very easily 
> dispatch coastal subs even if the coastal subs are
> striking first. 
> (Perhaps the sub counterattack modifiers should be
> lowered to something 
> less than 100% in the 'counterattack' table.) 

I think the US side has too many nuclear subs in
theatre.  But, again, those greenwater fleets that the
Koreans, Japanese and Chinese have are outclassed by
their nuclear counterparts.  It's part of the design
that an American nuclear submarine outclasses a
diesel-electric, but I think you're right, I've never
seen a nuclear sub sunk by one, and that should happen
occasionally.  I'd prefer that XConq allowed dice
larger than 13, because I'd give those coastal subs a
1d71-20 damage against all naval vessels, to represent
the very real possibility (Though improbable) of
scoring a critical hit on a capital ship.

The other possibility is to split up surface and
carrier groups, which are meant to represent a
collection of ships, and implement Destroyer
Squadrons, Cruisers and make the Carrier Air Wing a
seperate unit transported by Carriers, which gives you
a chance of sneaking your coastal sub through the
fleet and sinking (Or critically damaging) that damned
Kitty Hawk yourself.  It'd make more sense, because as
it stands there's only one carrier tech, which
theoretically improves both fighters and the carrier
itself, as well as better simulating battle, which
could wipe out a carrier air wing while leaving the
vessel itself unscathed (Right now Air Defense
Networks damage carriers, somewhat silly in certain
situations).  But, I have a feeling the AI wouldn't
deal so well with that.  

> When I played the N. 
> Korean side, I had a problem with the American subs
> coming up and 
> attacking my one port city (with cruise missiles
> presumably, even though 
> those would probably be classified as firing), and I
> really couldn't do 
> a whole lot about it.

That, to misquote Microsoft, is not a feature, but a
bug.  The subs in the game right now are all attack
subs, no boomers, so they should only be able to
attack naval units.  I'll make sure to fix it.

I'm implementing rules for nuclear weapons right now
(As an optional rule), which'll include the
introduction of missile subs, but I figured that
cruise missiles weren't militarily effective enough to
justify the trouble of modelling them.  I thought
about doing so with subs and surface fleets, giving
them a fire attack that consumed 'Cruise missile'
materials, but the AI doesn't like a unit that
utilizes both Attack and Fire.  The other option would
be to create a 'Cruise Missile Volley' unit that ships
could carry, but I find the inclusion of more than
four units in a hex or as occupants to be
aesthetically displeasing.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Re: More Feedback on AWLS: Korea 2006

[Eric McDonald]

Elijah Meeks wrote:

> I just tested this, and even if your city is occupied,
> it should be able to produce ground units, because
> places have a terrain size of 12, while units have a
> terrain size of 50 (The unit, rather than being placed
> in the city, would be placed in the same hex but
> outside the city).  

I wasn't seeing this, but maybe the cities were just out of materials. 
Those poor N. Koreans, you know....

> The problem that I see with this is in the
> creation of new naval units, which need to be placed
> in the city since, obviously, they can't go on the
> ground.

Right. And that was one of the worst cases. N. Korea only has one port 
city, and the moment a Chinese unit enters it that port is lost for 
naval (read, coastal submarine :-) production. And that somewhat 
diminishes N. Korea's ability to put S. Korean, Japanese, and American 
tonnage at the bottom of the Sea of Japan and E. China Sea.

> I'm going to create wrecked-type table entries for
> sub-ship combat, to represent that a sub isn't
> fighting a carrier air wing when it hits a carrier
> group.  I've already done this with air wings and adns
> in regard to damage from armor and infantry, (I'm not
> sure if the most recent check-in has this, though).

Sounds like a plan. Alternatively, you might be able to make an actual 
carrier air wing unit that can occupy carrier groups.

> There is, though, a method to this.  Trying to sink
> the USS Kitty Hawk with a diesel sub is a poor bet at
> best.

Is there some implicit ASW capabilities in the group, like a screen of 
picket ships or maybe some ASW choppers on the carrier's deck?

Even then, I think that might give an added detection boost against subs 
(choppers trawling sonar cans in the water, etc...), but if the sub does 
manage to get in and strike first, then what?

>>And, finally, it seems that the big American
>>submarines can very easily 
>>dispatch coastal subs even if the coastal subs are
>>striking first. 
>>(Perhaps the sub counterattack modifiers should be
>>lowered to something 
>>less than 100% in the 'counterattack' table.) 
> 
> 
> I think the US side has too many nuclear subs in
> theatre.  But, again, those greenwater fleets that the
> Koreans, Japanese and Chinese have are outclassed by
> their nuclear counterparts.  It's part of the design
> that an American nuclear submarine outclasses a
> diesel-electric, 

Sure. I understand that. The nuclear sub should be tougher and meaner. 
I'm not saying that the little diesel boat should be able to run up and 
blow it away in one or two pops, but the little sub shouldn't 
necessarily be guaranteed to die if it gets first strike, either.

> The other possibility is to split up surface and
> carrier groups, which are meant to represent a
> collection of ships, and implement Destroyer
> Squadrons, Cruisers and make the Carrier Air Wing a
> seperate unit transported by Carriers, 

I think the Carrier Air Wing is a good idea. It would decouple two 
different aspects of the present Carrier Group units, and save you from 
having to make a bunch more special wrecked types based on who does the 
killing.

>which gives you
> a chance of sneaking your coastal sub through the
> fleet and sinking (Or critically damaging) that damned
> Kitty Hawk yourself.  

Actually, I'm pretty much pro-Kitty Hawk, except when I'm playing "Kim 
Jung Il's advocate" (N. Korea is the default first side). Hopefully, 
I'll be able to make some time to play as some of the other sides later on.

It would be cool if the Russians were in the game. Then I could defend 
that one chunk of land on the Amur river (IIRC) that they and the 
Chinese skirmished over a few decades ago.

>It'd make more sense, because as
> it stands there's only one carrier tech, which
> theoretically improves both fighters and the carrier
> itself, as well as better simulating battle, which
> could wipe out a carrier air wing while leaving the
> vessel itself unscathed (Right now Air Defense
> Networks damage carriers, somewhat silly in certain
> situations).  But, I have a feeling the AI wouldn't
> deal so well with that.

It might do okay with it, if you allow carriers to produce carrier air 
wings over time.

> them a fire attack that consumed 'Cruise missile'
> materials, but the AI doesn't like a unit that
> utilizes both Attack and Fire.  

Hmmm... That seems odd. It should do okay in that situation. I guess I 
will have to make a new Windows installer, so that you can see whether 
Hans' victim finder and hit-unit improvements help things any.

One more thing that I forgot to mention earlier. It seems that the N. 
Korean cities can produce Carrier Groups but not Air Wings. That strikes 
me as a bit odd.

Eric

Re: More Feedback on AWLS: Korea 2006

[Elijah Meeks]

> > The problem that I see with this is in the
> > creation of new naval units, which need to be
> placed
> > in the city since, obviously, they can't go on the
> > ground.
> 
> Right. And that was one of the worst cases. N. Korea
> only has one port 
> city, and the moment a Chinese unit enters it that
> port is lost for 
> naval (read, coastal submarine :-) production. And
> that somewhat 
> diminishes N. Korea's ability to put S. Korean,
> Japanese, and American 
> tonnage at the bottom of the Sea of Japan and E.
> China Sea.

The build code has been changed the most throughout
the game, because there are certain combinations that
the AI likes and, because I use wreck-typing, there
were unforeseen consequences of build times over 1
turn in length.  As it stands, the AI doesn't build
military or civilian transports or carriers, but it
seems pretty good at building a good mix of everything
else.  Looking back on it, though, I should have made
sure to give cities a build-range of 1 (Or 2, I can't
remember if 1 is same hex or 1 hex adjacent) for naval
units.  I think I ran into a problem with this, but
I'll put it in and see.
 
 
> Is there some implicit ASW capabilities in the
> group, like a screen of 
> picket ships or maybe some ASW choppers on the
> carrier's deck?

The surface groups and carrier groups are considered
to have abstracted integral destroyer and cruiser
support.  At this scale, considering a coastal sub can
cover so much distance and make an attack in one turn,
it seemed good to give them such a high counterattack.
 On reflection, though, I think you've shown that
coastal subs deserve increased effectiveness, and I'm
going to tweak the rules a bit to give them a better
chance in the current ruleset.

> 
> Even then, I think that might give an added
> detection boost against subs 
> (choppers trawling sonar cans in the water, etc...),
> but if the sub does 
> manage to get in and strike first, then what?

snip

> Sure. I understand that. The nuclear sub should be
> tougher and meaner. 
> I'm not saying that the little diesel boat should be
> able to run up and 
> blow it away in one or two pops, but the little sub
> shouldn't 
> necessarily be guaranteed to die if it gets first
> strike, either.

I think with adding more nuance to the manner in which
units are detected, and tweaking attack values, that
there shouldn't be any counterattack for units
attacked by a sub of either type.  If you know where a
sub is, it's a pretty fragile piece of machinery, but
if you don't, it's not like it has to surface to fire.

Now, if the counterattack code took into account
see-chance, then I could give units a counterattack
chance that would be defeated by the fact that it
couldn't see the unit.  Right now, if I guage the
results properly, it doesn't, so removing
counterattack altogether against subs seems the best
course of action.

> I think the Carrier Air Wing is a good idea. It
> would decouple two 
> different aspects of the present Carrier Group
> units, and save you from 
> having to make a bunch more special wrecked types
> based on who does the 
> killing.

Oh happy day, the chance to make another 30 units!  As
the onetime advocate of 800 unit games, I have to say
it is a damn tedious process, but I think it's
justified in this case, Carrier Groups are simply too
abstracted right now.

> It would be cool if the Russians were in the game.
> Then I could defend 
> that one chunk of land on the Amur river (IIRC) that
> they and the 
> Chinese skirmished over a few decades ago.

I've been harassing Hans to give me a map of Eastern
Russia and China (He has a Mac, which apparently has
better design tools with the maps, which allows you to
crop pieces of, in this case, the earth-50km.g map),
with which the next scenario in the series will be a
major land war between Mother Russia and the Chinese
juggernaught (With the help of Kim Jong Il, leader of
a newly united Korea).

> One more thing that I forgot to mention earlier. It
> seems that the N. 
> Korean cities can produce Carrier Groups but not Air
> Wings. That strikes 
> me as a bit odd.

The North Koreans shouldn't be able to produce Carrier
Groups.  I thought I turned that advance off for their
side, I'll have to go back and check.  There's some
advance (I think 'Modern Surface Vessels') that needs
to be turned on or the AI won't build anything (I
don't know why), maybe that's it...

But Air Wings can only be produced in Aerospace
Facilities, which represent the infrastructure
necessary to produce modern jets.  Originally, Armor
Groups, Advanced Armor Brigades and Air Defense
Networks could only be built in Industrial Centers,
but the AI didn't like that, so they're all built in
cities, now.

What's noticeably missing is a tech tree for armor and
air.  It's not so big a deal with infantry, but the
North Koreans are fielding 30-50 year-old tanks and
any fighters that China produces can't really match up
with American and Japanese counterparts.  Right now I
abstract it by giving the North Koreans 'wrecked' and
'damaged' armor groups and their one Wrecked Air Wing
(Mostly, from what I've read, composed of Mig-17
Fresco, Mig-19 Farmer and Mig-21 Fishbed fighters),
but there should be at least three levels of Fighter
Wing and Armor Group, like the Carriers are now. 
Only, when you account for experience, that's another
120 units.  Did I say something about tedium...




		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Combat result tracking?

[Elijah Meeks]

I'm tweaking submarines in AWLS: Korea 2006, and I
thought, 'Gee, it'd be nice to know how many ships
they're sinking' so that I could just set all the
sides to AI and come back in twenty minutes.  But now
I'm thinking, this seems like a pretty good feature,
anyway, and I'd think it would be relatively easy to
implement.  Maybe just a number of units destroyed? 
Also, are there any plans to add a little depth to the
experience system?  It would be nice to give more or
less experience based on whether an attack was
successful or not.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: Combat result tracking?

[Eric McDonald]

On Tue, 13 Jul 2004, Elijah Meeks wrote:

> I'm tweaking submarines in AWLS: Korea 2006, and I
> thought, 'Gee, it'd be nice to know how many ships
> they're sinking' so that I could just set all the
> sides to AI and come back in twenty minutes.  

Xconq internally keeps track of some attack stats. It would be 
nice to report these things. I have been considering adding them 
to the help system, as some additional information in a side 
summary or with the individual unit information (for the side). 
Probably it would be better to have a separate stats window 
though.

> Also, are there any plans to add a little depth to the
> experience system?  It would be nice to give more or
> less experience based on whether an attack was
> successful or not.

I've thought about this too, and plan to do something about it at 
some point, unless someone else beats me to it.

Eric

Re: Combat result tracking?

[Hans Ronne]

>On Tue, 13 Jul 2004, Elijah Meeks wrote:
>
>> I'm tweaking submarines in AWLS: Korea 2006, and I
>> thought, 'Gee, it'd be nice to know how many ships
>> they're sinking' so that I could just set all the
>> sides to AI and come back in twenty minutes.
>
>Xconq internally keeps track of some attack stats. It would be
>nice to report these things. I have been considering adding them
>to the help system, as some additional information in a side
>summary or with the individual unit information (for the side).
>Probably it would be better to have a separate stats window
>though.

This is already available in the Mac interface. It has a History window
that keeps track of combat results etc.

Hans

Re: Combat result tracking?

[Eric McDonald]

On Tue, 13 Jul 2004, Hans Ronne wrote:

> This is already available in the Mac interface. It has a History window
> that keeps track of combat results etc.

Well, that's nice. Are you, by any chance, interested in adding 
this feature to the Tcl/Tk interface, the UI of choice for most of 
us non-Mac "peasants"?

Eric

Re: Combat result tracking?

[Elijah Meeks]

--- Eric McDonald <mcdonald@phy.cmich.edu> wrote:
> On Tue, 13 Jul 2004, Hans Ronne wrote:
> 
> > This is already available in the Mac interface. It
> has a History window
> > that keeps track of combat results etc.
> 
> Well, that's nice. Are you, by any chance,
> interested in adding 
> this feature to the Tcl/Tk interface, the UI of
> choice for most of 
> us non-Mac "peasants"?
> 

No no no!  Hans is only allowed to work on the SDL
interface.  Down with Tcl/Tk!!!

Whoa, sorry about that, I've been drinkin a lot of
coffee this morning...

I've achieved a minor victory, by the way, thanks to
your new wreck-typing table, Eric.  You had to
initialize units in order when you used the unit
property (wreck-type), now I don't, so all the
buildable units show up at the top of the Tcl/Tk list.




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: Combat result tracking?

[Eric McDonald]

On Tue, 13 Jul 2004, Elijah Meeks wrote:

> No no no!  Hans is only allowed to work on the SDL
> interface.  Down with Tcl/Tk!!!

I agree with the "down with Tcl/Tk". I have pretty much made up my 
mind that I am not going to bother becoming proficient enough in 
Tcl/Tk to improve that interface. I like learning new languages 
and everything, but__ I really feel that Tkconq is not worth the 
hassle. I plan on digging into SDL once 7.5 has been released.

> I've achieved a minor victory, by the way, thanks to
> your new wreck-typing table, Eric.  You had to
> initialize units in order when you used the unit
> property (wreck-type), now I don't, so all the
> buildable units show up at the top of the Tcl/Tk list.

That's good. It was kinda annoying having to scroll all over the 
place to pick out units.
Another way to achieve the same effect is not to set an unit's 
wrecked type when you first define it.
If you do something like:
  (add utype-1 wrecked-type utype-2)
after all of the unit types have been defined.

Eric

AI Motivation for non-combat units

[Elijah Meeks]

I'm in the middle of implementing Carrier Air Wings in
AWLS, and I just wondered, is it worth it?  Once I'm
done, carriers will no longer have an Attack or Fire
Attack, so doesn't this mean the AI won't use them as
a combat unit?  I know it doesn't deal with transports
well, but if I allow for disembarking of Carrier Air
Wings (A somewhat logical event), won't it just bump
into some piece of land somewhere and dump them right
next to a Crack Reinforced Armor Group?

Any hints on how to tag a Carrier so that the AI deals
with it well after it's lost its attack?  Should I
leave it with a minor Attack or Fire Attack?


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: AI Motivation for non-combat units

[Hans Ronne]

>I'm in the middle of implementing Carrier Air Wings in
>AWLS, and I just wondered, is it worth it?  Once I'm
>done, carriers will no longer have an Attack or Fire
>Attack, so doesn't this mean the AI won't use them as
>a combat unit?  I know it doesn't deal with transports
>well, but if I allow for disembarking of Carrier Air
>Wings (A somewhat logical event), won't it just bump
>into some piece of land somewhere and dump them right
>next to a Crack Reinforced Armor Group?
>
>Any hints on how to tag a Carrier so that the AI deals
>with it well after it's lost its attack?  Should I
>leave it with a minor Attack or Fire Attack?

I would suggest copying the Flattops game as far as possible. It is one of
the best working Xconq modules, and it handles carriers very well.

Hans

Re: Combat result tracking?

[Hans Ronne]

>On Tue, 13 Jul 2004, Hans Ronne wrote:
>
>> This is already available in the Mac interface. It has a History window
>> that keeps track of combat results etc.
>
>Well, that's nice. Are you, by any chance, interested in adding
>this feature to the Tcl/Tk interface, the UI of choice for most of
>us non-Mac "peasants"?

I doubt it would be worth the trouble. The Mac interface has many features
that I never use, and this is one of them. I think it would be more useful,
particularly to game designers, if the output was saved to a file so that
you could examine it afterwards. You do of course have the saved history
events in the game file, but the History window output is more
human-readable.

Hans

P.S. I share the view that we should limit our work on the tcltk interface.
But then I said so already two years ago, and I have hacked the tcltk code
a lot since then :-).

Re: Combat result tracking?

[Skeezics Boondoggle]

On Tue, 13 Jul 2004, Hans Ronne wrote:

> P.S. I share the view that we should limit our work on the tcltk interface.
> But then I said so already two years ago, and I have hacked the tcltk code
> a lot since then :-).

as long as we poor unix users aren't completely left behind... the tcltk
interface is playable even on my somewhat beefy sparc 20 (4x125mhz) as
long as you're careful with "click-ahead"; it's plenty fast on my ultra2
(2x300mhz).  i can't believe that anyone with a nGhz ppc or x86 box would
have any performance complaints even with the tcltk version, but if sdl is
faster/better/sweeter smelling/easier to build, then i'm all for it.

seems there's been so much going on lately, and so many new features and
bug fixes getting rolled in i haven't done a solaris build in quite some
time.  but i suppose i ought to try out the sdl version and see what state
that's in, if it's buildable on solaris and if there's any feedback to be 
given...

-- chris

Re: Combat result tracking?

[Eric McDonald]

Hi Chris,

Skeezics Boondoggle wrote:

> On Tue, 13 Jul 2004, Hans Ronne wrote:

> as long as we poor unix users aren't completely left behind... 

As long as you guys are still out there, I am interested in supporting 
your platforms. Unfortunately, I have to rely on the feedback of others 
to support non-Linux systems, since I don't have any working Sparcs, 
etc... right now. (I do have an old version of Solaris for x86 floating 
somewhere; I suppose I could try installing that in a virtual machine 
and see what happens.)

As far as SDL goes, it looks like you might have to build it from source 
on Solaris boxen. I didn't see any Solaris binaries at http://www.libsdl.org

>the tcltk
> interface is playable even on my somewhat beefy sparc 20 (4x125mhz) as
> long as you're careful with "click-ahead"; it's plenty fast on my ultra2
> (2x300mhz).  i can't believe that anyone with a nGhz ppc or x86 box would
> have any performance complaints even with the tcltk version, but if sdl is
> faster/better/sweeter smelling/easier to build, then i'm all for it.

For me, the main advantage to the SDL interface would be not having to 
hop back and forth between Tcl and C, which is a slight PITA when doing 
development and debugging, IMO. Also, in terms of configure/make, I have 
had to do quite a bit a work to support the building of Tkconq on 
diverse platforms, because different '{tcl,tk}Config.sh' set different 
important variables on different platforms. The 'sdl-config' scripts are 
much more uniform in the way they report things. Another consideration 
is that Tkconq is not a pure Tk app; it has some raw X11 calls as well, 
and this has led to deficient functionality on non-X11 platforms.

I wouldn't classify the performance of the Tcl/Tk interface as being 
totally smooth under Linux on my 1.4 GHz Athlon XP+. In a virtual 
machine (on the Linux host) running Windows XP, the performance is not 
that good at all (I haven't tried improving the nice level of the VM to 
see how is just a result of the lack of scheduler attention, though).

> seems there's been so much going on lately, and so many new features and
> bug fixes getting rolled in i haven't done a solaris build in quite some
> time.  but i suppose i ought to try out the sdl version and see what state
> that's in, if it's buildable on solaris and if there's any feedback to be 
> given...

That would be great. I also did a pretty massive overhaul of the 
configure/make stuff, and I would like to know if anything broke on Solaris.

   Thanks,
     Eric

Counterfire

[Elijah Meeks]

There was some discussion of giving units the ability
to do counterbattery work (A unit fires and then
another unit with enough ACP and in range returns
fire).  I'd love to see a 'counterfire' table and an
'overwatch' table, which would be something akin to
counterfire, except that the responding unit would
actually fire first with effects (Unit destruction,
ACP-to-defend) that may cancel the initiated attack.

So how much of a pipe dream is this?


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Re: Counterfire

[Eric McDonald]

Elijah Meeks wrote:

> There was some discussion of giving units the ability
> to do counterbattery work (A unit fires and then
> another unit with enough ACP and in range returns
> fire).  I'd love to see a 'counterfire' table and an
> 'overwatch' table, which would be something akin to
> counterfire, except that the responding unit would
> actually fire first with effects (Unit destruction,
> ACP-to-defend) that may cancel the initiated attack.
> 
> So how much of a pipe dream is this?

Well, I think it is primarily an issue of finding time to explore these 
ideas further and write some code. As far as the overwatch concept was 
concerned, this could probably best implemented in terms of the existing 
ZOC, or perhaps some new type of zone, maybe a zone of overwatch (ZOO?), 
which would have a max range defined by a table, but would also be 
limited by the unit's vision range.

Currently, I am working on an extension of the help system, which allows 
help files to be automatically generated for every game in the Xconq 
games library. The help files can be produced in either plain text or 
HTML format. I am also making the framework generic, so that support for 
other formats can easily be added in the future. I still have a lot of 
work to do on this, so I will probably be occupied with it for the next 
few weeks. When I finish, I will put all the HTML help files for all the 
games in the library on the Xconq Web site.

Eric

Re: AI Help

[Jim Kingdon]

> I'm wondering, though, if there's a way to take a little pressure off
> the coders and put it into the hands of the designers.

Seems like a good thing to have.  I especially like the idea of being
able to tweak the AI with some parameters, and play the resulting AI's
against each other.  That's the big problem with oplayer/mplayer/etc -
it is just too hard to create new AI's so we haven't really been using
the different AI's to experiment with different techniques.

I do kind of wonder whether the designers will necessarily make the
most advantageous choices.  Did the designers of the standard game
anticipate that the optimal strategy was to build no ships, for
example? (in my experience that is true, although of course I could be
biased from too much play against the AI and almost none against
humans).

Re: AI Help

[Hans Ronne]

>> I'm wondering, though, if there's a way to take a little pressure off
>> the coders and put it into the hands of the designers.
>
>Seems like a good thing to have.  I especially like the idea of being
>able to tweak the AI with some parameters, and play the resulting AI's
>against each other.  That's the big problem with oplayer/mplayer/etc -
>it is just too hard to create new AI's so we haven't really been using
>the different AI's to experiment with different techniques.
>
>I do kind of wonder whether the designers will necessarily make the
>most advantageous choices.  Did the designers of the standard game
>anticipate that the optimal strategy was to build no ships, for
>example? (in my experience that is true, although of course I could be
>biased from too much play against the AI and almost none against
>humans).

True. One could of course implement this as setup options. The main problem
in that case is that you also have to write new interface code, and we have
several interfaces. Just adding a new doctrine or GDL table that is set
from within the game file is much easier.

Hans

Re: AI Help

[Jim Kingdon]

> True. One could of course implement this as setup options. The main problem
> in that case is that you also have to write new interface code, and we have
> several interfaces. Just adding a new doctrine or GDL table that is set
> from within the game file is much easier.

Agreed on this.

Just because game designers might get things wrong isn't a reason to
avoid having the feature.

Sure, I can imagine all kinds of future directions (e.g. a GUI
doctrine editor, decoupling the doctrine from the game design, etc),
but we need to start somewhere, and putting the hints in question into
doctrine or GDL tables is the right place to start.

Re: Just say no to bungee paratroopers.

[Hans Ronne]

>> > The fix is to count the transport's movement
>> against the passengers as well.

>If this was introduced as a true/false table, it
>should work fine.  This way it could be turned on in
>cases where it made sense and left alone in games
>where it doesn't.  Right?

I think any change to the basic action/move code would have to be
implemented as a GDL option, in order not to break existing games.

Regarding this particular idea, there are some problems due to how the
kernel works. The kernel doesn't count "time" or movement points. Instead,
it counts action points (acps). if you want to limit the ability of an
occupant to move because its transport already moved, you would have to
bleed off its acps. Now, that would work fine in games where units have
many acps and use one per move. However, a more common situation is that
the unit only has one or two acps, and is able to move several cells using
one acp (how far is determined by the GDL variable speed). In that case,
the unit might not be able to move at all if you take away an acp.

Another problem is that operting ranges are important, both in the task
execution code and in the AI code. And some of the derived variables are
precomputed to save time. I think that with the proposed hack we would see
many more messages of the type "Your fighter has run out of fuel and
crashed."

Then there is the point I already alluded to, and that is that being able
to do rapid forward deployments makes most games more interesting. There is
nothing more boring than a stalemate "West Front" trench war situation.

I am not saying that a transport hack is impossible, but it would take a
lot of work to get it right. I think that in the case of the galaxy2 game,
the basic problem is that planets are to esy to capture, regardless of how
you go about it. For the bungee paratroopers that this thread started with,
the obvious fix would seem to be to require that they leave the bomber
before being able to attack. This is, after all, how real paratroopers work
(jump first, then shoot). And there is already a GDL variable,
occupant-combat, which can be used to limit the ability of occupants to
fight. Setting it to 0 instead of the default 100 for (infantry bomber)
should do the trick.

Hans

Re: Just say no to bungee paratroopers.

[Jim Kingdon]

> Then there is the point I already alluded to, and that is that being able
> to do rapid forward deployments makes most games more interesting. There is
> nothing more boring than a stalemate "West Front" trench war situation.

Good point.

All too many xconq games verge on this problem already ("yeah, I'm
pretty sure I'll win, but it is too boring to prove it"), so we should
be wary of anything which might make it worse.