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
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 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
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 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)'
or:
'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
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, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/