Squaring Robots Book 8 with Mega Traveller

[Swiftbrook]

First cut of front cover here. In PNG format for your viewing pleasure.

Nice. Iron shaped feet

Should the subtitle be "Robots and Robotic Craft" ??

-Swiftbrook

 

[OjnoTheRed]

Why did you increase the size and cost of programs for increased skill levels by the _square_ of the skill level when size x skill level is sufficent in terms of cost of the program as well as the brain in CPU and storage needs?

This is carried over from Rob Prior's original notes (I've uploaded them here).

I agree with this call. In going over the robot designs in the spreadsheet, I have come to appreciate that without squaring the requirements, it is too easy to give all robots level 4 in everything. This relates to the point that Hyphen made above - albeit on a different aspect of robot design: Traveller is a game biased towards sophont characters: people trump machines. Machines help people accomplish more, but they don't easily have the same capacity as someone who has made a skill their life's work (which is around level 4, sometimes more but rarely).

For a lot of the robot designs, it did not make much difference - this is because for level 2 or 3, the existing rule that EDU + INT was the upper limit for skills (same as sophonts) this meant provision of brain space anyway - particularly storage. For robots that did need to expand their brains a bit, for the most part it largely meant eating into fuel capacity.

It does, however, place some burdens upon the "professor deskbot" and the Rashush models that will mean skill levels need to come down. The Hiver Bruiser models aren't quote so volume or cost restrained, and the brains can just expand as well as the hulls.

The black squares at the corners of the boarders of the tables shouldn't go over any text or tables. Also there should be no black corners on boxes internal to the page (see page 62 of the Refs Manual) they should just be on the outside (in the 4 corners of the page). I.e. there shouldn't be black boxes around "1 - BASIC HULL DESIGN" or "2 - POWER SUPPLY", or "3A - LOCOMOTION" or "4 - COMMUNICATORS AND 5 - SENSORS & ELECTRONICS 1" or "6 - WEAPONS AND 7 - SCREENS" or "8A - ENVIRONMENT" etc etc etc

I'll double check the layout of the corner black squares for places where they have interfered with internal layout. If you've got chart / page references for stuff you've found, it would help me greatly in correcting particular errors.

Yeah, that's an interesting observation about black box corners for edges internal to the page. I had always taken that way of doing things on p.62 to be a layout mistake! But on a quick scan of other pages in the Referee's Manual and other pages, I see that charts with corner boxes always otherwise take the entire page, so it's really a page layout rather than a break-out box.

I'm in favour of this fitting in with Canon as much as possible. What I'll do is post another iteration of the supplement with both ways of doing it, see what everyone prefers (including me!).

Suggest the addition of "Civil Engineering" Skill, so robots lower than TL 11 can designe buildings to standard physical rules. Either this or remove the need for Emotion Simulation from architect.

That's a good call. The idea behind Emotion Simulation for Architect was that without it, designs would be lifeless and drab. But you're right, it does leave a gap for CAD style autonomous systems.

Why do robots need light and heat on the inside of their bodies? There is absolutly no need for any vehical to have basic enviroment installed, so why impose this on robots? This requirements needs to be removed.

All craft need basic environment to keep fuel at the right temperature, provide for fittings for moving parts, some basic indicators and switches (e.g. on/off). While this isn't explicitly stated in the rules, most people I have discussed this question with indicate they feel basic environment is more or less compulsory. The comparison I would make would be to my family car - there are some basic environment things such as interior lights and heating for the passengers not relevant to robots. But then there are things like window controls (yes, just the handle for each one!) and some considerations such as anti-freeze in the radiator water and the placement of the fuel tank for dealing with the Australian heat. All of which falls under 'basic environment'. It is kind of like a tax on the design.

Having said this, have a look at the robots in the design spreadsheet; even among larger-than-human robots, say, 400 litres, basic environment comes to no volume, weight or power required, and costs a grand total of Cr4! For the purpose of keeping the rules simple, it's easier just to state that you need to calculate it and let designers figure out that it basically costs nothing. Having said this, I might help out by adding a phrase something like "up to volume X, basic environment takes no volume, weight or power".

You missed the three stars on Emotion Simulation form the table.

Thanks, will make the correction.

Why have you put the requirement of Low Attonomous on the ground and vehicel combat skill when it wasn't there before? Limiting warbots to TL11+ ? You've also removed Tactics as a skill.
For that argument all skills need Low Attonomous because they all require "independent action without direct commands".

You raise a good point about autonomy in general, and I think I may go over the text again with that in mind. The question is one of threshold. What the Robots in MegaTraveller chapter spells out is how Infantry Ground Combat and Armoured Ground Combat work in practice. (On reflection, there needs to be equivalent skills for water, air and space.)

