Chapter 31: Robotic Combat

Robots cannot easily engage in combat. No robot, unless otherwise noted, may harm its base anthro type, or in any way allow that base anthro type to come to harm (Asimov). This means that a robot may attack an entire expedition, and leave one persona alone. This means that a robot will not fire a grenade into a crowded room if a lone member of its manufacturing anthro type may come to harm. Robots cannot be convinced to attack their own base race, nor can they be easily tricked. The ref must closely watch that robot personas do not try to squeeze through loopholes of this ruling; as long as they see even the potential for harming their base anthro type, they must take precautions to avoid doing so. It is also important that the ref makes sure that robots are not manipulated due to this law.

Lethal personal combat with robots will certainly exist. By no means does this imply that there will be any dearth of insane robots for the expedition to fight, but those fights won’t always be toe wheel brawls. Even when a robot is technically allowed to bash an organic being, many robots find themselves lacking any such attack. Therefore crazed bots will often be reduced to locking expeditions in rooms (forever), turning off the air conditioning, or even messing with power supplies.

When robots are involved in lethal personal combat, whether it be with an expedition, an unlucky anthropomorph, or another robot it is carried out in the same method as all personas. The player running the robot must make a to hit roll higher than the target’s armour rating before she can damage her target. There are no special benefits that are given a robot to hit roll. Conversely any to hit roll made on the robot that is higher than her AR will inflict damage. The robot will take damage regardless of whether she is hit by an avarian feather, or a fusion blast. The rest of the chapter deals with how robotic combat is different from anthro and alien combat. These differences are all procedural for the robot persona and should not affect combat at all.

I just washed that!
I just washed that!

Robotic Attacks

Robotic attacks vary considerably, and most robots that engage in combat will have no weapons to speak of. Robotic weapons are most often regular non-violent appendages that are being used to damage a target. The next question is, how does a robot with no built-in attacks damage an opponent? This is left to the ingenuity of the player. It may be as simple as ramming, or as convoluted as mopping the opponent’s face.

Robotic Combat Table

If you are using the tactical combat system the robot persona will require a combat table. The robotic combat table appears the same as any other persona’s combat table. There are of course differences in how the matrix is populated. If the idea of a combat table is unfamiliar to the reader she should refer to Chapter 9: Combat Tables. If the reader is using the theatrical combat system then she should simply ignore pretty much everything that appears here.

The robotic combat table (Table 31.2) has three weapon types like all other combat tables. The way in which each weapon type’s bonus proficient is generated is different from that of anthros and aliens. A robot with a 10 PSTR and a 15 DEX would had a Bonus Proficient (BP) of 125 for type A weapons. The Bonus Proficient (BP) is used for any weapon that is part of the robot. The Bonus Non-Proficient (BNP) for robots is 0. The BNP is used for any weapon that is not part of the robot. For instance, a robot with an articulation that picks up a gun would use her Bonus Non-Proficient (BNP), in other words there would be no to hit roll bonus at all. Robots have no maximum roll to limit their to hit rolls. If a robot were to roll 986, and have a Bonus Proficient (BP) of 110, her to hit roll would be 1096, and it would not be limited by a Maximum Roll (MR). Robotic Damage Adjustment is straightforward, and is simply added to the damage of the appropriate weapon type.

Table 31.1 Description of Robot Weapon Types

Examples of various weapon types as applied to robotic combat.
Weapon TypeBonus Proficient ExampleBonus Non Proficient Example
Weapon TypeBP (part of robot)BNP (external to robot)
A (contact)Ramming. Whacking. Punching. Held sword. Lance welded onto body.
B (ranged)Ejecting. Spurting. Tossing.Catapulting rocks. Using a bow. Tossed grenade.
C (powered)High velocity projectile.Held gun.

Table 31.2 Composition of a Robot Combat Table

