Rules for ''droids''???

[MarcoSkoll]

Still almost entirely dependant upon the programmer, but keeps it more consistent...

Ah, but Inquisitor has never been about consistent. You'd think that my characters wouldn't fall flat on their arse about 30% of the attempts they have at jumping a gap, but they do.

Anyway, part of the reason I'm looking at inconsistent is that consistency, in my mind, is one of the things that makes servitors dull. They have no personality, no progression. If they're a bit different every time they play, making the player have to think around the particular technical limitations this game, then that could make them a more interesting model to play.

~~~~~

Anyway, I've considered various solutions to the problem of a flopped test, and the two most likely ones are that:

- The model gets a low, but just about usable, base statline and one function straight off the bat. However, the more specialised this first function is, the greater the modifier to their Sg test to add more functionality.
In this case, they're using some predefined code, but the more complex the basic code is, the harder it is to build on it.

- The programmer gets half their Sg automatically, plus the amount they pass an Sg test by.

Or possibly even a combination of the two.

This explains the bear/wolf/grox minds referenced in the background of Titans as well.

But we already know that Titans have organic computing parts installed already. The FW models have at least two servitors in all their current Titans (well, not the Chaos ones).

And as far as I can tell, they're doing relatively unintelligent roles that don't really require emulating any mind at all - checking the ammo feeds to the weapons, maintaining coolant system pressure, etc.
Intelligent stuff like target selection and aiming is the work of the Moderatii, not the servitors.

So it seems a bit funny to assume that when they're already using organic computing, that there can't possibly be any in the Titan's machine spirit.

The fluff is mixed on the Machine Spirit but given the horrendous ages of some of the Land Raiders still in service today, let alone some of the Titans, I would have to come down on the side of non-organic technology...

Why? We already know that the AdMech can produce anti-agapics, so the life time of a part could still be in the many hundreds of years, and it's long been set out that they have to be repaired many many times (and repair usually means "replace problem bits").

Inorganic parts will wear out over time too, and let's be honest, that time may well be shorter than organic parts. Name for me vehicles more than 50 years old that is still working without ever having had a single part replaced or having had major renovation work. That list will be pretty short. But a considerable majority of humans (at least in the western world) will make 50 years old without needing external repair work at all (most of that work is all done "in house").

Being an engineering type myself, I know it's practically impossible to produce something with a reliable lifetime of even hundreds of years. Particularly in a combat vehicle.

In my opinion, almost all the vehicles and weapons described as thousands of years are like Theseus' ship. All the parts have been replaced until nothing of the original remains.
That whole idea seems very 40k to me, that they still think that this is the original Rhino of their Chapter and treat it with all that great reverence, despite all the parts it actually started as being on a scrap heap somewhere.

[Aurelius 12]

As someone who's PhD is on AI, robots and the like, and is building an Adeptus Mechanicus warband with an unhealthy interest in the subject, I've been paying this a great deal of thought.

With regards to programming how about something along the following lines;

Starting stats
A robot's stats are determined by two main factors; its construction and its programming. Prior to determining either of these, a robot has 0 points for every stat except nerve, which is 100. All robots are ambidextrous (assuming they have more than one hand/arm/manipulator etc.) and benefit from force of will.

Programming your Machine

Step 1: Determine Code Quality
A robot's Initiative represents how elegant its code is, while its Sagacity is an indication of how versatile the code is. In order to determine the machine's Sg and I, the programmer may spend up to their Sg +2D10 on boosting these stats from 0.

e.g. Explorator Mathias has a Sagacity of 64. He rolls 11, meaning he can spend 75 points on his creation's initiative and sagacity. He gives the machine I 51 and Sg 24. Mathias' robot is quick thinking, however it will struggle to adapt to new or unusual circumstances.

Step 2: Determine Core Function
The vast majority of machines are built for a particular purpose. They may be automated battle machines, spy robots or medical assistants. To represent this, all robots have a core function. The robot gains a number of points equal to ½ the programmer's sagacity to be spent on one characteristic.