The way I see it working for warbots is this: yes, at TL11+ they are much more flexible and can take orders and act independently with those orders. At lower tech levels, warbots are restricted to being given commands rather than instructions - so, "fire at that enemy over there" rather than execute a detailed order. I've developed that last chapter in the latest iteration to make a distinction between giving a robot a command - one sentence containing a verb in the imperative voice - and an instruction - a more lengthy assignment to a task. For warbots the distinction is spelt out in detail. For other robot tasks - e.g. repair and maintenance - it would vary greatly on the particular circumstances. For the most part, yes, robots are given instructions rather than commands, but it will take some time to make - in a way, it's really a form of programming by an operator. What I might do is spell out some distinctions between instructions and commands for non-combat tasks to give a better flavour.

So, note that warbots are not restricted to TL11+ - it's just that they need much closer supervision by operators below that TL.

Tactics is included as a skill. It's there on the table on page 22. The skills listed in the text are only those that need to be addressed in some way for robots, or are new skills.

If robot brains can replace a computer in a vehical why can't they replace one in a starship? They either can or they can't. Either robot vehicels need a computer and a robot brain, or they just need a robot brain. As a robot brain is a computer I don't see the need to have two. The original rule (which makes sence) is that a robot brain can replace a computer and a crew member. Starships have three computers, boats have two. Why can't a computer (a robot brain) replace one of these computers?

This is first and foremost a game balance / game world issue. In DGP's 101 Vehicles where they first discussed the INT rating / CP multiplier for robot brains, they pointed out that higher level computers have robot components built into them, and gave them some effective intelligence. Clearly in those cases, robot brains do not replace the entire ship's computer. If they did, no TL15 starship would have a ship's computer at all, they would just have a brain. I think this is against the spirit of Traveller. Some of the size of the computer is co-ordination of all of the various systems and sub-systems and hugely complicated calculations like lighting up that Lanthanum Grid for getting into Jumpspace correctly. A tiny robot brain is not up to a Model 9's capacity for that sort of thing.

This does create a threshold issue - that is, a situation where something of 99 dTons can be classified as a Small Craft and be run by a robot brain, but something of 100 dTons needs a computer. But this threshold issue is already built into the rules anyway in the way that crews are calculated differently for small craft and for starships / spaceships. So if I'm creating an issue, at least it's in line with issues already in Canon.

 

[OjnoTheRed]

Also Spohat control points in vehicels. If the crew position in a vehicel is required to be controlled by a sophant, then enough CPs need to be installed for this to be the case. If you install a robot brain to for the crew position you don't need these CPs. You only need them if you require the crew position to be filled by both a robot brain and a sophant.

This is for the sake of simplicity. If we get down to designing starships that have both sophont and robot crew, calculating the proportion of sophont control points and robot control points is, frankly, an unwanted complication. So I've settled on any sophont controller requiring full CP to be installed for the craft, ignoring robot brains. Having said this, robot controlled craft can take along passengers who are robot instructors, and sophont control panels do not need to be installed. The Essor Robot Drone - design 107 - is an example of this kind of design; the robot brain controls the craft and the passenger might be able to give commands or instructions - e.g. "fly lower over there, and get pictures of that funny grey box object with slits in the side".

Starships and spaceship crew calculations do benefit from robot brain installation by removing the need for accommodation and state rooms to be supplied.

Having said all of that, I think I've just talked myself around to a position where we take total percentage of crew not replaced by robot brains and use that as a multiplier to reduce the required sophont controls. I'll think about it.

As I read the MegaTraveller design sequence, what control points and control panels was replacing was the Classic Traveller Bridge "2% of volume or 20 dTons minimum" rule, but in such a way as to scale the design system from motorcycles through to Imperial Dreadnoughts and Battle Carriers.

Dexterity for Grav vehicals should be better than air cushoned.

Yes, good call. What do people think - a better multiplier - e.g. x5, x6?

Thanks for all your feedback, I'll go away and chew over it. Also, on looking at the latest layout, one of the chapter headings has dropped off, so I'll look into that as well.

Also, thank you aramis, swiftbrook, and SJWaldock! Swiftbrook - "robotic craft" it is!

 

[OjnoTheRed]

OK, updated supplement.

Keeping Black All Corners
Removing Black Corners except at Page Corners

I am still to have more of a rethink about the autonomy issues that Ewan raised. This revision includes improved front and back covers, updating the Base Dexterity for Grav robots to Grav Vehicle Skill x 6. Also - new! improved! chapter headings - now using the Shattered Imperium logo instead of the sunburst.

As well as placement of pictures (any ideas gratefully received!), I will be spreading example designs throughout the supplement in the style of COACC. Currently I have two example designs in, but the table borders aren't correctly formatted (should be top & bottom thicker lines), and I need to sort out a consistent format for Design Evaluation, commentary - and possible a picture.

 

[E.D.Quibell]

I agree with this call. In going over the robot designs in the spreadsheet, I have come to appreciate that without squaring the requirements, it is too easy to give all robots level 4 in everything. This relates to the point that Hyphen made above - albeit on a different aspect of robot design: Traveller is a game biased towards sophont characters: people trump machines. Machines help people accomplish more, but they don't easily have the same capacity as someone who has made a skill their life's work (which is around level 4, sometimes more but rarely).

