• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

Squaring Robots Book 8 with Mega Traveller

Much better layout than the last version.

Formating particulars, most of this is in view of making this match the rest of canon.

Text:
Headers throughout the document:
Even pages: Chapter Title - FFE
Odd Pages: Manual Title - Chapter title

Section Titles: The MT canon goes as follows:
1st level - bold all caps, then start next line
2nd level - bold, upper & lower case, text starts same line
3rd level - italicized only, text starts same line.

Tasks - Keep tasks at the same font size. The white space around it is enough to set it off.

Pg 1 - update copyright from 2008 to 2011.
Pg 8 - Master & slave networks - Bolded & italicized. Inconsistant w/ rest of titles.
Pg 9 - Add space above ACCOMODATION
Pg 9 - Fundamental Logic Programs - Bolded & italicized. Inconsistant w/ rest of titles.
Pg 24 - Sub paragraphs in ROBOTS ON STARSHIPS section - go wth 2nd level section titles.
Example: Dumb Warbots: Robots who are equipped.....


Charts:
1. Some charts have titles in the box, some do not. Every chart should have a title.
2. Charts should be in the same size typeface as text. We aren't getting any younger. When I retypset my MT manuals, I had to go from 7 point to 9 point. Yes, it added pages, so what, We don't have to do things in groups of 4 pages for publishing - PDF are the way to go.
3. Put the charts in the back of each chapter. That way, you don't have 1 line of information on 2 rows.
4. Highlighting. Great idea, but needs to be consistant.
5. Pg 12 - Skill charts - Dire need of highlighting to make readable. I'd recommend underlining every fifth row & again making this the same text size.
6. Chart table pages not numbered.
I would also recommend looking at moving the power supply to the end. The design sequence in canon doesn't work in this order. Every craft design generation example, moves Power supply to the end. This also needs to be changed in canon. If no one is following the design sequence because it doens't work, then it should be fixed.
7. Chart Section Titles: bold all-caps, centered.
8. Tables - right justify the rows to match canon.
9. Lines under column titles - consistant - I recommend 1 thickness. Also, each column title shouls sit on the line.
10. How did you make those boxes? I never did figure that part out.
11. Fully justify the text in boxes. Makes it easier to read.
12. Pg 18 - Software - consider making sub-tables (1b, 1c, etc for each of the *'s) It will break up the chart & should make it easier to find the skill you are looking for.


All in all, great work!
 
Hi Jonathan,

Just coming back to this.

The TL- on the INT role as stated in Book 8 makes it very hard to get intelligent robots under TL12. I think that’s right, otherwise you can quite easily get INT 1 robots at TL8. This isn’t tinkering it’s a fundamental change.

So I think you should change this back.

On the CP INT rule, I think there should be a CP for INT 0 robots. I liked the formula that you worked out before however I can see that it doesn’t work well in the design sequence (it’s an additional unwieldy step), so pick a number. TL8 computers have CPs of 95, so as robot brains have skills a CP of 100 for INT 0 robots would seem appropriate. If you think that’s too high go with 50.

Remember control panels are for SOPHAT (human) control of the craft. Robot brains don’t need to press buttons, turn wheels, push peddles or flip switches. That’s why CPs in robots have to be “linked”. Thus INT 0 brains have to have some type of CP multiplier otherwise they wouldn’t be able to control the craft.

Your robot brain not replacing a computer rule again I think is wrong. You need three computers in a starship, if you have a robot crew member you just need two more. Also your robot brains’ CP multiplier should be able to be used for sophant crew running the craft, it’s intelligent after all, however it should be noted that with the loss of the robot brain the craft returns to its computer’s CP multiplier, which might mean that there might not be enough CPs installed to run the ship without it. That should be the choice of the craft designer, not ours. The consequences should be pointed out though.

On the Master/Slave CPs the values were worked out from the initial ones of Book 8, and a CP multiplier picked to work with the ones in the book. If you change this (min size, CP value etc) you have to compare it against TL/CP value of the CP table in the Refs Manual not in the cost or number needed to control a robot.

Slave CPs were worked out between Electronic Linked and Computer Linked, as there is no TL enhancement.

Slave CPs are run by Master CPs. So if you installed Slave CPs in a robot to cover the CPs needed in that craft you need an equal number of Master units elsewhere. That might be in the same craft, or it might be in another, but they have to be somewhere.

As an example instead of installing 5x electronic linked CPs in one craft you could install 5x Slave CPs and 5x Master CPs in the same craft and they would work in exactly the same way.

Again I believe INT 0,1,2 robots should be able to be in master/slave config, however with the proviso that only one of unit should be mobile. This allows INT 0 robots to move their own chassis if they have master/slave CPs installed in the same manner as if they had electronic linked cps installed. This allows Sophant control of slave units, and non-mobile masters (much like the drones that air forces use today). The INT rule should then kick in for multiple _mobile_ units.

O and before I forget, the chassis should be worked out via the vehicle tables, there should be no default armour value unless you choice to design this into the vehical.

Best regards,

Ewan
 
Thanks to both of you - this was exactly the kind of feedback I was after. I'll start working through the list of layout issues - thanks sfschbryan!

Ewan, my removal of the CP multiplier plus TL mod was entirely driven by the complication of the CP multiplier as we had worked it out. But you are right, on reflection changing the TL mod is a major change. I'll have to re-think this - I like your idea of picking an arbitrary number for INT 0 robots - say 100.

I think I get what you're saying about master/slave units to provide control.

Thanks again, more later.
 
Hi there. Sorry this post is a bit long and I'm raising a host of issues.

Next iterations:

Supplement in PDF form
Supplement in OpenOffice (original format)
Robot spreadsheet in PDF format (one robot per page)
Robot spreadsheet in OpenOffice format (original)

The first 10 robots in the robot spreadsheet have evaluations and have been re-done in keeping with the latest iteration of the supplement. But I am not vouching that they are without error! Still checking through them, and because I'm still tinkering with the robot design sequence, they will be subject to further changes.

The robot spreadsheet PDF is one worksheet per page, and the print is tiny - but zoom in on your PDF reader on the first ten pages and you'll see what the evaluations look like at the bottom of each page.

These are the revisions to the supplement since the last iteration:
1) Original TL-12 modifier for INT restored
2) For INT 0 robots, TL x 10 = CP multiplier
3) Clarification of role of CP multiplier and fractional control panel numbers.
4) Chart titles in design sequence in capitals
5) Consistent first, second and third level headings throughout text (but sharp eyes welcome!) - this took care of several instances pointed out by sfchbryan which were intended as second level headings but were not consistent.
6) Appendages section re-badged "Appendages and Tools" section
7) The tool packages in the 'other' section now broken up between sensors and electronic and the new Appendages and Tools Section.
8) Added Voder and keypad to design charts
9) Removed all tables from text - the design sequence charts are now the only reference for 'numbers'. Thus the charted design sequence is the "charts at the end of the chapter" now. My intention in putting the numbers in both places was to allow someone browsing the supplement who was reading the text to have a quick reference for the absolute numbers without flipping pages, but to make it consistent with how I saw canon laid out involved compromising text sizes which hurts eyes. Flipping pages is less of a concern than straining the eyes, and frankly it relieves an editing burden not to have to modify everything twice.
10) Design chart tables upped in font size to equal font size of rest of text in design charts. Consequential extension of charts across more pages. Some white space to play with now on chart pages.
11) Page numbers now continuous including on design charts.
12) Headers - can't figure out how to make them different for each different chapter AND a mix on even and odd pages. Different headers for left and right pages is straightforward; different chapters is straightforward; it's doing both that makes it difficult. Have gone with MegaTraveller: Robots (left) and Far Future Enterprises (Right) throughout. See more below on Master Documents.
13) Reformatted all tasks to be same font size as body text
14) Copyright updated
15) Remaining non-design chart sequence charts all have titles. The actual titles themselves are up for debate, of course.
16) Chart section titles bold, centred, capitalised to match canon.
17) Tables - I did right-justify *most* of the entries. However, a left-hand column entry in text gets left-justified; all numbers relating to that entry get right-justified. I left smaller tables with variations, though - usually all centred. I am trying to keep tables of installable gear consistent as: TL - name - power - volume - weight - price - other details. In this schema, both TL and name are left-justified, the rest are right-justified.
18) Lines under table headings in chart design sequence now all half-point thickness and headings should sit on the line now (i.e. all bottom verticle-alignment).
19) Table highlighting - Charts in Design Sequence tables get first three rows white; next three 10% grey, then repeat. This means tables with three or less rows don't get highlighting (and it's not really needed anyway). Charts in text get first row white, next row 10% grey, then repeat.

