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 it. Brian ----- 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, 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/ > > _______________________________________________ > vanilla-list mailing list > vanilla-list at us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list >