As you know I work with low tech robot designs, where I get hampered with negiative and limited intelegance, limited skill choise due to lack of Emotional Simmulation, and double space requirments for my programs anyway. By squaring the space requrements for skill levels the burden becomes even grater.

I can understand the reasoning, but then High tech robots get free Intelegance. The same brain at TL8 is Int -4, while at TL15 it's Int 3. Which I agree with by the way, because it should be harder to make intelegent robots at lower tech levels.

But by squaring the requirements for increased levels at TL10 robot needs 32 slots for Pilot-2, on top of the normal brain requirments, while a TL11 one only need 8.

The skills aren't were the problems for robots are, it's the interprtitaion, understanding and creative thinking where the issue is. i.e. not the skill as such, but the intellegance behind the skill. I could understand higher storage requirements for skills that need interperatation, i.e. the stuff that Emotional Simmulation is required for.

The dificulty in the skill is already suggested in the space requirements needed for the different skills; driving a car 1, flying a space craft or an air/raft 2, piloting a spaceship 4. These are standard stuff, however things that require intelegance, instruction 10, linguistics 10, Tactics 8, pyscology 12 already have far higher space requirements without incorporating the fact that you need Emotional Simmulation for some of them as well.

That's a good call. The idea behind Emotion Simulation for Architect was that without it, designs would be lifeless and drab.

You could do a simmilar thing with Steward, and do a with and without. Functional vs Artistic.

All craft need basic environment to keep fuel at the right temperature, provide for fittings for moving parts, some basic indicators and switches (e.g. on/off). While this isn't explicitly stated in the rules, most people I have discussed this question with indicate they feel basic environment is more or less compulsory. The comparison I would make would be to my family car - there are some basic environment things such as interior lights and heating for the passengers not relevant to robots. But then there are things like window controls (yes, just the handle for each one!) and some considerations such as anti-freeze in the radiator water and the placement of the fuel tank for dealing with the Australian heat. All of which falls under 'basic environment'. It is kind of like a tax on the design.

Having said this, have a look at the robots in the design spreadsheet; even among larger-than-human robots, say, 400 litres, basic environment comes to no volume, weight or power required, and costs a grand total of Cr4! For the purpose of keeping the rules simple, it's easier just to state that you need to calculate it and let designers figure out that it basically costs nothing. Having said this, I might help out by adding a phrase something like "up to volume X, basic environment takes no volume, weight or power".

Unencolsed Vehicals can't have basic or exstended enviroment. Jeeps, Motocycles, boats, biplanes, to name a few don't have basic enviroment and don't need it. There shouldn't be a requirement for it. I understand what you are saying and the cost/wieght/price implications, however it shouldn't be a requirement to have it. We aren't changing the vehicel design rules we are integrating robot design with them.

You raise a good point about autonomy in general, and I think I may go over the text again with that in mind. The question is one of threshold. What the Robots in MegaTraveller chapter spells out is how Infantry Ground Combat and Armoured Ground Combat work in practice. (On reflection, there needs to be equivalent skills for water, air and space.)

These skills aren't needed for Humans. They are said to be "instictive" i.e. there is no Infantry Ground Combat or Armoured Ground Combat needed for Mercanary characters. So these skills are specificly designed for Robots so by having the skill disinct from just weapon skills implies that what you need for a warbot is in the skill. As per my last comment this implies a limited emaout of "independent action without direct commands" is already programmed into the skill it'self. You don't need to add to this with the brain command structure.

Where you do is when you need intelegance to provide creative thinking. Creating new tactics, reacting to situations in new ways. And this is what limits the robots. Come up with a new tactic and robots are stumpt. They won't be able to respond creativly.

The skill itself, using cover, identifying targets, moving between cover, laying down suppressing fire, responding to amushes etc etc. These would all be covered in the skill it'self.

Co-ordinating a team, as in your example, would need intelegance and tactics I agree. But not individually.

The way I see it working for warbots is this: yes, at TL11+ they are much more flexible and can take orders and act independently with those orders. At lower tech levels, warbots are restricted to being given commands rather than instructions - so, "fire at that enemy over there" rather than execute a detailed order. I've developed that last chapter in the latest iteration to make a distinction between giving a robot a command - one sentence containing a verb in the imperative voice - and an instruction - a more lengthy assignment to a task. For warbots the distinction is spelt out in detail. For other robot tasks - e.g. repair and maintenance - it would vary greatly on the particular circumstances. For the most part, yes, robots are given instructions rather than commands, but it will take some time to make - in a way, it's really a form of programming by an operator. What I might do is spell out some distinctions between instructions and commands for non-combat tasks to give a better flavour.

So, note that warbots are not restricted to TL11+ - it's just that they need much closer supervision by operators below that TL.

By imposing "Low Autonamous" on the combat skills you are limiting those skills to TL11+

Tactics is included as a skill. It's there on the table on page 22. The skills listed in the text are only those that need to be addressed in some way for robots, or are new skills.

Thanks Missed that. Tactics is a skill which I would suggest requires "Low Autonamous". YMMV.