Explanation of black-box corners: Each step in the design sequence consists of six frames. The first frame encapsulates the heading ("10 - FUEL AND OTHER") and lets me set the position of the heading relative to the rest. The second frame is invisible - it has no borders, its internal and external margins are zero, it is completely transparent and it is a wrap-though. The third frame is the internal body of the step and has borders and margins. Its parent is the second frame so its width and position are all relative to the second frame and they move together. The third through sixth frames are small frames measuring 0.70cm x 0.70cm with black borders, and filled-in black. They, too are children of the second frame. Their positions are set relative to the four (invisible) borders of the second frame. Thats it! All I've done is used text frames to mock-up the graphics I needed. If there was an extension for OpenOffice that had nice corner-design features and internal / external margins set for you, it would be much easier!
 
A few issues on substantive things.

Control points.
I agree with Ewan, changing the TL-12 rule was fundamental, not tinkering. I've put it back. I've simplified the rule for INT 0 to TL multiplied by10 as the CP multiplier. This can be justified even for the most basic brains (Linear CPU=3, Storage=11, Basic Data, Limited Basic Command). Firstly, control mechanisms for a robot brain to its constituent parts do not need to be as extensive as for a sophont controlling a craft - no steering wheel, instruments, video display / keyboard / holographic in-out, etc. So the multiplier represents the vast reduction in volume and space needed in this regard. It also means we can justify saying that we are not really installing "panels" for sophont interaction in the same way as for other craft, but rather electronics/electro-mechanical controls that communicate a certain volume of command. This relates to our concession that for robots, we can install down to one litre of the standard control panels. The best panel value in the existing design sequence for volume is the Computer Linked panels (0.08 CP per litre - listed volume is 0.010 kL or 10 litres for 0.8 CP). In the vaaast bulk of "standard robot" cases, this will lead to a design where our robot brain is all we need to install, but if we are thinking of larger craft - e.g. a small-craft combat vehicle completely robot controlled - dare I call it a "cylon raider" - more extensive control might be necessary. Secondly, any robot brain complex enough to run limited basic command has sufficient electronics to control a fair bit in its own right - hence the Total CP divided by Brain CP multiplier < 0.05 = no control panels required rule. I believe the balance I have struck represents a reasonable simplicity of design system (i.e. playability) that encapsulates a reasonable level of flexibility for those wishing to design robots across a range of tech levels. In the name of playability and simplicity, I argue that a craft with ANY sophont *crew* aboard must install regular controls and disregard robot brains. This does not preclude robot craft with "passengers" who never directly control the craft but can instruct the robot - the TL13 Esser Robot Drone from 101 Vehicles is an example of such a craft, which I have put as robot 107 in the robots spreadsheet.