Robots have combat tables too.
Weapon TypeBonus Proficient (BP)Bonus Non Proficient (BNP)Maximum Roll (MR)Damage Adjustment (DA)
Weapon TypeBP (part of robot)BNP (external device)MR (no limit)DA (increase to damage)
A (contact)5 times DEX plus
5 times PSTR
0NonePSTR
B (ranged)5 times AWE plus
5 times DEX
0NoneHalf PSTR
C (powered)5 times DEX plus
5 times INT
0NoneNone

Robotic Ramming

All robots can fling themselves into targets that they want to damage. Ramming damage for robots is dependant on the type of ramming surface, relative wates and relative speed of the robot and its target. Robots that have no attacks whatsoever can resort to ramming, but they must first make a successful control factor roll (see below). Ramming a target will certainly damage it, but it will also damage the robot. Such self destructive behaviour for a robot will only be allowed by its programming if its insanity were to overrule it. This is what the control factor represents. If the robot has ramming as an attack, it does not have to make the CF check.

Table 31.3 Robotic Ramming Surface

Damage from ramming depends on what structural part the bot has decided it will ram with.
Die Roll (1d100)Surface DescriptionHit Points Damage
Die RollSurfaceHPS Damage
01-10Nice Soft bit.1d4 per 4 h/u
11-45Blunt Flat1d4 plus 1d4 per 3 h/u
46-75Blunt Protruberance1d6 plus 1d6 per 3 h/u
76-90Edge1d8 plus 1d8 per 3 h/u
91-99Sharp Protruberance1d10 plus 1d10 per 3 h/u
00Ref's Own Table

Relative Speed: How much damage a robot inflicts is dependant on the relative speed of the robot and the target. If the bot is chasing the target, and scores a hit; the target’s speed is subtracted from the robot’s ramming speed. Thus a robot moving at 12 h/u ramming a target running away at 8 h/u could only generate 4 h/u of ramming speed. If the target happens to be travelling in the opposite direction of the bot; the target’s speed is added to the bot’s ramming speed. If the same robot and target described previously were to meet head on, the robot’s ramming speed would be considered 20 h/u. A robot ramming at 10 h/u with a blunt flat would inflict 4d4 HPS damage. A robot ramming with a sharp protuberance at 21 h/u would inflict 8d10 HPS damage.

Relative Wate: If the referee chooses relative wate of the target and the robot can be considered. Not only does relative speed affect ramming, relative wate is also an important factor. If a robot has a greater wate than its target, it will inflict additional damage. If the target has a greater wate than the ramming robot, the target will take less damage. The damage factor is calculated by dividing the wate of the robot by the wate of the target. This damage factor only applies to robotic ramming, and not to any other robotic attack.

After damage for the ram is rolled, the Hit Points (HPS) damage is multiplied by the wate of the robot divided by the wate of the target. If a 120 kg robot rammed a 40 kg target for 22 HPs of damage it would inflict triple damage, or 66 HPS damage. If a 40 kg robot were to ram a 120 kg target for 24 HPS of damage, the bot would inflict 1/3 damage, or 8 HPS damage. The damage factor cannot exceed 4 times greater, or be reduced by less than 1/4.

Damage With Random Peripherals

How much damage does a mop to the head do? Here again the referee, and the player, must improvise. A quick (yet both arcane and convoluted) system to allow the player to roll any  four dice combination whose maximum damage is less than the robot’s PSTR. For example, a bot with a 9 PSTR could choose from  inflicting 1d8, 2d4, 3d3, or 4d2 HPS damage with a random peripheral attack.  A robot with a 24 PSTR could choose from 1d20, 2d12, 3d8, or 4d6 HPS damage per attack. The maximum number of dice in the combination is 4.