O, and from the other side of combat skills are needed to be programmed into a robot, one thing that I think a robot doens't need is the Sensor Ops skill. I think that sensors are the "senses" of the robot and are thus "instictive" in their command programming. Much like we touch, see, smell etc, a radar is just anouther sense to a robot, like light amplification. To use it the command functions are already programmed in. The robots might not be able to learn from their senses, but they have no trouble interpreting them.

It's only humans that need to be trained to use and "interperate" the results of sensors, for robots it's already in the programming.

I suggest that you expand the fluf on the command aspects of the brain it include radar, pasive ems etc etc, and drop the sensor ops skill.

This is first and foremost a game balance / game world issue. In DGP's 101 Vehicles where they first discussed the INT rating / CP multiplier for robot brains, they pointed out that higher level computers have robot components built into them, and gave them some effective intelligence. Clearly in those cases, robot brains do not replace the entire ship's computer. If they did, no TL15 starship would have a ship's computer at all, they would just have a brain. I think this is against the spirit of Traveller. Some of the size of the computer is co-ordination of all of the various systems and sub-systems and hugely complicated calculations like lighting up that Lanthanum Grid for getting into Jumpspace correctly. A tiny robot brain is not up to a Model 9's capacity for that sort of thing.

This does create a threshold issue - that is, a situation where something of 99 dTons can be classified as a Small Craft and be run by a robot brain, but something of 100 dTons needs a computer. But this threshold issue is already built into the rules anyway in the way that crews are calculated differently for small craft and for starships / spaceships. So if I'm creating an issue, at least it's in line with issues already in Canon.

I understand the games balance issue, but then you need to explain this in some way in the book otherwise it doen't make any sence. You say something like "We are doing this for a game balance issue as we are integrating robots into the existing vehicel design system." and something about the instability of synaptic cpu against the reliabilty of needed jump calculations at TLs lower than 17. Follwoing with at TL17 this requirement goes away, as starship computers gain intellegance by themselves (a TL17 starship computer could be said to have INT 4 automatically).

Best Regards,

Ewan

 

[OjnoTheRed]

This is just a quick note to say that you've given me a lot of food for thought. Yes, your perspective on lower tech robots should definitely inform the design question.

Overall, two things strike me:

(1) autonomy - I should liberalise the limits around "emotion simulation" and the ground combat skills but rather have a scale for these - e.g. some way of working the fundamental logic into how the software operates. This would preferably be a simple game mechanic related to the tasks in the Robots in MegaTraveller chapter.

(2) capability - in relation to the "square the skill level" rule, I think it calls for lowering costs for a lot of the skills to rebalance them, and as you point out, how much processing power / cost difference is involved in programming Grav Vehicle vs. Pilot? So we could balance it that way. I think I also need to go back to the Tech Level charts in the Referee's Companion and do a bit of research into robot capability expectations by Tech Level so that we enable designs that way.

More thoughts and revised versions to follow.

 

[E.D.Quibell]

(1) autonomy - I should liberalise the limits around "emotion simulation" and the ground combat skills but rather have a scale for these - e.g. some way of working the fundamental logic into how the software operates. This would preferably be a simple game mechanic related to the tasks in the Robots in MegaTraveller chapter.

I don't think you need to liberalise around "emotion simulation" because this is where there is a fundermental problem for Robots. They lack creativity and empathic responses. In dealing with sophants skills "emotion simulation" should be reqiured, and limited to a single race (Human, Vargr, K'kree etc). And it also makes sense that "emotion simulation" needs "Low Autonamous" command because it's hard to deal with humans in a human way. Yes this limits the options of Low Tech robots, but then they should be limited in some way.

My issue was the new requirement for "Low Autonamous" on the combat skills, as I don't think it's needed.

Where I think it's more needed, and likely missing is in Tactics.

(2) capability - in relation to the "square the skill level" rule, I think it calls for lowering costs for a lot of the skills to rebalance them, and as you point out, how much processing power / cost difference is involved in programming Grav Vehicle vs. Pilot? So we could balance it that way. I think I also need to go back to the Tech Level charts in the Referee's Companion and do a bit of research into robot capability expectations by Tech Level so that we enable designs that way.

More thoughts and revised versions to follow.

I think we should concentrate on the intergration of the rules, and not the changing of them. The costs/sizes are as they are, they work and they are relativly accepterble. TL10 or under means you double the cost and size. This works to imposing limits on lower tech robots that are understandable, while making it easier as the TL increase.

Where the rules need intergrating, like CPs and CP multipliers, I think we've come up with some great answers, TLx10 for CP multipliter with no INT is genious by the way, I wish I had thought of it.

MegaTraveller isn't going to be revised (more is the pitty) unless Mongoose have the inclination (which I doubt), so I don't think we should be creating new rules. Intergrating, tweeking, and slight adjustments to help the intergaration is what we should be aiming for.

Best regards,

Ewan

 

[OjnoTheRed]

I have made some updates to the supplement and the spreadsheet:

Spreadsheet - Open Office
Spreadsheet - PDF version
Supplement - Open Office
Supplement - PDF version

Firstly on the capability of lower tech robots. I have thought about this, and Ewan, I have to disagree. The rules as they stand provide a reasonable restriction that does not significantly break designs.

Ewan, I took on your challenge about Pilot-2. Have a look at the new designs in the spreadsheet on pages 111 and 112 of the PDF file. Both are TL10. The design on p111 is a 37 L / 14kg box with Pilot-2 and a brain interface for plugging into your starship and comes in at Cr32,789. The design on page 112 is a two-legged, two-armed design with Pilot-2, a base speed of 192kph (mwa ha ha ha ha ha), eyes and ears. Ignore that TL15 holorecorder I just spotted that I forget to remove. The whole thing is 138 litres / 106kg and comes in at Cr97,008.

Both designs use the supplement rules as they stand. What you won't get is a TL10 shuttle pilot that is roughly human sized with Pilot-4, and Navigation-4.

Based on those results, I'm happy with the software rules as they stand.

But onto autonomy. Here I've changed approaches. Firstly, I have expanded the skills charts to explicitly cover all vehicle and combat types, and filled in some gaps from the Mega Traveller skills list. I have deliberately left off some interpersonal skills that are problematic such as Persuasion - but on those, I am open to argument as to how a robot might Persuade a sophont of anything in a role-play context (yes, emotion simulation for a start!).

Secondly, the Infantry Ground Combat etc. skills now no longer require Low Autonomous. But they work significantly better with it. Bear in mind that Tactics skill provides that "roving DM" in combat. That's the core thing here.

The rule I have instituted is to say that robots with less than Low Autonomous can act in an "advisory" capacity for someone who already possesses the skill as well as Robot Ops. So, an NCO with Robot Ops-1 and Tactics-1 could use a robot with Tactics-2 to gain an additional roving DM for their team.

BUT if that robot was equipped with at least Low Autonomous logic, the operator would not need to possess Tactics skill themselves; the robot would have sufficient independence to advise the team / unit directly and thus they gain the roving DM.

Robots who have the relevant combat skill ("Infantry Ground Combat" etc.) can now be regular warbots without Low Autonomous logic. That expands warbot functionality - the ability to execute orders independently. But if that warbot has Low Autonomous, they also get the benefit of any roving DM to apply to help their orders. Bear in mind that Infantry Ground Combat etc. are treated as Tactics minus 1. Thus, a robot with Infantry Ground Combat-2 and Low Autonomous logic could execute independent orders and get a roving +1 DM to support their actions.

I think this gives a good scale of abilities from lower tech to higher tech robots.

A couple of more minor things. No preferences yet by anybody for supplement with / without the extra black corners? My own preference is to keep them, having looked at both but I'd like to hear other views.

Is Grav Vehicle Skill x 6 for base dexterity for grav-based robots good?

Steward skill and a couple of other I have adjusted around their usage with and without Emotion Simulation.

I'm inclined to keep Sensor Ops skill in, but maybe add a note to the effect that it's only really needed for the sensor lock tasks in Space Combat - otherwise we can assume as noted by Ewan that radar etc. are just another sense from the robot's point of view and assume sufficient software drivers are built into their logic programs.

I did miss adding an explanation re: the requirement for a computer for starship / spaceship sized craft. Next time.

Other views on Basic Environment? It doesn't make much difference, stay or go - I'm starting to sway towards "go" - i.e. only needed in cases where the robot is sealed and expected to operate in a hostile environment. Takes away a headache from designers.

 

[E.D.Quibell]

I think it looks better without the black boxes in the middle of the page.

Grav x6 seems ok for Dex.

With the size needs for multiple skill levels, could you have the skill-1 in CPU at the skill-1 size and the skill-2 at the inflated size in storage?

i.e. for pilot-2, could you have pilot-1 in cpu at size 4 and the pilot-2 skill in storage at size 12? Empersizing the grater knowledge base needed for increased skill levels over the ability to do the skill?

Best regards,

Ewan

 

[OjnoTheRed]

Yes, absolutely Ewan - we don't require the entire program to be CPU resident, just resources worth a level-1 skill, the rest can be in storage. This allows designers to balance cost vs. volume/weight. I confess I hastily put everything in the CPU in haste in those two extra designs, but it doesn't have to be done that way.

This will even be the case where robots with Grav / Air Cushion / Aircraft locomotions require the applicable skill to be CPU resident - i.e. level-1 at least must be CPU resident.

We can assume that a robot can shuffle the program in and out of storage as necessary to get the benefit of the skill.

 

[OjnoTheRed]

New iterations of the supplement and spreadsheet.

Robots Spreadsheet
Robot Supplement

Both are in PDF form. If you're desperate to look at the latest versions in Open Office format, use the links earlier in this thread.

