Re: Bugs in Bellum Aeternum

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On 23 Sep 2003, Lincoln Peters wrote:

> I finally got CVS to work by deleting my entire "xconq" tree and then
> re-checking it out.  I can see some practical uses for the vanishes-on
> table (e.g. infantry in the deep ocean), but this is not one of them.

It was useful in finding the "unit leaves road, crosses illegal 
terrain to get to legal transport" bug. But, like I said, I have 
had most of that table disabled for some time, so you should not 
have been seeing the vanishing behavior with any checkout over 
the past few weeks.

> 4. Ruins exert ZOC, and in doing so prevent aircraft from flying over
> them.  That doesn't seem right.

Well, independent ruins should allow aircraft into them.
As far as hostile ruins go, who is to say that occupation forces 
are not using them for a (rather shabby) depot or base of 
operations? In that case, aerial defenses might be present.  I 
don't know, I'll think about it some more. I actually did consider 
what you are suggesting during the design of the module.

> 5. Attacking bombers, dive bombers, etc. have a chance to retreat when
> *attacking* a capital.  I think that this would only make sense when the
> bombers are themselves under attack, or if they (foolishly) try to
> attack fighters.

Yes. I thought I had that behavior ironed out at some point. I'll 
see what I can do.

> 1. It's somewhat difficult to keep track of all of the different
> materials.  Although that may be a problem in Xconq itself rather than
> your game (I had the same problem with space-civ.g).

My module does have quite a few materials. It was my experience 
that, aside from command and control ('c'), they form a backdrop 
econcomy that you can usually ignore. One thing I could do to aid 
tracking would be to define the most important ones first so that 
they get displayed in the top row (of the Tcl/Tk info window), 
which generally does not get clobbered with other text.

> think that you could, at the minimum, use doctrines to prevent immobile
> producers (bases, towns, cities, et al.) from complaining if they run
> low on 'c'.

I thought that I had already cranked the resupply and rearm 
percentages down to 0 for facility types, but I will double check 
when I get home from work.

> 3. It might be helpful if there was a way to simplify all of the various
> grades of battleships into one unit-type, and simplify all of the
> various grades of aircraft carriers into one unit-type.  However, last
> time I looked, that was beyond the capabilities of Xconq.

Are you thinking in terms of some sort of class-subclass 
relationship, or do you have something else in mind?

I will agree 
that {frigate,cruiser,battleship} and {escort carrier,light 
carrier,fleet carrier} basically form a price-performance 
continuum (aside from special command-and-control production 
among the heavier members of each set).

> 4. As it is set up now (unless things have changed since my last CVS
> update), armor has a 5% chance of success to capture a capital with each
> attack.  No other units can do this.  Is the idea of the game that a
> side persists until its capital is destroyed (or surrenders), or until
> its capital is overrun?

Yes, unless you turn on the "Stubborn Sides" variant, in which 
case some other units can continue the fight after the Capitol 
falls.

Capitols are not meant to be easy to take or destroy. You 
correctly note that only Armor has enough oomph (and just barely) 
to make a successful capture attempt against a Capitol. I have not 
added a Stormtroopers unit type, but if I do, then it will also 
have that ability. The question is, does the module need yet 
another land unit type?

> 5. There should be a way to clear ruins.  

I have been contemplating adding a disband table entry to 
accomplish this.

>They get in the way when I try
> to germinate.  It would also be interesting if one side could gut an
> enemy town and build a grand citadel where the town used to be.

Yes.
And once the type change mechanism is fully functional, there will 
be the ability to evolve town->city->metropolis, which should help 
make things even more interesting.

So you like Grand Citadels? Do you think they are too powerful or 
too cheap (compared with Towns)?

>    The way I handled it in one of my projects (bolodd.g, which might
> appear in the unfinished games library fairly soon) was that ruins were
> always independent, but engineers could attack them and inflict 6d6
> damage per hit, clearing them much faster than non-engineers could (they
> rarely inflict more than 1d6 damage with each hit).

I thought I had given Engineers an advantage against them, but 
maybe that was just against mines....

Another way to handle this is to make Ruins' hp-max small (like I 
had it during most of the alpha phase), and just arrange things so 
that they have a hp-min = hp-max when versus all units except 
Engineers. That way only Engineers could destroy them. This is 
actually the direction I am thinking about heading, provided that 
part of Xconq actually works....

> 6. There should be an easy way to give orders such as "move to within 3
> of x,y; then wait for a friendly transport ship with less than 6
> occupants to move to x,y; then move to x,y."  I could probably do it
> using standing orders (although I'm not sure that standing orders could
> easily work here with *any* transport ship), but there should be a
> simpler way.

Agreed. I think Bruno Boettcher expressed a similar desire on this 
list several months ago.

> 7. There should be a relatively simple way to visualize the supply
> system.  Perhaps a color could be assigned to each material, then an
> option under the "View" menu could be used to display the supply using
> alphablending?  If I haven't made this idea clear, I could try to send a
> picture.

Good idea.

> 9. When the game gets really big, it becomes less desirable to
> micromanage units that are not on the front lines.  One thing that can
> become annoying is that, if I want a bunch of ground units to meet one
> or more transport ships, it is often necessary to use several separate
> "move" actions, since the pathfinding algorithm is so brain-dead.

One of the things I am going to propose to the community after 7.5 
is released is the idea of being able to set waypoints with the 
click of the mouse (or by the traditional move-to) and have them 
visually indicated whenever a relevant unit (one that is 
following the set of waypoints) is selected.

> 11. Once a unit's "SupplyLow" flag is up due to being less than half
> full of one supply (e.g. 'c'), and you give it an order, it will not
> stop for further instructions even if another, even more important
> supply (e.g. 'f1') runs low.  (I say "more important" because, although
> no unit can function without 'c', running out won't kill it, whereas
> running out of 'f1' would kill any aircraft)

Good observation.

  Thanks,
    Eric