Re: Bugs in Bellum Aeternum

[Lincoln Peters <sampln at sbcglobal dot net>]

On Wed, 2003-09-24 at 19:30, Eric McDonald wrote:
> > 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.
> 
> Yes. Do you think it is too small? It is a 1 in 20 chance, iirc, 
> and if you bring enough armor for the task, probability is that 
> the Capitol will fall sooner rather than later....

It seems fine if that's what you want.  And there isn't anything wrong
with doing it that way.

I think that the reason that I was somewhat confused by it was the first
time I played it, I swarmed a bunch of armors around the capital and
started pounding.  When that 1 in 20 chance finally came around, the
game ended quite abruptly (at least it was abrupt in comparison to most
other games).

> 
> > > 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.
> 
> Agreed. :-)
> 
> > It looks like engineers can try to clear mines and shipwrecks, but they
> > can't do anything to ruins.
> 
> Yeah, I noticed that when I looked at the module yesterday. I 
> guess the computer forgot to record that thought when I had it....
> 
> > I think I tried using hp-min once, and it worked.  Although that was a
> > while ago.
> 
> Well, if you are still kicking Bellum's tires, I am now using it 
> for Ruins, so you can see if it still works.

I see.  I haven't tried to blow up any ruins yet, but it looks like I
could.

> 
> > 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.
> 
> I think these are good ideas. 

One more thing regarding standing orders and such automation mechanisms:
I ran into a situation where there was a severe shortage of 'c' at the
front lines, despite the presence of a Field HQ unit.  It would be nice
if I could set a condition (perhaps that its supply of 'c' drops below
25) under which it would move to a predetermined place (most likely a
metropolis), resupply 'c', then return to its previous location.

On the other hand, maybe I'm just not swarming enough Field HQ units to
keep up with my other swarms.

> 
> > 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 idea I have, regarding waypoints, would be to allow them to be 
> assigned to units/transports and not just fixed coordinates.
> 
> > 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!
> 
> But, if you send an Engineers into a Ruins, then the Ruins should 
> be able to perform a disband action, because the Engineers doubles 
> (in theory, haven't tested this yet) the Ruins' ACP, thereby 
> giving it 2 ACP, which should be sufficient to do a disband.

The only problem I can see there is that the engineers might vanish
along with the ruins.  Although I haven't tried it.

What I did in bolodd.g was:

* Ruins are always independent (they aren't useful for *anything*).
* They start with 50HP.
* They lose 1HP per round (as per attrition).
* They can be attacked and suffer damage comparable to what an attacker
would inflict on a base (usually 1d6).
* Engineers, however, inflict 6d6 damage vs. ruins with every blow, and
so they can clear ruins very quickly.
* Finally, engineers don't require any ammo to attack ruins.

> 
> I was going to test this RSN (I checked it in yesterday, 
> because I thought there was a good chance that it would work, and 
> it wasn't harming anything if it didn't). 
> 
> Also, once the Ruins gets down to 2 HP, you should be able to 
> withdraw the Engineers and let the Ruins finish itself off. 
> Obviously this is also untested, and there is a higher chance that 
> this might not work correctly, since I haven't looked at the 
> interpolation-list code in a while.

I think it would work, but there is probably an easier way.  See above.


Two more small things:

1. This is probably beyond the current capabilities of Xconq, but it
would be nice if there was a way to prevent two sides from starting on
the same continent.  When they do, the game often ends too quickly for
anyone to build a grand citadel, a fully-loaded fleet carrier, etc.

2. It looks like a name is assigned to every capital, but the only time
Xconq refers to a capital by name is when it is captured (the rest of
time it's refered to by coordinates, e.g. "your capital at x,y").  It
might be useful for Xconq to refer to capitals by name, especially if a
game has lots of sides and consequently toward the end, a few sides have
a lot of captured capitals (if nothing else, I could easily find a
specific capital using the "Find" command).