e.g. Mathias has constructed a robotic surveillance drone to alert him to any intruders. As such he puts his 32 points into Initiative, bringing it up to 83.

Step 3: Determine Coding Points
Anyone attempting to program a robot does so using Coding Points (CP). In order to determine how many points the programmer has to spend, they must take a Sg test at the beginning of programming. The number of CP is equal to ½ the programmers Sg plus or minus the number of points they passed/failed their Sg test by. Characters with the 'Programmer' special ability gain an extra 20 CP.

e.g. Mathias rolls a 72 for his Sagacity test, failing by 8 points. Ordinarily this would give him 24 CP, however because Mathias is a programmer, he earns an extra 20, bringing his total to 44 CP.

Step 4: Spending Coding Points
Coding Points may be spent on any of the following stats; BS, WS, I, Wp, Sg, Nv, Ld.
For every 10 CP spent on a particular characteristic, add 20 points to the stat. In the case of Nv, reduce the stat by the number of CP spent. In addition, CPs may be used to 'buy' special or robotic abilities for 10 points each, or exotic abilities for 20. No characteristic may have a higher value than that of the robot's core function.

e.g. Mathias's creation is fast and flighty but not designed for combat, He spends 10 CP on Dodge, as well as 10 on Response: Return. He spends 20 on reducing the robot's Nv and the rest on increasing its sagacity. The machine's programmed stats are: BS 0, WS 0, I, Wp 83, Sg 28, Nv 60, Ld 0, Response: Return, Dodge.