The amount of damage that a certain peripheral inflicts is determined at the beginning of the campaign, and does not alter (unlike the unpredictable ramming). Deciding whether an attack is a type A or a type B attack depends on the description of the deadly random peripheral. The number of deadly random peripherals that a robot has is determined when the persona is generated. Some of these peripherals will be well described, and not require too much creative effort on the part of the players involved. It is assumed that the procedure has managed to hardwire itself into the robot’s violence response, and no other peripheral may be used to inflict damage. Other peripherals can be used to distract, annoy or otherwise endanger opponents. A description to help determine how the deadly random peripheral inflicts it’s damage can be rolled on Table 5.19: Primary Robotic Peripherals

If it appears that a particular weapon is not doing a realistic amount of damage the referee and players must remember that these are malfunctioning robots and therefore malfunctioning peripherals. The deadly random peripheral is not being used for what it was meant to. For example an excavating shovel of a robot will not necessarily crush everything flat. It can still move a tonne of dirt, but it can only do so much damage.  Using the shovel to crush a scampering alien is not part of the programming for that device, and possibly there are still detectors and safe guards partially in place preventing full damage. 

Robotic Armour Rating

Making physical contact with a robot is fairly easy, but penetrating their metallic hides can prove difficult. This difficulty is only reflected in their armour rating, and a hit will inflict damage if the attacker has rolled over the robot’s Armour Rating (AR). Robots are given a base Armour Rating (AR) when they are manufactured, and cannot increase it with DEX bonuses. A robot’s AR is usually 700 and is determined when the robot persona is generated.

Damaging Robots

Robots are damaged by all the same things that damage organic personas, plus a few extra things. Robots are hardy and can take more damage than any other persona type. Robots also gain experience, become more insane, as they are damaged more. Robots take double damage from concussion and force attacks (bomb blasts, solid blows), and triple damage from disintegration, corrosive and electrical attacks. Robots are damaged the same way as any other persona is: if a hit is scored it means HPS are subtracted from the robot’s HPS total.

Many of the robot types have enormous HPS totals. This is because they need them. Many attacks, such as electrical, and disintegrations do triple damage, and robots cannot repair HPS like organic personas. When a robot is hit, any damage it takes is subtracted from its HPS total. Damage to a robot is the same as damage to any other persona. A punch does no less damage to a robot than it does to any other biological life form. The HPS still represents a universal value. This means that a robot will quickly lose HPS, but will be unable to heal itself.

Zero Hit Points: A major difference between robot and other personas is that robots do not expire upon reaching zero HPS Total. When a robot’s HPS Total drops below zero, it is damaged, but not dead. Some random system of the bot has been eroded to some degree. This erosion is represented by a drop in the robot’s attributes, including the HPS Maximum. Regardless of how the robot lost the HPS the system  malfunction is randomly determined. This could roughly be considered the hit location of the damage taken. An attacker could damage a bot’s sensors, or power plant, without ever aiming for that particular part. Each time the robot is reduced to zero HPS Total another robotic system malfunctions. Robotic death, the fatal malfunction, occurs when any of a robot’s attributes, including its HPS Maximum, is reduced to zero.

System Malfunction and HPS Max: When a robot’s HPS Total drops below zero the robot will suffer a system malfunction. Each system malfunction reduces the robot’s HPS Maximum by ten percent, and damages an attribute. The robot then returns to full it’s new HPS Maximum (the HPS Maximum that was reduced by ten percent). For example, a bot with a total 110 HPs drops below zero HPS Total. The bot returns to the new HPS Maximum—which is less 10% than the previous one—in this case, 99 Hit Points Maximum. This new hit point total is now the bot’s HPS Maximum. If this robot were to accumulate another 99 HPS in damage, it would suffer a new system malfunction, and its new HPS Maximum would be 89. This process of diminishing HPS Maximum is continues until bot reaches zero HPS Max. Which is a fatal malfunction. For example the HPS Maximum by  10% every system malfunction  (80, 72, 57 etc.) until it reaches zero HPS Maximum, when it is destroyed. Robots may now seem indestructible. They are tough, compared to organic personas, but they are far from indestructible. Usually, long before the robot’s HPS Max reaches 0, the bot will suffer a fatal malfunction due to a failed system. A failed system is represented by any robotic persona attribute reaching zero. 