I have explicitly made the clarifications around skill storage and Sensor Operations as in previous posts. I have modified my previous post in only two ways: thrust based locomotions must have the entire skill present in CPU, and must have at least level one in the relevant skill (Grav Vehicle, Jet aircraft, etc). Secondly, weapon skills must be CPU resident - the time frames involved in combat are too short to allow for shuffling of programmes in and out. This tends to make warbot brains a bit more expensive if a bit lighter and smaller.

I have started adding artwork a bit more systematically to break up the text. Front and back covers are completed and have a FFE logo - that came with all of the cool stuff from my huge FFE CD-ROM purchase that arrived last week. I probably went a bit overboard, but I'm looking forward to getting into T5.

The news with the FFE CD-ROM's arriving is that I finally have my hands on the Wet Navy articles and the low-tech craft design article. There are two nautical robots in the spreadsheet, and I'll be doing them with proper Nautical locomotion now instead of the dodgy "aqua maneuver package".

Some of the text now needs to be broken up a bit more with robot designs - 3 or 4 will do it. Obviously I have a heap to choose from - but I would like some guidance as to which designs readers might think best ... and whether anyone would like to contribute designs to the book. Ewan, I would really like designs from you in particular. Let's get a supplement going with a variety of tech levels in it rather than the general assumption in the Imperial Encyclopedia that everything is TL15.

I had another idea. The spreadsheet is approaching completion as to a full evaluation for each design at the bottom of the design calculations. This is easy to scrape into a word processed format for a design supplement. The hard part is artwork. The artwork in 101 Robots gave the whole supplement a great feel.

So I had an idea - how about a supplement with a space for a picture for every robot where you draw your own? The basic shape would be listed (e.g. sphere with grav thrust and three tentacles) and anyone can combine that with the design evaluation and their imaginations. It would be quick and easy for me to do.

Would love to hear any thoughts including the observations of sharp eyes over the latest version of the supplement.

 

[OjnoTheRed]

This is the latest iteration of the supplement:

robot_supplement_v2.0.pdf

I have designated it arbitrarily as version 2.0 because the artwork is now all in place (including a great find on page 3 - from one Nathan Bowers who kindly gave permission). I have otherwise broken up the text with some robot designs.

The supplement as a whole is nearing completion.

I still welcome feedback on any topic, but there are two things in particular I'd appreciate feedback on.

Firstly, yes, I will be changing the black-corner boxes as outlined by Ewan. On reflection, he is right it looks more like canon to keep the black boxes to the corner. However, on all examples I can find, they go in the very corners of each page - this means spacing pages with multiple rectangles a bit more as there is some white space to play with. I'd like some feedback on what people think looks best. I also think the border lines should be a bit thicker than at present.

Secondly, I'd appreciate any general layout observations about placement of the designs and pictures throughout the text. They are basically there to break up the blocks of text a bit, but any feedback for general improvement of the layout is welcome.

I have made a couple of minor changes to the rules. I have reverted Basic Environment to optional except where the robot is in a hostile environment (to keep the brain in working order, correct temperature primarily). This brings the robot design in line with the Craft Design Sequence in this respect.

I have also added some clarification to the design sequence charts.

 

[E.D.Quibell]

Hi Johnathan,

Something is wrong with your brain size calculations. They don't seem to be constistant for some reason.

For example in the ANIMAL CARE ROBOT:

High Data requires 8 CPU (5 of which need to be parallel), and 10 Storage (either).
Basic Command require 2 CPU (any) and 2 Storage (either).

So for logic/command you need CPU 10 and Storage 12.

You have CPU – linear = 14, CPU – parallel = 5, Storage – Standard = 24

Which leaves 9 free slots in CPU and 12 free slots in Storage (so far so good, especilly with the right amoutn of parallel). Totaling 21 free

Now Medical-2 needs (with the square rule) 16 slots, and Body Pistol (with the sqaure rule) needs 8 slots. Totaling 24.

Which means you don't have enough space in the brain to run the programs.

***

Now I think you need a brain like this:

CPU Linear = 9
CPU Parallel = 5
Storage Standard = 32

Logic/command = CPU 10 and Storage 12

Giving 4 free slots in CPU enough to run the largest program (Medical-1 at 4 slots) and the rest in storage (20 free slots).

This also changes the UPP to INT2 EDU3

***

You could add more CPU and drop Storage if you wish to save the volume (but add to the costs) so you could have a bain like this:

CPU Linear = 13
CPU Parallel = 5
Storage Standard = 28

and make INT2 EDU2


***

However is you just use the skill x size rule you would only need 8 slots for Medical and 4 for Body Pistol giving a bain like this:

CPU Linear = 9
CPU Parallel = 5
Storage Standard = 20

giving INT2 and EDU2

So however you look at it you seem to have your brain calculations wrong for this one.

However your Janitor Bot dosen't work either because their isn't any space in CPU to run the program (you need a CPU of 5). Also your Starship maintenance bot has too much Storage (you could drop it to 40 giving INT2 EDU4 and still run the programms). Your parallel and synaptic CPU in your ELITE VALET are the wrong way around, and the security bot needs a brain that looks like:

CPU Linear = 9
CPU Parallel = 10
CPU Synaptic = 1
Storage Standard = 53

(Logic/command = CPU 17 (with 10 Parallel and 1 Synaptic) and Storage 27)

giving INT3 and EDU5

***

Now there might be designe decitions that you took for the mainenance bot and the security bot that make the barins the way they are, which is fine, however the others are wrong.

Appologies

Ewan

 

[OjnoTheRed]

Thanks Ewan - I will double check all of those figures. Easy enough, they're all designs drawn from the spreadsheet so I should be able to figure out where I went wrong.

 

[McPerth]

From your robot supplement, page 24, under robot brain replacements

Computers: On Vehicle or Small Craft, the robot brain one computer in addition to a crew member.

I guess you mean (...) the robot brain may replace one computer(...), but you forgot the verb in this phrase.

I also understand in this case you can make a fighter/drone crewed only with a robot brain (this would be coherent with what was written in 101 vehicles). If so, which computer number is this brain rated in combat?

Proposals:

- half its INT+END/2

- ship's tactics skill (this would force to have a very potent robot brain in order to be able to have this skill, but that's OK for me, as it must be quite specialized).

- ship's boat skill regarding to defDM. Gunnery skill when attacking (as rules for space combat allow you to replace compuer number by gunnery skill).

From page 29:

Lastly, for all Starship Combat tasks that use the Computer Model number as a DM, robot brain skills may not be used to modify the task. This is because the Computer Model DM - whether a positive DM or as a negative DM in an opposed check - already builds in the full capacity of the relative ship's electronic power. This means that it is rarely useful to install more
than Gunnery-1 for any robot, and that Ships Tactics and Fleet Tactics roving DMs are reserved for non-weapons tasks in combat

I guess this only applies to starships that have a computer, not the fighter/drones I talked about above

 

[E.D.Quibell]

Going on CP multipliers

INT 1 = Computer 10
INT 4 = Computer 11
INT 40 = Computer 12

and INT 0 = highest computer at that TL x10

TL 8 = Computer 7
TL 9 = Computer 7
TL 10 = Computer 8
TL 11 = Computer 8
TL 12 = Computer 9
TL 13 = Computer 9
TL 14 = Computer 9
TL 15 = Computer 9

Which makes them better at lower TLs an worse at higher TLs. Which makes sense kind of, to me at least.

Anyway if you went with this then you would have to balance it against normal computers in space combat.

In spcae combat a computer-1 hit reduces the ability of the computer to function suggesting that they are made up of multiple CPUs and storage boxes much like a virtual enviroment now. Robot brains being small specialised computers arm't like that however, if fact I would suggest that taking one hit should but them out.

So I would propose using the above based on the CP Multipler, and making any computer-1 hit in space combat completly destroy your robot brain.

Which means that they are better at fighting in general than normal computers, however they are instantly vunerable to dammage.

This makes sense against the relative size of the computer vs robot bain as well.

Thoughts?

Best regards,

Ewan

 

[E.D.Quibell]

You're missing ATV in the skills list.

Best regards,

Ewan

 

[OjnoTheRed]

Thank you for your sharp eyes, McPerth and Ewan!

I have corrected the wording - yes "may replace" is exactly the right word there.

As to our robot controlled small craft fighters in space combat. Thank you again for spotting that gap in the rules.

The approach I assumed when doing my Robot Raider was that the robot brain did not count at all for the DM in space combat - but I had not really settled on it. The design is on page 110 of the PDF'd robot design spreadsheet. Still, the Def DM is +8 based on the craft size and agility alone. Basically this thing is an armoured speedster with a huge amount of excess power to give it agile grunt. It is intended to close to suicidally stupid close visual range and knock out crucial ship's systems such as locomotion.

I think Ewan's solution is the most elegant; I certainly support the interpretation that a hit of Computer-1 or better takes out the robot brain, effectively killing the craft.

What's really needed is to run something like Trillion Credit Squadron with these robot raiders on one side to see if it's balanced. That's my main concern - giving that robot model an additional +11 on confrontation rolls. Would it upset game balance? I'm open to views, I just haven't run enough starship combat recently to do the numbers, and in the interests of time I need other experience for this.

I like your thinking, McPerth, but as the Robot Raider design shows, it has an INT of 15 and an EDU of 15 with synaptic storage that allows it to advance its EDU up to 35. In comparison to the cost of the craft, the brain and software cost of MCr1.35 is pretty trivial, and such craft could routinely install these kind of maxed-out brains routinely; that MCr1.35 price is between a Model 1/bis and Model 2 system. So using INT and EDU in a formula is out - that Robot Raider would have a Def DM of +23.

Skills are more interesting here. But again we come across some problems from canon. Pilot / Ship's Boat is used instead of agility. Gunnery skill can be used instead of the Weapon Table DM or the computer DM - which is more hopeful for our purpose; we would install Gunnery on any small craft that needed it, it's utterly trivial compared to the cost of the overall craft.