Computers.
Ditching starship computers in favour of robot brains will unbalance the game. There is also extensive reference in Canon to ship's computers have extensive robotic systems as part of them, and when you compare robot brains to ship components, the brains are utterly trivial. It raises a host of questions. For example, what computer DM do we use in the "to hit" task in starship combat? I believe starship and spaceship computers are justified even with robot brains present based on the sheer grunt needed to navigate these vessels. The cut-off point in the design sequence is arbitrary - 100 dTons for a non-jump space craft vs. say 95 dTons for a "small craft" shuttle. But for a game that wishes to remain reasonably playable even with a flexible design system, there are going to be these "border" issues. Thus, standard robots are simply vehicles or small craft with robot brains replacing sophonts AND a computer; spacecraft / starships the robot brain only replaces particular crew members, mobile robots replace others.

Zero-G environment.
I'm quite chuffed I came up with that. I Googled thruster devices, researched Wikipedia on the physics - found out about "specific impulse" and engine performance, and googled various Gyroscope devices to come up with the figures. What I visualise is that Zero-G Hydroponic Farmbot (number 8) hanging there in the Zero-G orchard in space, with only occasional hissing and puffs that gently move it from one plant to the next. The thrust package assumes a package of 12 thrusters (2 for each dimension, 2 each for roll, pitch and yaw).

