• 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

OK, I've had a chance to go over the design problems that Ewan spotted.

1) Animal Care Robot.
Somehow had put CPU usage for High Data Logic at 5 instead of 8, hence the missing 3 CPU needed that Ewan spotted. Upped Linear CPU by 3, reduced fuel volume to compensate.

2) Janitor Bot
Had allocated the Janitor skill to Storage instead of CPU. This design was done prior to deciding on the rule that at least a level-1 resource in the skill must be resident in CPU, had not corrected the design for establishing that rule. Substituted 2 CPU for 2 storage as a result. Ironically this increased volume available for fuel marginally.

3) Security Bot
Again, had split the CPU/Storage requirements 50/50 for skill programmes given the lack of any other way of doing it before establishing that level-1 rule above. After corrections, could correct the brain to a more efficient use of cost, and used up some more of that excess storage.

4) Starship Maintenance
Ditto as for Security Bot.

5) Elite Valet
A spreadsheet problem - I had managed to get the design evaluation to cross those values over. No impact on other components or overall size, weight, cost or power consumption.

In the next iteration of the supplement, I shall endeavour to ensure the corrected designs are included.

Thanks again.
 
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.

You're right about that...

Perhaps we should point that in the errata forum, and let DonM to give us an official answer.

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.

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.

Agreed with Ewan and you in that. I'd also won't allow the robotic brain to be protected against radiation/EMP, as they are too delicate for that (mostly against starsip sized weapons producing that radiation). This would partially balance it again..