The easiest way to calculate the new HPS Maximum is to multiply robot’s present HPS Maximum by 0.90 and round the result down. Always round the result down.

System Malfunction and Attributes: In addition to losing 10% of its HPS Maximum each system malfunction, the robot will also lose some attribute points. Depending on which system malfunctions one of the robot’s attributes will be reduced. Whenever any of these attributes is reduced to zero the robot has suffered a fatal malfunction and is irrevocably destroyed. The robot part damaged is determined randomly on Table 31.27: Robotic System Malfunction. And the extent of damage is determined on Table 31.28: Robotic Malfunction Severity.  Both of these tables are included here for convenience. The Robotic Malfunction Severity is rolled for each attribute that is damaged when the robot’s HPS Total  drops below zero.

Table 5.27 Robotic System Malfunction

Determines what breaks when the robots breaks.
Die Roll (d100)System Damaged Attributes Damaged
Die RollSystem DamagedAttributes Damaged
01-15ArticulationsDEX and AWE
16-25BrainINT; add d6 to CF
26-40Control UnitAll Attributes; add d6 to CF
41-55LocomotionDEX and PSTR
56-69PeripheralsDrop a peripheral
70-75Power PlantPSTR and CON and Duration
76-99SensorsAWE and INT
00Ref's Own Table

Table 5.28 Robotic Malfunction Severity

How severely does a malfunction impact the robot's attributes.
Die Roll (d6)SeverityAttribute Penalty
Die RollSeverityAttribute Penalty
1Lucky0 points
2-5Severe1 point
6Critical2 points

Robot Decay Table: The first question that any self-respecting referee will ask is how in the hell does one destroy a robot without destroying playability. If the players and referee gain particular enjoyment out of bashing robots then on the spot calculation of robotic deterioration may be considered fun. When speed is preferred, a Robotic Decay Table is recommended. The Robot Decay Table is prepared by the referee before the robot enters combat. The table outlines what happens to the robot as it accumulates HPS in damage. The referee tallies how much damage the robot has taken is listed as TTL (total damage), and the corresponding attribute effects for each system malfunction

The damaging continues until one of the robot’s attributes reaches zero and the bot dies. How on earth does one keep track of this during combat without having everything grind to a halt. The answer is to pre-roll the effects and create a robot decay table. Consider the following Table 5.29 Robot Decay Table (included here for your convenience) for Sal the Diagnostic Veterinarian Robot. TTL keeps track of the total damage delivered over time. Sal decays until her AWE reaches zero and dies.

Table 5.29 Sal's Robotic Decay

Example of how a robot falls apart and eventually becomes scrap.
AWECHACONDEXINTMSTRPSTRHPSDamaged PartTTL
AWECHACONDEXINTMSTRPSTRHPSDamaged PartTTL
9118211801216Nil16
9118191801114Locomotion30
9118191701112Brain42
7118191601110Sensors52
61071815099Control Unit61
61071715088Locomotion69
51071515087Articulation76
41071513086Sensors82
31071512085Sensors87
31071412074Locomotion91
11071411073Sensors94
11071411072Peripheral96
0
scrap
1071311071Sensors98

Controlling Robots

Robots are machines and their free will is an anomaly of their circuitry, and damaged artificial intelligence. They were initially designed to be completely under the control of the anthro type that manufactured them, and one way to defeat a robot is to restore it’s previous servitude. This does not mean that a persona from the  robot’s manufacturing anthro type will be able to order around an insane robot. These robots are free willed, and mere verbal ordering would be no more successful than it would be with other personas. However there are circumstances where a robot may succumb to it’s intended programming. The more insane the robot the higher it’s Control Factor (CF). The Control Factor is a measure of how much control the player has over the robot persona. Loss of control means that the referee controls the robot like the good automaton that it is. 