I'm pretty sure Gunnery can substitute for computer DM, then, when attacking. It's the Def DM I'm still wondering about. I like your thinking Ewan about basing it off CP multipliers and deriving an implied DM from there, I'm just worried it will be too powerful.

The computer DM for defence represents, in my view, firstly being loaded up with software in the "Evade" style in Classic Traveller, but also the computer's ability to co-ordinate a massive effort of screens and defence fire onto incoming ordinance. Electronically the computers are battling out trajectory calculations and this is abstracted by the DM. This basically envisages larger craft slugging it out. Are we giving the robot brain too much power compared to the volume, weight and cost of Traveller ship computers? I'm not sure.

Having said all of that, advantaging small craft with robot related DM's could restore the role of fighter craft to those massive starship battles.

 

[McPerth]

Pilot / Ship's Boat is used instead of agility.

This is only on the task for aiming the spinal mount, and I guess that won't be used in such a fighter/drone.

As for defense, in MT pilot/ship's boat skill has no use. I guess it could be a choice for this computerless fighter/drone (using the gunnery skill use analogy as a rule of thumb).

If the gunnery/ship's boat option is used, of course, sensor ops would act as computer number for locate/lock enemy with its sensors (rules also state it can be used instead of computer number). The use of ship's tactics in both cases as if it was computer number may also make sense, as you state they are not used as combat modifiers. Of course it makes tactics skill quite powerful for this robot brain

BTW, I still have to read in deep all your bock, but I guess you'll keep on the book initial skill limit of 4.

Of course, any such skill(s) use would make those fighter/drones better as most 'experience' they have in combat...

 

[OjnoTheRed]

You're right, McPerth, Pilot is only explicitly listed with that "aim the spinal mount" task (which, by the way, would apply to a robot-crewed behemoth with a spinal mount!). Obviously Ship's Boat would never be relevant in that situation.

But then there's this curious entry under Special Rules beginning at the bottom of page 94:

Emergency Agility: Because of the importance of agility, it is possible for a ship to elect not to use energy-consuming weapons in a combat round and instead divert energy to its maneuver drives. It such a case, an emergency agility rating equal to the ship's maneuver drive may be used. As always, Pilot Skill may be substituted for emergency agility if desired.

(emphasis added is mine).

In my view, this implies that Ship's Boat skill where relevant would apply in an equivalent way.

The problem with phrasing the rule this way, of course, is that adding "As always" implies that the rulebook says this elsewhere, but I can't find another reference to pilot / ship's boat. I think this makes Pilot / Ship's Boat skill a good candidate for a substitute for Computer Model in the Def DM.

But, other than this, I think I'm now tending towards saying we substitute Gunnery skill for Computer Model for Attack DM, Gunnery skill for both sides of the "to penetrate a defence" task, Sensor Ops for Computer Model for Sensor Lock (but robots get Unskilled OK on this task), and Ship's Tactics can be applied to non-combat tasks - so, yeah, sensor lock would be a prime candidate for this. There's another robot crewed ship design - an armoured box with ultra powered active sensors, Sensor Ops-4 and Ship's Tactics-4 with a range of communicators that is designed to sensor lock and broadcast enemy positions.

As a side note, yes I have kept the restriction of a skill level of 4 installed on the robot - robots can improve this skill using the Improving Skills chapter but it won't be usual in the run of play. One interesting trope this chapter gives rise to is the developing relationship between machine and player character.

And lastly, yes, the intention here is that all of this only applies to robotic craft that do not have a ship's computer installed. But this gives rise to a new problem. Adding a ship's computer to a small craft could reduce the ship's performance in combat. And there's the volume / weight / power problem: a robot brain with far less investment in any of these metrics can produce a +4 DM - in the robot drone above.

Consider this:

Robot Drone Brain - MCr1.35, 0.12kL, 0.03 tonne, 0.02MW
Model /4 - MCr6.4, 5.5kL, 1.4 tonne, 0.005MW

Now, the robot brain is far more power hungry, and when considering the power needed given its smaller size, it positively runs hot. I think this stands up to my pseudo-reality test.

Ewan has suggested that any Computer-1 hit wipes the robot brain, whereas normally it reduces the effective computer model number. This is a partial re-balancing, I agree.

But the additional problem is that the rules also assume that the computer has two redundancies - that means, triple the stats above. Does this mean that a Computer-1 hit means one of the models is reduced by one and then a better back-up kicks in? I don't see that in the rules, which are drawn from High Guard; it seems to imply that total computing power is reduced.

This gives a robot brain controller the edge in this situation over a massive starship computer.

There is another way of looking at this. The scenario we are describing only applies to small craft anyway, because starship/spaceship sized craft require a computer anyway. So perhaps this is a way of giving those smaller craft an edge in space combat. Again, this restores the role of the fighter - it can't carry the heavier weapons, but install a robot brain (even with a sophont controller) and you've got something that's very hard to hit and can close to visual range and target ship components.

I'm tending towards thinking this might be balanced, even if only as a result of emergent behaviour from this system.

That's my thinking aloud, hope it stands up.