I actually started coding away. As I intend all 'bots to function as
appendages to a single unit, I've had to take a look at socket code.

Almost all of it will have to re-written. The reason? Almost all the
code assumes access to global variables. With up to 8 players
functioning from a single process, this simply will not do.

This isn't as bad as it seems. The only reason the current code is so
complicated, I believe, is due to the large amount of legacy code that
is interspersed with new code. Even after years of evolution, while
the code definately looks a lot prettier in many areas, one can see
remnants of xtrek. Other insertions into the code, such as colourful
language under certain conditions, remain mildly amusing. :-)

The code will be broken into layers, with each layer represented by
one or more thread. The kernel will be used to schedule the priorities
of the layers, to allow the code itself to be as streamlined as
possible. As a sample for how this will work, ranking tentative layers
from highest priority to lowest priority:

    - data processing
       + will take data off the server sockets, populate the client
         specific structures, then update the global structures.
       + will notify other layers of interesting observations that may
         warrant more immediate attention.
    - combat engine (may be broken up if responsiveness would not suffer)
         NOTE: Any of these functions may be specifically disabled by
               the targetting layer on a ship by ship basis.
       + will ensure that the shield is up when advantageous, and down
         when advantageous. (shield takes up fuel and does not allow hull
         damage to be repaired)
       + will deal with temporary overrides to velocity to evade torps,
         plasmas, or phaser range for all ships. The preference is to
         maintain the target velocity. If a combat excursion affects
         the ability for a ship to arrive at a target on schedule, the
         targetting layer will be notified.
       + will tractor/repress team mates to effect lateral movement, and/or
         to temporarily improve acceleration.
       + will tractor/repress enemies orbitting a planet that may offer them
         an advantage. Advantages include, but are not limited to: beaming
         down armies, beaming up armies, bombing, making use of a
         friendly repair resource, making use of a friendly fuel resource,
         moving away from our position around the orbit of the planet.
       + will tractor/repress enemies to adjust enemy positions to
         be more suitable. This would include pressing a ship closer to
         a team mate to allow them to phaser the ship, pushing them closer
         to a torp stream or plasma that would otherwise miss because the
         player altered course unexpectedly, to pull a ship closer for any
         of these reasons, to press or tractor a ship away from one of our
         own if it is scheduled to explode.
       + will schedule torp patterns for all ships.
       + will schedule phaser blasts for all ships. This may include
         phasering an enemy plasma, if it judged that it's trajectory
         puts it in line with one of our ships that cannot dodge, or
         does not wish to dodge. The enemy plasma may also be phasered
         if it is in proximity to another enemy ship.
       + will schedule plasma shot for all ships.
       + will schedule the detonation of enemy torpedoes by all ships
         to minimize damage for the entire unit. (i.e. less valuable
         ships will choose to accept damage before more valuable ships -
         if two ships are escorting, they may take turns detonating to
         ensure that they both continue living)
       + will detonate any specific torpedoes that will not do damage, if
         it is judged that a new torpedo may be necessary by the next update,
         and the 'targetting computers' have reached the limit of 8
       + will cloak if advantageous, or uncloak if advantageous.
       + will toggle between repair/maxwarp if hull damage is present,
         and it is possible to maintain the target velocity.
       + if especially damaged, the ship may enter repair state. The
         targetting layer will be notified.
    - targetting
       + will accept list of objectives from strategy layer, and determine
         among our available set of ships, which is capable of best
         achieving the top few set of objectives. Several ships may be
         assigned to an objective, or one ship may be assigned to an
         objective. If an objective is not possible, either because certain
         criteria are not met (i.e. to take the planet, at least one
         of our ships needs to obtain a few kills and beam up some armies),
         the objective may be temporarily overlooked, or the criteria
         may be tackled.
       + ships will be assigned specific courses, velocities. The targetting
         layer will perform ship synchronization, as for example, ogging of
         an SB.
       + once a target is achieved, the targetting layer may perform an
         action of its own. For example, if a target is 'lock on Den', then
         when the ship arrives at Den, the targetting layer may initiate
       + the targetting layer may perform tactical suicide. If an enemy
         bomber is near the home planet, the targetting layer may instruct
         an especially damaged ship with few kills or armies to cruise
         into a torpedo stream, or orbit a nearby enemy planet.
    - defensive analysis
       + will analyze motion and actions of enemy ships, attempting to
         discern enemy targets, potential enemy targets, or enemy ships
         that should be eliminated (they may have armies, or kills, or they
         may be too powerful (SB), or they may be too causing us trouble).
         Summary is in the form of a list of objectives, such as 'guard Den',
         'ogg F7', 'escort R5'.
         The objectives will be a little more detailed, such as:
             'guard area (x1, y1)-(x2, y2) stationed around (x3, y3)'
             'escort R5 (dx1, dy1)-(dx2, dy2) stationed around (dx3, dy3)'.
       + if interesting information is available, the strategy layer may
         be notified
    - offensive analysis
       + will analyze the existing set of planets and enemy ships, to
         determine the order that the planets should be taken.
       + if interesting information is available, the strategy layer may
         be notified
    - strategy
       + will take objectives from offensive analysis and defensive analysis,
         weigh them, vary them according to experience, and present the
         combined list that is used by the targetting layer.

At each stage, several strategies may be employed, or variations of
several strategies may be employed. Characteristics of enemy players
will be maintained to ensure that a strategy that rarely succeeds
against a certain player, will not be employed again. This applies to
general strategy, but it also applies to such things as torpedo

Traditional robots employ a single algorithm for launching
torpedoes. While the algorithms used are often quite difficult to
combat, for especially clued players, patterns can be determined and
exploited. As an example, a clued player may find that it is easier
for their style of play to kill a robot by plinking them. In this
case, the robot would take note of this, and *all* robots may choose
to get into close quarters when combatting that specific player. They
all 'learn' from each others mistakes, allowing the team to quickly
adapt even with no prior history.

Certain players may be judged as being exceptionally excellent
dog-fighters, in which case, a single bot would avoid ever being on
the same tactical screen as the player, and the team would only ever
attack the player if two or more robots were available. All of these
observations will take into account the class of ships. I.e. perhaps
the SC would realize that it should never go against "Captain Ogger"
if he has a BB, but with BB vs. BB, the robot is safe. In this case,
all SC's would give "Captain Ogger" an extremely wide berth, while all
BB's would go straight in for the kill.

Also, the robot team would not assume that 'ability to kill' a player
means success. If the robot ship is left crippled, or out of fuel,
this is not a success. If, in the above case, the SC robot could
destroy "Captain Ogger" every time, but always be left with an empty
tank of fuel, the SC robots would still give "Captain Ogger" wide
berth, although perhaps not as wide of one. Robot plinkers can be just
as effective as human plinkers... :-)

After I have a functional baseline, or even before, does anybody want
to help out?


mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...