COACC and Wet Navy:
Here's another two cans of worms. Now that we've got an advanced draft for robots in the standard design sequence, do we open up COACC to robot-controlled craft? Well, of course, there's no question in my mind. My thinking is either lower-tech aircraft drones, or unusual situations, e.g. airship robot controlled airships on high-tech worlds looking for cheaper solutions than installing heavy fusion plants on everything. But it can probably be kept simple: simply adopt the crew replacement rules for vehicles, remove need for any cockpit and we're done.

For Terry McInnes' Wet Navy rules? Well, firstly I don't have a copy! Arrrgh! Will fix that by purchasing the Challenge Magazine CD from FFE. Looking forward to doing that. But I'm thinking of submersible robot designs with locomotion that fits the medium, basically, instead of the unsatisfying Undersea Harvester Robot's "aqua maneuver package". If the wet craft design rules are anything like the craft design sequence, I'd be confident the changes here would have it covered. Hopefully.

Should I add chapters addressing COACC and Wet-environment robots?

Combat and damage points:
I have come firmly to the view that robots' structural damage points should remain consistent with craft design - yes, that means I would rather live with damage 1/1 and armour 4 than complications over the toughness of smaller things. I have inserted a new rule that all craft have a base armour of (3) which stops the "kill the whole robot with a club" problem.