Spontaneous Loss of Control: There are certain conditions where a robot may involuntarily revert to its utilitarian nature. The chance of this happening depends entirely on the  Control Factor  (CF) of the robot, and the nature of the challenge. Whenever a robot voluntarily does a task that its robot type is designed to do then it may lapse into a state where it is again simply a mindless machine. For example, a janitorial bot would have to make a control factor roll if it were to clean up a messy room. If the player were to fail the Control Factor (CF) check then her robot would be out of control. Control factor fits are &scribed in chapter 5 under Control Factor.

Whenever a robot persona performs a task for which it was originally designed — a janitorial bot cleaning up, a combat bot killing an opponent —it must roll below its control factor or briefly return to it’s original programming. Control Factor rolls are usually Normal Attribute rolls  (1d20). If the janitorial bot were ordered to clean up a room by a charismatic mechanic from the robot’s base race, a tough (1d50) Control Factor roll would be need to be made.

The Control Factor of a robot is the robot’s INT plus its experience level, and represents how well it has learned to bypass its programming. To fail a Control Factor roll is to give in to that programming, a persona robot phenomenon known as loss of control. A robot that has lost control becomes a helpless automaton, a temporary referee person.  The persona will continue to perform exactly its programmed function without deviation until it regains control of itself. If the failure occurs during combat, it will last a random number of units determined by the same, die the robot lost control with so failing a tough (d50) CF roll would result in d50 units of boring, non-sentient behaviour. Outside of combat, the failure will last a random number of minutes on the same die: failing an improbable (d100) roll might lead to over an hour and a half of tedium.

CONTROL FACTOR (CF) = INT plus (INT level times EXPS LEVEL)

So a robot with an INT of 15 and INT LEVEL of 3 and was 3rd level would have a control factor (CF) of 24.

Table 16.3 Duration of Loss of Control

How long does a robot persona return to being a robot controlled by it's programming, and not the malfunctions that gave it sentience.
Difficulty of CF ChallengeDuration of Control Loss
DifficultyDie Roll
Easy1-10 units (1d10)
Normal1-20 units (1d20)
Hard1-30 units (1d30)
Tough1-50 units (1d50)
Impossible1-100 units (1d100)
Bizarre1-1000 units (1d1000)

Priority Commands: Priority commands are specially worded orders that can immobilize the robot by creating logical dilemmas within its reasoning circuitry. They are like combat within the robot’s circuitry. Priority commands are great opportunities for role-playing between the expedition and referee personas. The higher the robot’s control factor the more difficult it is for a priority command to be successful. Referees will often have priority commands prepared for their robot personas, and little clues can be given to the expedition to give them a chance to avoid confrontation with a robot.

Mechanics are the only class that can properly phrase priority commands to immobilize a robot through logical difficulties. The Degree of Difficulty (DD) of such a maneuver is equal to the robot’s CF divided by 5, plus a random factor of 0 to 9. The robot will suffer debilitating effects for the length of time 1 to 100 units in length. Priority commands may cause the robot to move at half speed; not use a certain weapon, forget how to open doors, or only remember how to turn left. The effect of the priority command will somehow impair the robot but not completely put it out of commission.

Robotic Overrides: These are aggressive attacks in which the robot’s enemy tries to take control of the robot with specialized equipment. The specialized equipment could be an artifact that is designed for taking over robots, or some concoction of mechanic directed wizardry. This can be done remotely with magical electromagnetic waves, directly by attaching to ports, or sneakily by infecting the robot with some control virus software. Success of a robotic override is much more problematic for a robot persona than a spontaneous loss of control, or a priority command. Robotic overrides give control of the robot to the attacker.  Such a circumstance needs to be played out by the referee and the players. A quick approach would be to triple the Degree of Difficulty (DD) of the mechanic performance roll, and convert the duration of control to 1-100 hours instead of units.  

aikidobot.324