In terms of robotic abilities, there's not much that can't be modelled using the abilities that already exist, that said however, I was thinking about different ways a robot might respond to coming under attack for example. Some (like Mathias') might make a beeline for their master rather than going prone etc. Others might attempt to hide by powering down (a bit like 'they got me mother' only for a particular length of time, to avoid detection).

Other abilities may include a form of machine empathy based on interacting or overriding a piece of programming etc. Or a jamming field...

What do you think? It's just something I've been kicking around for the last couple of days, but if you like it, or want a third co-author I'm happy to join in!

[Ynek]

Step 1: Determine Code Quality
A robot's Initiative represents how elegant its code is, while its Sagacity is an indication of how versatile the code is. In order to determine the machine's Sg and I, the programmer may spend up to their Sg +2D10 on boosting these stats from 0.

It's a step in the right direction, but it creates a very narrow window of possible results (within 20 of their sagacity stat). The above method would work fine, assuming that this was the 21st century, and the people who were programming robots knew what they were doing, but this is 40k. The Admech don't really know how computers work, or their limitations. To them, computers are mysterious and powerful artefacts that are not fully understood, and therefore, when they start poking around in it's programming, the likelihood of making catastrophic mishaps is a very real possibility. Therefore, I'd like to see a wider window of possible programming point stats. This would represent the wider range of possible outcomes from the Admech's educated, but often misguided tinkerings.

How about....
To program a robot, the programmer takes a sagacity check. However much he passes or fails by is added or deducted from his sagacity respectfully. The resulting number is the number of programming points that they have. These programming points can then be spent on any and all mental stats (including Initiative).

Therefore, an Admech Magos with a sagacity of 80 can create a robot with a maximum of 159, and a minimum of 60 programming points.

Of course, most of the rules we're talking about right now are only relevant when REprogramming robots. I don't think that you should have to make all these random dice rolls every time you field a robot in your warband, since that brings us back to the defunct process of 'rolling stats for your characters' as per the back of the rulebook.

So, if you have a robot which was programmed by Magos Yosef Ferra in M35, and has never been reprogrammed in the last seven thousand years, just make up stats for it like you would for any other character, but the special rules such as rolling a sagacity check for any action other than it's core function and robotic special abilities, would still apply.

Also, I was thinking about "bugs" or "demons in the programming". Essentially, unforseen errors of problems with the coding which have resulted from the programmer poking around in subroutines etc. that were really best left alone.

Things like blindness, friend/foe recognition failure, reverting to an older program and performing the wrong functions (imagine a robot trying to stitch up an injured character when his surgical tools have been replaced with chainblades....) Perhaps these errors happen when a character fails the programming test. For every 10 points he fails by, a single randomly determined error happens. Or perhaps you can EARN programming points by incorporating these errors. So, for instance, having a blind robot might earn you an additional 30 programming points, whilst a robot prone to system crashes and reboots might earn you an additional 10.

[Aurelius 12]

I like the idea of one roll for all mental stats (although we'd presumably include BS & WS too). I was trying to treat Sg and I as if they were meta-stats; sort of following Marco's idea that they reflect the quality of the coding in question. But I guess Initiative stands for much more than that in game, and it does make everything a lot simpler.

I'd be hesitant to use a character's whole sagacity value; again the problem is that it can be used to represent knowledge, reasoning as well as a particular ability. I'd be tempted to make it so that untrained programmers are highly unlikely to produce an all-singing all-dancing machine by saying that they have a number of programming points equal to 1/2 their Sg +/- the degree by which they pass/failed. Characters with a 'programmer' special ability use their full Sg value however.

I like the idea of bugs, however there's possibly a difference between bugs, like BSODing and disadvantages like having no visual sensors. Bugs sound like a risky action table to me? Or something they roll on instead of being stunned etc. I like the idea of disadvantages earning you points though!

Of course once we've dealt with programming, we're then onto how robots are built (and not in a 'when a mummy-robot and a daddy-robot love each other very much' kind of way!). The alien generator seems to be a good start for things like wings, multi-limbed and wheeled robots perhaps.

As for re-programming, that's certainly true to an extent, and I totally agree that if your droid has been around for 7k you should probably just come up with stats like a normal character. But what about those Ad Mech who like to *shock horror* experiment? Those heretics who like to try new things, or fiddle around with technology to try and understand what makes it work! This would work brilliantly for those mad scientist-esque games. Plus there's always the possibility of Tau drones etc.

[MarcoSkoll]

Some good ideas.

Losing the randomisation fore each game might be a helpful timesaver, as well as getting around the "why the heck am I reprogramming it every time" dealie, but it would mean the role of the sagacity check for non-core functions would need to change slightly. As opposed to it being a fixed yes/no as to whether the Servitor is thus programmed (which would need unnecessary paperwork to keep track of between games), it would fall more into "No, not this turn".

The other thing is that I still recommend the DH approach to stat upgrades - the second one perhaps costing twice the first, and then three times (or maybe twice again, so four times), etc, etc, because it'll discourage servitors with devastating skills in a given area. Nobody likes BS 80 heavy bolter servitors.

Perhaps these errors happen when a character fails the programming test. For every 10 points he fails by, a single randomly determined error happens. Or perhaps you can EARN programming points by incorporating these errors.

Sounds a bit like hallucinogen for servitors - I like it!

I also like the idea of incorporating errors - well, not so much "incorporating errors" as perhaps using your programming time on things other than doing proper bug checks.

[Aurelius 12]

As opposed to it being a fixed yes/no as to whether the Servitor is thus programmed (which would need unnecessary paperwork to keep track of between games), it would fall more into "No, not this turn".

This would also make it more likely for people to try doing non-core things with their droids, rather than reconciling themselves to the fact that it just doesn't do stairs etc.

The other thing is that I still recommend the DH approach to stat upgrades - the second one perhaps costing twice the first, and then three times (or maybe twice again, so four times), etc, etc, because it'll discourage servitors with devastating skills in a given area. Nobody likes BS 80 heavy bolter servitors.

That's a very good point. Perhaps the first 10 points spent get you +20, the next 10 get you +15, the next 10 get you 10, then after that it's 2 points per +1?

Sounds a bit like hallucinogen for servitors - I like it!

That's exactly what I was thinking, but it could work as a catch-all for failing a risky action, being haywire-grenaded (with hillarious results) and other potential options too. I still think separating bugs from disadvantages is probably a good idea. Of course one dissadvantage could be 'buggy!' meaning that the robot suffers from a random bug (chosen at game beginning) each turn unless it passes a Sg test.

[Charax]

Charax - are your rules designed for Legio Cybernetica robots or more abominable versions? If the former then I'd be interested to see them.

Cybernetica, mainly.

Well, if there's interest...

Seek-Locate-Destroy: Robots in Inquisitor

Step 1: Choose Chassis:[/b]

Small:
-30% to hit
Strength: Up to 100
40 Build Points
1 Hardpoint

Medium:
Man-sized
Strength: Up to 200
80 Build points
2 Hardpoints

Large:
+20% to hit
Strength: Up to 350
120 Build Points
4 Hardpoints

Step 2: Choose Statistics:
All robots start with 10 points in every statistic, with every further increase by 10 costing a build point (this may be split, so that for one build point 5 can be added to two seperate stats)
The robot has no Wp, Sg, Nv or Ld statistics, and may not purchase them unless it has a Cortex (see below). Of the remaining statistics, Ws and/or Bs may be reduced to 0 and S and/or toughness may be reduced to 5 using the same ratio of 5 stat points/1 build point. Robots are never required to take tests for psychological effects such as fear or pinning.

Step 3: Choose Armour:
All robots start with armour 4 on all locations. this may be increased at a rate of 1 build point per location. Each build point can increase the armour of one location by 1, or reduce it by 1.
Some robots will have non-standard location tables - this is fine, a lower number of locations means cheaper armour, but a higher chance of each location taking damage, whereas the cost of high amounts of locations really add up.

Step 3: Equipment and Weapons:
Equipment can be built in to robots for a cost of 1 build point for every 5 weight, as long as the equipment's weight does not exceed the robot's strength. Such equipment is part of the robot's structure, protected by it's armour and the commands for operating it are encoded directly into the robot's Firmware. Weapons must be mounted on one of the Robot's hardpoints - a pistol takes up half of a hardpoint, a basic weapon or close combat weapon takes up one hardpoint and a heavy weapon takes up two.

Energy weapons feed from the robot's internal power supply, and thus replace their reload value with a recharge value equal to it (or, if they already have a recharge value, it carries over). Non-energy weapons must have ammo loaded into the robot, costing one build point per standard reload - note that this is not an actual reload - it is just *space* for a reload, and autoloader mechanisms for it, the ammo itself (along with any special ammo therein) must be acquired and loaded seperately, usually by the robot's minder.
All robots have Quickload and Rock Steady Aim for any weapons they possess (meaning that the recharge rate of energy weapons will be half their usual reload rate/recharge rate)

Any number of the robot's hardpoints may be replaced with a Hand at the cost of 2 build points - this allows the robot to use weapons that are not built into it, but the robot loses it's quickload and Rock Steady Aim abilities for these weapons.

Standard equipment:
All the following equipment is standard in a robot, and costs no build points, but certain systems can be removed to free up build points for other uses.

Communicator:
This device allows the transfer of data between the robot, other friendly robots and the robot's commander (usually a tech-adept of the Legio cybernetica, but sometimes an Inquisitor, or even an arbites officer in the case of razorfangs) - it accomodates wireless data transfer, and if the robot is equipped with a sensor package, it can pick up messages encoded in any of the senses it has - it can hear and respond to verbal orders (security features include encoding to a specific voice, or a spoken keyphrase preceeding the order) or written ones (perhaps written in code, or an obscure language) or any combination (verbal orders given by someone wearing a certain symbol, for example). Communicators are vital for robots without a cortex.

IFF system:
Allows the robot to recognise friends and enemies - by default, anyone in the warband it's in is a "friend" anyone else is a "foe" - other designations are left to common sense - an Arbites mastiff will see all arbites and law enforcement as friends. Anyone attacking a known "friend" will instantly be classified as a "foe". A robot without an IFF views everyone as a Foe. Damage to the IFF can be very dangerous. The IFF costs 1 build point and is weightless

Sensor package:
As standard, the Robot's sensor package gives them the effects of advanced bionic vision and hearing. For an extra build point each, additional senses can be added to this package. Adding an auspex or gunsight to the sensor package (in the same manner as having such things incorporated into bionic eyes) costs a build point.

Autoloader:
This is installed on all robots with projectile weapons, and is what bestows the Quickload ability for that weapon. This costs 1 build point per reload of capacity, as mentioned above. if removed (or rather, not present to begin with) the Robot does not have Quickload for that weapon, and reloading must be done manually (this can be done by the robot if it has a hand, or otherwise by a human loader.

Recoil Supressor:
A series of springs, weapon cradles and hydraulics bestow the Rock Steady Aim ability upon the robot for all weapons it is fitted with - for 2 build points per hardpoint, this can be removed.

Optional Upgrades:
These are, in effect, pieces of equipment that can only be bought for and used by a robot, unless otherwise stated. Build point costs are given.

Cortex:
A vat of artificial organic tissue and circuitry, the cortex contains all the basic operating protocols of a robot (such as how to walk, or what each of it's weapons is which) in addition to the capability to accept program cards - small slices of bioplastic that contain the programs the robot is to follow in battle. Each level of Cortex bestows 10Sg on the robot, which effects the complexity of the program it can run (see Programs). The robot's other mental statistics are largely useless given the immunity to psychology, but the cortex allows the option of spending build points to raise the mental statistics. Sg cannot be raised other than through the purchase of a more complex cortex, and none of the mental statistics can ever exceed double the robot's Sg. Each level of cortex costs 5 build points.

F-T-E system:
The FTE or For The Emperor system is a self-destruct device designed in such a way that the explosion is channelled through the robot's primary systems, melting them to slag and preventing the secrets of such technology falling into the hands of the Emperor's enemies. It can be triggered by the robot itself, or by the robot's controller. When triggered, calculate damage as if a demolition charge had detonated on top of the robot, all hits to the robot will bypass its armour (as it's inside). A FTW system weighs 25 and costs 10 build points.

Powerfield/Powerfield syncroniser:
Medium or larger robots only.
A Powerfield is a very powerful but energy-consuming form of forcefield that projects a bubble of energy around the generator that protects against most forms of attack. A powerfield generator projects a 5D10 forcefield in a sphere three yards out from the robot. people can pass through the forcefield, and the robot can walk around fleely, but any shots fired into *or out of* the bubble must cause damage in excess of the forcefield's value to pass through. A powerfield generator takes up 20 Build Points and has a weight of 50.
The Powerfield syncroniser is a device attached to the Powerfield generator that causes it to flicker on and off for fractions of a second - the device then relays the status of the field to the Cortex and fire control systems, allowing it to bypass the shields - a robot with a powerfield and syncroniser is therefore unaffected by its own field when shooting. A syncroniser takes up 5 build points and has a weight of 10. Any shot fired into the powerfield will bypass it if the to-hit roll was 0-5%

Organic Camouflage:
The robot has a layer of cloned synthflesh grafted on top of its armour, causing it to resemble a human or other creature. the robot's armour remains at the basic level of 4 and cannot be upgraded, but it may wear armour on top of the synthflesh for additional protection. Bioscanners will show the robot as a living being (the synthetic flesh is kept alive by internal nutrient feeds) and subdermal thermoconductor plates give the robot a realistic, but somewhat high, heat distribution profile when viewed through thermal imaging devices such as Infrascopes - of course, this is literally only skin deep, and any damage above Light to any location will reveal it as being robotic - sufficiently advanced robots will have programming allowing them to pass this off as being subdermal bionics, but such occasions are rare. Organic camouflage costs 15 Build Points and weighs 5 - it includes a set of microactuators for mimicing things such as facial expression and muscle movement, and a vocal system capable of passing for a human voice. Obviously, robots with more or less locations than a normal human cannot pass for one, but may be able to pass for something else. Large-chassis robots may be built to resemble Ogryns, and small-chassis robots children or pets.

Programming up next

[Charax]

Programs:
When constructing a Robot program, three types of instruction are used: Commands, Decisions and declarations:

Commands tell a robot what to do. A robot can complete one command per action it passes. Robot action rolls pass on 2+. On a 1, there has been a Program Malfunction.

Decisions are yes/no questions the program asks thge robot. the robot answers based on its sensors and information, and the answer determines the course of action. A robot can complete any number of decisions per turn.

Declarations are used to seperate off sections of the program into subroutines. Every program starts with the declaration "Start" - it is from this point that the robot's program runs at the start of every turn. Declarations are useful for cutting down the amount of instructions a program needs by reducing the need to duplicate instructions.

Commands:
The possible commands for a robot are:

Move/sneak/walk/run/sprint towards X:
   when given this command, the robot will move as fast as specified (as fast as possible if no speed is stated) towards X (X can be any Constant, see below) for one action, turning to face X if this was not already the case. This command is often used along with a decision saying "Is X within Y yards", and the process is looped until X is within Y yards. Robots given this command will avoid any impassible obstacles, and will always take the quickest route to their target - it includes the capacity to judge the speed-hampering effects of different terrain types when judging if they should be avoided or passed through.

Charge And Fight!:
   The robot will charge (if possible) and fight the subject of whichever decision preceeded the Charge & fight! command, usually an Enemy or Target. The robot will use any close combat weapons at its disposal, and will not leave combat unless defeated, the target is taken out of action (through death, unconsciousness or another event) or directly commanded to by its controller. Charge and Fight! does not involve any parries or dodges - the robot will simply charge, get as close to the enemy as it needs to be, and attack. While under the C&A! order, the robot's program does not start again every turn, the program only restarts once the target of the action is taken out of action. More advanced combat programs have to be written manually and triggered like any other program, but robots with such prigramming can usually best an identical (or sometimes superior) robot on a C&A! command.

Explode!:
   The robot will detonate it's F-T-E! system and any bombot racks it possesses (if present) - the explosives are detonated on a D6 roll of 2+ (roll for each available explosive) and all those rolling 2+ *will* explode, even if one of the previous explosions destroys the robot. Note that when applied to a specific bombot rack or explosive system, the correct command is "Detonate X" - i.e. "Detonate Frag grenades" or "Detonate 2 Plasma grenades", but such selective programming is rarely used.

Ranged weapon commands:
Robots with ranged weapons need a whole plethora of new commands to deal with their systems.

Select new Target:
   Another advanced command, "select new target" tells the robot to shift its attention to another model sharing the target characteristics defined in its Constants - so if the constants read "Targets are mutants", the Select New Target command will shift the robot's focus from one mutant to another character it can see with an obvious physical mutation. It is most commonly used on robots armed with ranged weapons.

Fire X at Target:
   The current target is fired at by the weapon designated X (ex. "Fire bolter at target), or, if no weapons are designated, only those within range (for weapons with a maximum range) or with a modified to-hit chance of greater than 20 are fired. Weapons with multiple fire modes are fired on the highest semi-auto mode the weapon has, but this can be changed by the command "set [Weapon] to [Fire Mode]" (ex. Set Bolter to Single) - if full-auto is selected in this way, the target group will consist of the current target *only*, which may result in the robot not firing due to the discounting of attacks that have less than a 20% chance to hit.


...that's it. I never said I finished the rules!