But something else needs to be raised. Robots being treated as craft means that hits are rolled for on the vehicular hits table. The initial roll yields a 50% chance of damage being applied to the superstructure (assuming we're going to simply ignore the "crew" result if there is no sophont crew); for the other 50%, the hit is applied to locomotion, a weapon or power. So it will be possible in these instances for the robot to be disabled but still able to fight after a couple of hits. I think this keeps some of the dramatic tension desired with the multiple-toughness-points scenario - the robot can be tough to kill in some ways.

These thoughts raise another thing - I should really address this in the ground combat section explicitly, shouldn't I?

Introduction
Lastly, the document is really crying out for an introduction. The obvious text is the introduction from Book 8, edited for a Rebellion context. The Referee's Companion already has an extensive chapter on Robot manufacture, so I would reference it in the introduction rather than replicate it. Dom, are you still reading this thread? Either way, I think at this point I should formally e-mail FFE for permission to lift a chapter or so of text for this supplement. I'd also like a pithy quote / flavour text, perhaps include a nod to Asimov.
 
OjnoTheRed said:
COACC and Wet Navy:
Here's another two cans of worms. Now that we've got an advanced draft for robots in the standard design sequence, do we open up COACC to robot-controlled craft? Well, of course, there's no question in my mind. My thinking is either lower-tech aircraft drones, or unusual situations, e.g. airship robot controlled airships on high-tech worlds looking for cheaper solutions than installing heavy fusion plants on everything. But it can probably be kept simple: simply adopt the crew replacement rules for vehicles, remove need for any cockpit and we're done.

For Terry McInnes' Wet Navy rules? Well, firstly I don't have a copy! Arrrgh! Will fix that by purchasing the Challenge Magazine CD from FFE. Looking forward to doing that. But I'm thinking of submersible robot designs with locomotion that fits the medium, basically, instead of the unsatisfying Undersea Harvester Robot's "aqua maneuver package". If the wet craft design rules are anything like the craft design sequence, I'd be confident the changes here would have it covered. Hopefully.

Should I add chapters addressing COACC and Wet-environment robots?
Click to expand...

Wet Navy uses the exact same design sequence. And yes, you should address COACC & Nautical Command robots and ground combat issues as well. It will save trouble in the long run. And it will give us something to use for warbots.

OjnoTheRed said:
Introduction
Lastly, the document is really crying out for an introduction. The obvious text is the introduction from Book 8, edited for a Rebellion context. The Referee's Companion already has an extensive chapter on Robot manufacture, so I would reference it in the introduction rather than replicate it. Dom, are you still reading this thread? Either way, I think at this point I should formally e-mail FFE for permission to lift a chapter or so of text for this supplement. I'd also like a pithy quote / flavour text, perhaps include a nod to Asimov.
Click to expand...

Good idea. If Marc buys off, maybe I can sell him on an expanded Citizens book.....
 
Thanks sfchbryan!

Just one update: the robots spreadsheet was an older version that didn't include the changes to the evaluation to put tools and appendages in the same section, and miscalculated Basic Environment.

I've updated the robot spreadsheet PDF version which is located here:

Robot Spreadsheet PDF

The first 13 designs are now much more up to scratch to the new proposed rules than before.

I would just like to draw readers' attention to design 108 "Automated Scout". This is our beloved Type S Scout, but minus the crew. This is the way that a fully robot-crewed starship might be designed.
 
OjnoTheRed said:
Thanks sfchbryan!

Just one update: the robots spreadsheet was an older version that didn't include the changes to the evaluation to put tools and appendages in the same section, and miscalculated Basic Environment.

I've updated the robot spreadsheet PDF version which is located here:

Robot Spreadsheet PDF

The first 13 designs are now much more up to scratch to the new proposed rules than before.

I would just like to draw readers' attention to design 108 "Automated Scout". This is our beloved Type S Scout, but minus the crew. This is the way that a fully robot-crewed starship might be designed.
Click to expand...

Thanks for the update. Quick suggestion. Could you add version numbers to your document? That way, I'd know which copy of Robots is the latest version.

I've been looking at OpenOffice to see how to separate the header for the first page of a chapter. No luck so far, but I am still looking.
 
Version number - yes great idea. What I'll do is put an extra worksheet at the front to log version with brief description of changes for each revision.
 
Minor updates to spreadsheet of robots.

PDF Version
Open Office Version

I have now updated through to design 23 with the new rules plus design evaluations. The version numbering I am assigning to the PDF Version only; the spreadsheet simply has the log of changes on the first sheet. If you're worried you didn't get Robots 1.1 or 1.2, don't worry, I missed actually posting them here, just logged those changes in the front sheet.

The supplement has been only undergoing minor spelling / grammar / typo changes as I see them. Feedback from sharp eyes still appreciated!

I put in my order for the Challenge Magazine CD from FFE ... and then added a few more I wanted because there were titles I didn't have ... and, errr, kind of got out of hand. Thank goodness for the high Australian dollar!
 
Dear Ojno -

First, thanks for your excellent work on Robots. To me, Book 8 always had the appearance of being a rush job - look at those half-finished tables, for one thing. (Totally agree on the need for an intro, BTW.)

You wrote:
OjnoTheRed said:
A few issues on substantive things.

Computers.
Ditching starship computers in favour of robot brains will unbalance the game.
Click to expand...

If you are interested, Joe D. Fugate Sr wrote two Q&A answers to questions about robot brains vs starship computers. I have a copy on my Beowulf Down site (address below). Follow this path:

--> Tavonni Repair Bays
----> Traveller Q&A
------> Traveller Q&A: Official Answers To Your Questions (Digest 11)
Look up the "How do robot brains differ from starship computers?" answer.

Also, go back up a level and go here:
------> Traveller Q&A: Official Answers To Your Questions (Digest 15)
Look up the even longer answer to the "How do robot brains and starship computers differ?" question.

I suggest that any rules mods be written in such a way as to keep to the spirit of Joe's response, and Traveller in general. One of Traveller's fundamental ideas are that people are more important than machines; it is people (i.e. the PCs) who become "Travellers" and go off adventuring.

The "design manual" for Trek's Enterprise says something similar (as a sidebar about why fabrication, not replication of components is used): "If you could build a starship by replicating it, you wouldn't need to." Relating this to Traveller, if you could replace flesh-and-blood pilots with robotic brains, you could extrapolate this to say "why have PC's"? Why not just send 'bots?" I know the canonical Hivers create autonomous warbots that not only pilot starships, but that run military campaigns to attack and subjugate their enemies, but this is for background flavour ("Aren't they so... alien!"). If you did this routinely in the foreground, your PC's could soon become redundant.

If you don't think there's enough of a technical show-stopper to prevent players from arguing the toss over robot brains vs ship's computers, here's one idea. The canonical explanation could blame the situation on the Imperium's laws (or insurance policies), especially the Shudusham Concords that say the creator of a robot is responsible for the actions of the robot - meaning they could be either tried or sued for misjumps or accidents that occur when a robotic pilot is in charge. That should put a damper on any firm that wants to allow one of their robot brains to be used as a pilot.

(Can you imagine the disclaimers in your robot brain operating manual?!!! "This guarantee becomes null and void if the robot brain is modified by an unauthorised repairer. No user-servicable parts inside. This device is not a toy. It is not a floatation device. Children should be supervised at all times." etc etc etc) ;)
 