We must think, though, that, being a small fighter/drone (not over, let's say, 50 ton, 100 at maximum) most hits would give it criticals, so being left brainless due to a hit won't usually be its main problem...

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.

I've allways seen this as a safety measure for personnel carrying crafts/ships. If you look at the drone in 101 vehicles, it has only one robot brain, even as rules say a flying craft must have a back up computer too, so I guess the same may be applied to space drones.

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.

The first time I envisoned such fighter/drone, was while studing how to make a squadron for BCS. The fighter/drones may allow to ignore (most would say cheat) the pilots limit (while the enemy has 10 ships only due to pilots limit, I oppose them with a dispersed structure carrier and 100-150 fighter/drones). The fighter /drone I designed was on the 8-10 dton range and armed with a fusion gun. I could never try it. It would have been a one-shoot weapon, as,if it was succesful, drones would either been forbiden or counted as pilots, as the intention of the limit was (IMO) to limit the fighters and avoiding massive fighter batles.

After that, I used those fighter/drone in a MT RPG campaign, but, just not to make them too strong, I ruled they need a person with robot operations and flet tactics, and a dedicated radio channel to direct a flight of 10 such fighters (or fraction), so limiting its use (curiously enough, as one player pointed me, both skills may be adquired at the staff college, so he said this position was one of the ones trained there).
 
Last edited:
Real life has intervened hence no updates in a little while. I'm still working through some issues I've found in the spreadsheet of robots in order to make sure the example designs I drop into the supplement are correct. What I've found now is that for the TL13+ designs I haven't allowed for the bonuses to weight and power output for fuel cells which are quite a bonus and make those designs flexible. I have also added an extended Fuel Cell table to the Design Charts in the supplement that spell out the values explicitly at TL10, TL13 and TL15.

I'm also going to systematically check brain resource allocation and generally go with a skill-1 resource present in CPU and the rest in storage, but some designs might allocate more to CPU to balance volume and weight considerations (although storage is far cheaper).

Another interesting robot related link is here. A new technology is emerging from aquatic animals that have a generic motion and direction sense that works under water.

Could we implement a robot-building sixth sense and what effect would it have on gameplay? We could come up with some arbitrary volume, weight power and price specs, but how they would help a robot in play would be more interesting.
 
FINAL - post your criticisms!

It's finally finished. The robot supplement, including a gruelling correction to all of the designs in the spreadsheet.

Robot Supplement - OpenOffice format
Robot Supplement - PDF format
Robot spreadsheet - OpenOffice format
Robot spreadsheet - PDF format

Please post any criticisms, comments, or flames to this. Utterly pointless and violent criticism is authorised (well, just don't get banned by the moderators). No observation is too small. And if someone's got a bright idea (e.g. a drawing ...?) to fill the horrible white space on page 23, please share!

No criticism is too big either ... although I should say I will be sticking to my guns on the thrust of the rule calls (e.g. the hit points debate comes to mind).

I am going to leave this here for one week for all to read, then e-mail Marc that it's finished so he can post it on DriveThruRPG as a free supplement. If there are substantial responses that require edits, I'll extend this time as necessary.
 
Hi Jonathan,

Just a quick one for the Credits page. It was me who found the draft of "Robots & Cyborgs" that I sent through to you.

Also for your consideration:

When performing a task that the Robot has a skill in, can they also gain additional +1 DMs for Computer Augmentation?

Say we have a mechanical breakdown in a ground car and we task AutoCarBot to go fix it. AutoCarBot is a human replacement robot (two arms, two hands, two legs, two eyes, two ears, one mouth, one head etc) who has Mechanical-1.

Now as AutoCarBot is essentially a computer in a mobile body, if we uploaded the car's CAD diagrams, parts specifications and work packages (i.e. how to make the car) into storage, would he get a +1 DM at fixing the car? or more?

What happens if we added a Haynes Manual as well? For those who haven't come accross them Haynes Manuel's are how to fix specific models from a human perspective i.e. take the cover off, like this, before you do that, and watch out for this because if you take it off by accident the steering will fall to bits (type thing). Would AutoCarBot get an additional +1 DM ?

Best regards,

Ewan
 
For Page 23. Ask permission to use one of the Robot picture from the MT manuals.

Page 36, page 37 of the Referees Source Book.

Also the pictures (and sidebars) in the book should be predonidently on the lower right hand column on the page and have a line border.

Best regards,

Ewan
 
Thanks Ewan!

To address the questions one by one.

Firstly, thank you, I had completely forgotten who had sent through Rob Prior's draft, I will update the credits page.

The Computer Augmentation DM is a great idea! Something like, if the robot has a brain interface or removable storage and can have the detailed data "slotted in" then they get the DM. Is there an existing rule to reference? That makes it easier to integrate.

Additionally, such a robot could extend its Education and Skill levels through learning and experience - but this is a much longer process than being given the manual. "The manual" would be in electronic form and represents accumulated knowledge that has come before and can much more easily be passed onto a new robot.

Weapon skills being resident in CPU: my thinking on this was that the speed of combat means that the brain needs to be able to access all of the necessary skill immediately without shuffling information back and forth out of storage. I'm open to other views on this (e.g. is this just a useless detail and we should make the rule simpler - at least level-1 must be allocated to CPU and the rest can go in storage?).

Now, I'm not just being picky, but the word "predonidently" - I'm hoping you mean "predominantly" or is this a layout term that I've not heard of. I will put a line around all of the remaining pictures.

On the positioning of pictures and sidebars: what I've gone with is even pages get them in the left hand column and odd pages get them in the right hand column. This means that when you print the book, they are on the outside of the page. They have gone upper or lower depending on how they interacted with the surrounding text - whatever looked better or sat better with headings and paragraph breaks got it.

Thanks for spotting those pictures - they are both good pictures! I'll give it some thought.

Thanks again.

Jono.
 
The Computer Augmentation DM is a great idea! Something like, if the robot has a brain interface or removable storage and can have the detailed data "slotted in" then they get the DM. Is there an existing rule to reference? That makes it easier to integrate.

Page 15 Ref's Manual

Weapon skills being resident in CPU: my thinking on this was that the speed of combat means that the brain needs to be able to access all of the necessary skill immediately without shuffling information back and forth out of storage. I'm open to other views on this (e.g. is this just a useless detail and we should make the rule simpler - at least level-1 must be allocated to CPU and the rest can go in storage?).

I think more on the lines of "adapt the rules to fit", so I would go with the main skill needs to be resident in CPU and the others can be in storage. If the main skill was grav vehicle then weapons would be in storage. I wouldn't comple the need for weapons to be in CPU.

Now, I'm not just being picky, but the word "predonidently" - I'm hoping you mean "predominantly" or is this a layout term that I've not heard of. I will put a line around all of the remaining pictures.

I meant "predominantly". Appologies there is no spell checker and I'm dyslexic.

Best regards,

Ewan

P.S. Space combat skill has 4 stars when it should have superscript 4?
 
Thanks Ewan. Yes, on the CPU resident requirements, I think the only one I'll go with is the vehicle skill must have at least a level-1 of resources resident in CPU, any other skills can go in either CPU or storage, and assume the brain can execute the software shuffling resources as necessary. Applying the KISS principle.

I'll read up on that rules reference, and put something together for computer augmentation.

Sorry about the spelling thing - grammar and spelling on the internet needs to be a bit loose and I hate it when posters pick on someone's grammar and spelling, just wanted to be sure I knew what you meant. I'll reconsider the placement of sidebars and pictures as you outlined, I'll have a look back through canon with that in mind.

Good spot on the asterisk vs. superscript 4 for the footnote on the software table! Thanks! More feedback like that.
 
New and probably FINAL version is here.

Supplement in PDF form
Supplement in Open Office Format
Spreadsheet of designs - PDF form
Spreadsheet of designs - Open Office format

I have included some words on computer augmentation (basically robots are assumed to get it in many circumstances assuming there's a Traveller equivalent to the Internet to interface to).

Some further designs are included in sidebars. The spreadsheet at design 12 - the Undersea Harvester Robot - now uses the Challenge Magazine Wet Navy series for the design. The design evaluation is now included in the supplement on page 19.

All layout has been tightened, and biased towards the bottom right for pictures and sidebars. Some sidebars still appear on the left for even numbered pages - this keeps them on the 'outside' if the book is printed.

The spreadsheet now includes a design evaluation for every robot in there. Open Document formats open fine in Microsoft Office 2007 and 2010 (earlier versions I haven't tested) so feel free to convert the files to your preferred format and have a play with them.

Unless I hear from posters before next Thursday my time (my timezone is GMT + 10 hours), I will be e-mailing this link to Marc for putting up on DriveThruRPG.
 
Hello all.

I sent this off, then embarrassingly spotted some errors in it, corrected them and sent it off again.

Here's the final version I've sent off:

Robot Supplement - PDF Form

I'll keep my subscription on this thread active, but for now, that's all from me.
 
So excited and proud. Marc Miller has published this as a MegaTraveller supplement on DriveThruRPG. It can be downloaded from DriveThruRPG here.
 
Don't play MegaTraveller myself - but thanks for sharing and way to go!

Quick skim - very nice quality and quite extensive.

(P.S. - should the Rech doc contain illustrations?)
 
Thanks everyone. @BytePro - the Rech System document really does need illustrations! Unfortunately did not include any artwork. I'm still reasonably pleased to share it, though.

For the Robot project, I wanted to lay it out a bit more professionally.
 
Back
Top