I'm not sure you really want to do that.  One strange seg fault could crash
the whole system.  A better approach is to have the brains of the operation
be a separate process that each of the bots communicate with.  This would
allow you to put the bot brains on to a separate machine (for CPU reasons)
and then divide the bots up on to other machines.  If one bot crashes, you
don't lose 7 others along with it.

Also, you then don't have to worry about people using global variables.
Cleaning up the code is going to be a major project and really isn't worth


----- Original Message -----
From: "Mark Mielke" <mark at mark.mielke.cc>
To: <vanilla-list at us.netrek.org>
Sent: Sunday, December 09, 2001 10:52 PM
Subject: [Vanilla List] organized, intelligent 'bots

> 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,
>          to temporarily improve acceleration.
>        + will tractor/repress enemies orbitting a planet that may offer
>          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
>          and the 'targetting computers' have reached the limit of 8
>          torpedoes.
>        + 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
>          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
>          the objective may be temporarily overlooked, or the criteria
>          may be tackled.
>        + ships will be assigned specific courses, velocities. The
>          layer will perform ship synchronization, as for example, ogging
>          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',
>          when the ship arrives at Den, the targetting layer may initiate
>          bombing/beamup/beamdown.
>        + 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
>          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
>          'ogg F7', 'escort R5'.
>          The objectives will be a little more detailed, such as:
>              'guard area (x1, y1)-(x2, y2) stationed around (x3, y3)'
>          or:
>              'escort R5 (dx1, dy1)-(dx2, dy2) stationed around (dx3,
>        + 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
>          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
> patterns.
> 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
> --
> mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   |
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario,
>   One ring to rule them all, one ring to find them, one ring to bring them
>                        and in the darkness bind them...
>                            http://mark.mielke.cc/
> _______________________________________________
> vanilla-list mailing list
> vanilla-list at us.netrek.org
> https://mailman.real-time.com/mailman/listinfo/vanilla-list