Thanks Hyphen for that response, firstly I am flattered - in turn, I greatly admire your essay on pseudo-biological robots and the research into relative volumes of body parts! That has been incorporated directly into the supplement.

Thank you for pointing me towards those Q&A's regarding robot brains vs. starship computers. The one from Traveller's Digest #11 would seem to support the view I have taken that for starships / spacecraft of 100 displacement tons or greater, a starship computer is still required. The answer in #15 is interesting for in-game purposes.

I agree with you about Traveller being about the people in the game, and I think you are raising interesting questions about the line between living intelligent self-aware sophonts and robot brains and the limits of robot brains. The general background limit of TL15 in the OTU lends itself to saying that, even where robots are pushing towards the limits of replacing sophonts they are still machines. The TL17+ "magic" tech levels postulate true artificial intelligence - but in my mind this is just another way of saying that another form of intelligent life in the universe. This is a great science fiction trope but lends itself more to Battlestar Galactica and the Human / Cylon conflict, or Asimov's robot series of novels than the way I see Traveller - which is more in line with Asimov's Foundation series or Space Viking by H Beam Piper Of course, Referees around the traps will create their own take on their TU's and that's one of the attractions of the game.

But sticking with the TL15 limit, hence the limits in combat I have kept from Rob Prior's work - no interrupts allowed, and fairly heavy software requirements for dedicated warbots without further restrictions.

I think this extends to non-combat questions and would be worth adding to the "Robots in MegaTraveller" chapter. The question is: how much you trust a robot with an important task that requires initiative and assessing courses of action, especially where in a starship context the return time on a task is a minimum of two weeks?

As an exercise, I took the Type S Scout/Courier design and laid it out as a fully robot-crewed ship using the supplement as it stands thus far. The crew requirements are drawn directly from the Craft Design rules rather than the OTU dodgy one Pilot/Engineer for crew. I'll return to that later.

The two required bridge crew are replaced with robot brains; the engineer is replaced with a mobile robot. But what would such a robot crewed starship be used for? I can visualise it being sent on risky scouting missions where the fleet commander does not want to risk lives, or alternately as a jump torpedo to carry an important message such as a distress report if the fleet has lost a battle and the ship is detached to report back.

