Re: Bugs in Bellum Aeternum

[Lincoln Peters <sampln at sbcglobal dot net>]

On Tue, 2003-09-23 at 13:17, Eric McDonald wrote: 
> 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.

And I can now see that vanishes-on is no longer used.

> > 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.

A better solution might be if the occupants of the ruins exerted ZOC,
rather than the ruins itself.  I've never tried it, so I don't know if
it would work.

> > 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.

I was thinking that it might be useful to have finer control over the
supply system.  For example, I might want a base to give higher priority
to aircraft when supplying fuel, since they would die without it.

> > 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).

I recall that the Game Designer's Manual indicated that this kind of
variation between different units could, in theory, be done with a
single unit type (the example I remember was young dragons and old
dragons).  On the other hand, it doesn't seem to work as well in
practice as it does in theory.

> > 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?

What I was thinking was that, in most games, the capital is fairly easy
to capture if it is not well-garrisoned.  However, in a few games
(insect.g comes to mind), the only way to defeat another side is to
destroy its capital.  I wasn't sure if you wanted it to be set up so
that there would be that small chance of successful capture.

> > 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.

I've been waiting for that, too.  The bolodd.g module I sent to Hans
recently had all sorts of problems that stemmed from that it had to use
a time.g-like upgrade mechanism where change-type would be more
appropriate.

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

Well, they're certainly not cheap, but in the long run, they give far
better results than a simple town.

> >    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....

It looks like engineers can try to clear mines and shipwrecks, but they
can't do anything to ruins.

> 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....

I think I tried using hp-min once, and it worked.  Although that was a
while ago.

> > 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.

Looking back at his e-mail, I can certainly see the advantages to a more
powerful standing orders mechanism.  Particularly if it could:

* Distinguish between a specific (perhaps named) unit and any unit of a
particular type (e.g. should the dive bomber occupy *any* aircraft
carrier, or only a particular carrier?).

* Allow users to selectively apply standing orders to specific units.

* Allow defensive units (e.g. fighters) to respond immediately when a
hostile unit (e.g. bombers) is sighted within r units of the place it's
defending.

* Perform a task involving a unit or location that is unknown at the
time that the order was given (e.g. a patrolling fighter cannot know
ahead of time where enemy bombers will be sighted).

* Disregard previously-declared standing orders.

Perhaps some of these are already possible, but the existing
documentation is quite vague.

> > 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.

I think that, as Hans said, an improved pathfinding algorithm that could
actually find the fastest route would be the best solution.  Although
using waypoints in conjunction with standing orders might eventually
yield more effective possibilities for automated patrolling units.


One last thing I noticed is that, as of when I last updated from CVS
(about 10 minutes ago), ruins now get 1 ACP per turn.  However, there is
nothing I can tell that they can do with that ACP!