The problem in both cases, though, is that a sophont crew that can show initiative beyond explicit orders would be highly desirable. The risky scouting mission would be preferably lead by someone who understood the kinds of unexpected things that are worth checking out or investigating more closely before jumping back. The last-ditch dispatch of an urgent message from a dying fleet would be best served by a sophont who could communicate a 'sense' of what was going on and answer questions from admiralty on top of providing recordings.

I have also put up a design for a 20-dTon raider. It has one beam laser for armament which is devastating in a ground-support role, but with its high agility and 6G thrust it is intended for high-risk almost suicidal maneuvers to close with a powerful enemy to visual range and take out power plant or locomotion under the Pinpoint Location rule. It has no shipboard computer, hence its Defence DM is only constructed of Agility plus target size DM. The raider might be better with a triple-missile turret; only some playtesting will answer that question. But its severe restriction is the inability to interrupt - this could make or break a combat situation as a player can see an opening but is powerless to exploit it.

Lastly, though, I just want to return to the dodgy one-crew 100 dTon Type S Scout/Courier. I say dodgy because one-crew starships are simply not supported by the Craft Design Sequence. But it makes sense in the Traveller Universe even so that such craft exist. Robots supply the simply answer; one brain to replace one of the bridge crew, and a robot down in engineering; compared to the cost of the whole ship, the robot components are negligible. I hear echoes in my head of Luke Skywalker saying "fire up the power converters, R2".
 
Good news to share. Marc Miller has given permission for me to adapt the Introduction from Classic Traveller Book 8: Robots for the fan supplement, and has provided a picture to use on the front cover. He will post it (when it's finished) as a free download available on DriveThruRPG.

So. List of things to do.

1) Adapt introduction
2) Produce cover
3) I've got a couple of ideas for additions to the Robots in Mega Traveller chapter to extend the task library a bit.
4) Extend design system with notes on how robot brains might fit with COACC / Wet Navy (using the KISS principle)
5) Possibly add a design example to guide designers through the maze.

I am still adapting my Robots spreadsheet of designs, but I am changing my approach to speed things up. I will keep posting revised versions of both the supplement and the spreadsheet as I do them.
 
A new iteration of the supplement is out, and I am providing an update to the spreadsheet as well for those that are interested.

The supplement now has an introduction, some pictures used under Creative Commons, and I have extended the rules for using Robots in Mega Traveller. I have changed the cover page as well, but not yet laid out an actual 'cover'.

New Version of robots spreadsheet in PDF format - version 1.4
New Version of robot supplement in PDF format - version 1.1
OpenOffice Calc version of spreadsheet
OpenOffice Writer version of supplement
 
This next version of the supplement now includes front and back covers, a table of contents. I've extended the Robots in MegaTraveller a bit, and I have started inserting pictures.

New Supplement verion 1.2

I'm still interested in feedback on the rules, of course. But also on layout issues - breaking up the blocks of text, suggested placement of pictures (there are a few more that can go in) and any other comment on layout.
 
Hi Jonathan,

Just gone through the book.

A few things.

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?

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

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.

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.

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

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".

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?

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.

Dexterity for Grav vehicals should be better than air cushoned.

Enough for now.

Best regards,

Ewan
 
You must log in or register to reply here.

Similar threads

atpollard
CT Only: Book 8: Robots
Replies
3
Views
345
Commander Truestar
Commander Truestar
atpollard
Robots for "Backwater"
2
Replies
27
Views
1K
Condottiere
C
C
Auto-Jimmy v0.9.2: Robot Construction Release
Replies
8
Views
397
CthulhuStig
C
Spinward Scout
General Handling Adult themes in Traveller with Robots?
2
Replies
34
Views
2K
Spinward Scout
Spinward Scout
M
If you could "Fix" Classic Traveller how and what would you do?
2 3 4
Replies
60
Views
1K
Murph
M
Back
Top