Squaring Robots Book 8 with Mega Traveller

[BardicHeart]

I agree, that's too generous for hits and one of the things I considered. I also wanted to come up with a solution that, at least to some degree, "fit" within the vehicle table. DGP's solution is, in my opinion, too far to one extreme but I think Aramis went too far the other way, I'm hoping to work out a compromise somewhere in the middle if we can find one. I'm still tinkering with it. What I'd like to see is something that kind of fits the existing table without making robots so fragile they have no durability.

What I was thinking was sort of along these lines.

Although I see the logic Aramis used in calculating (volume x 10) / H = hits, where H is either 15 for inop or 6 for destroyed. I was thinking instead do it this way... (volume / H) x 10 = hits which generally gives us at least a 10/10 value. Then, use 200 liters or smaller for "robots" which would end up with hits of up to 4/10 max (at 200 liters) down to 0/1 at 5 liters. Not a perfect fit but its a start. Above 200 liters we do the regular vehicle thing with a default value of 10/10 until the volume goes high enough to raise it normally. Bit crude but its where I was starting at working this out. The more I look at it, the more I'm thinking the only solution may be to just work out an adjusted chart with pre-calculated hit values that creates a reasonable "point spread" between 5 liters and however high up we need to go. Or I may just scream a lot... sometimes it helps... sorta... o:

Plus as I was suggesting to Onjo in an email, we probably need to do some comparative examples of how "big" various volumes are. For example, an "average" human male would be about 70-75 liters. But as Onjo alread pointed out, a 500 liter cube is about 80cm on a side... doesn't seem that big until you start adding legs and stuff. I think it would be useful to help people designing robots to understand "how big is my robot"... literally.

Might have to work on some illustrations.

Anyway... I'm going to bed early... it was one of those Mondays. Back tomorrow.

 

[OjnoTheRed]

Yes, that might be workable, BardicHeart. On the last worksheet of the robot designs there's a spread of hull sizes up to 6750 kL (1/2 dT) with various ways of calculating the damage (including the current rules). I have done up a couple of ways of applying a formula there.

A note on volume, though. Note that appendages including arms and legs all CONSUME volume. That means that measurement of a box of 80cm x 80cm x 80cm being a bit bigger than 500 litres is the TOTAL volume of the robot including any appendages. For craft design in MegaTraveller, all components consume volume and so external appendages actually reduce the volume of the body of the robot. If an appendage is to be retractable, double the volume: the first half is for the volume the limb consumes of the space of the craft overall, and the second half is the allocate enough space to retract it into the remaining body.

David Jaques-Watson has a great article here that deals with (among other things) the actual volumes involved in a pseudo-biological robot of human form. He used his own body and measured the volume of his limbs, head, and whole body. It was such a nice essay I think it was picked up as a good science essay somewhere. Basically, if the human form was a total of 100 litres (i.e. 100kg - a man on the large, let us say even rotund side - me) then the proportions work out to be 30 litres for the legs, 9 for the arms, 9 for the head and 45 for the torso. So your starting point is a 90 litre hull with a 10% turret (i.e. 9 litre head), light arms only, and 15% each for the legs. That doesn't leave much room at all for other components (at minimum, brain and power supply).

The way that AB-101 and Telku were designed using Book 8, the starting point was a 100 litre and 80 litre chassis respectively, and then legs and arms were added and did not consume volume. On a straight reading, this doubled the size of both robots when accounting for all limbs - hardly convincing pseudo-bios. I have worked the designs to reduce fuel and other components, but AB-101 is still around 7 feet tall on a desirable BMI - near convincing. But Telku - who is meant to be 1.53m and a slight frame - is still far too large.

That 500 litre box above - I think it would be reasonable to say an unarmoured box of that nature can withstand a blow from a club - but a determined effort with a baseball bat might be enough to render it uncommercial to repair (effectively "destroyed"). That's a reasonable test of balance in my view.

 

[BardicHeart]

A note on volume, though. Note that appendages including arms and legs all CONSUME volume. That means that measurement of a box of 80cm x 80cm x 80cm being a bit bigger than 500 litres is the TOTAL volume of the robot including any appendages. For craft design in MegaTraveller, all components consume volume and so external appendages actually reduce the volume of the body of the robot. If an appendage is to be retractable, double the volume: the first half is for the volume the limb consumes of the space of the craft overall, and the second half is the allocate enough space to retract it into the remaining body.

I should have explained what I meant a bit better... but its a good example of why some diagrams would probably be really helpful.

While the volume remains the same, that box is merely the most compact possible shape... but in order to function, the most compact possible shape isn't necessarily optimal. When I was first looking at volumes and shapes I started with the basic idea of a humanoid shape for some sort of robot butler, companion bot, etc.

This lead to some odd research on the actual densities of human bodies (and now I know that a 1 liter volume of steak has a mass of about 1.042kg while 1 liter of chicken is about 0.95kg... the things we learn in games... LOL) Anyway, I settled on the density of water as a good median (which turns out to be pretty close to the actual density anyway), which is 1 kg = 1 liter volume. So, this gives us an average human male of about 70-75 kg (154 to 165 lbs for us Americans). If we convert this into a cube it turns out to be about 31cm on a side, or about 16.5 inches on a side. First time I looked at that it seemed too small and that lead to the above research on steak and chicken thinking I'd maybe made a mistake. Finding that basis to be realistic I then started "dissecting" that cube... for startes, my chest is not 16.5 inches thick... but it turns out my shoulders are almost exactly 16.5 inches wide (I'll stop here, that's about all anybody needs to know about my dimensions LOL). As I worked through this, reducing the depth of the cube I discovered that I ended up with "boxes" that were more than enough for my torso, legs, arms, and head... of course I weigh less than 75kg.

To come to the point... a 80cm cube is the most compact shape for a 500 liter robot... but once you start taking some of that volume for legs or other locomotion, lifter arms, etc.... its actual height, width, etc. will begin to change and it starts getting "bigger" even though the volume hasn't changed.

I've actually had a bit of fun with this, and even gotten a couple ideas for modifying starship design. I also got some interesting ideas for robots that "collapse" down to a compact form for transport or storage (include a little 5 liter ball shaped spybot). This sort of thing is what I meant about having some diagrams / illustrations to demonstrate how changes in the shape can radically alter the max dimensions of a robot, as well as giving comparisons between different volumes and maybe some "standard" chassis shapes. I think it would help add some clarity for those working to produce designs and understand "how big is my robot".

And now I'm going to go finish my half liter of chicken for lunch... :rofl:

 

[OjnoTheRed]

Mmmmmmm. Half litre of chicken.

Yes, I agree with your assumption that 1 litre = 1kg (roughly) for human anatomy. It turns out less than you might think - e.g. two cubic metres is considered cramped for passenger comfort in vehicle design. But it's the bendability of our body and practical room to move that's really in question.

If you puree'd a body, I'm pretty sure it would come close to 1 litre = 1kg.

I don't want to sound argumentative, but well, I am going to be anyway. I'm still convinced that a simple armour solution would be best to fix the toughness dilemma.

Consider this rough high-level flow chart of attacking a target in combat.

Notice that there are several routes towards the target remaining operable for the next round. The important thing is the net effect of the attack. If we assign armour of, say (2) - that is, value of 2 against melee weapons only - then our penetration 2 club won't damage any robot. This has the intended effect of avoiding the take-out-the-500kg-robot-in-one-swipe, while leaving the robot open to gun fire.

What I like about this solution is its simplicity - one small change to the rules and we've wiped away a whole lot of trouble. We don't have to rescale damage or come up with new tables or formulae.

2 more days until I post Rob's creation.

 

[aramis]

One problem, Onjo. P<A is only 0 damage if 100% rigid armor (as a robot would have) but for flexible or incomplete armor....

if₁ 10*P < A, then₁ damage = 0, else₁ if₂ P<A then₂ if₃ armor is full coverage then₃ damage = 0 else₃ Damage x0.1 else₂ if P<2*A....

 

[BardicHeart]

I think we have a different definition of simplicity :rofl: Kidding

No objections from me. I still prefer having more than 1/1 damage points but I'm just stubborn that way.

 

[conanlibrarian]

I do not like the armour solution, and would probably not use it. Armour and hits are two different things, armour is how hard something is, and hits is its toughness. High armour and low hits is too all or nothing to be usefull to describe some intresting in-game situations, since there is not much room for damaged robots that still operate.

Even the rules from the referees gaming kit, moderated by comon sense, is almost better. To improve upon this, the system needs to smoothly go from sensible values for small robots to sensible values for large vehicles, at the same time being somewhat close to the values for animals of the same size. (I think the house rule I described earlier achieves this, but I realize it is a bit simplistic.)

I guess this is not adressed in the draft robot suplement, but I still look forward to seeing this pdf!

 

[OjnoTheRed]

Firstly, as promised, the text of Rob Prior's work can be found here. It's a 50kb text file, and I have not modified it from what I have received. It is entirely Rob's work. If I get a request to take it down, I will.

He takes the position that robot design is extended craft design (i.e. craft hits not any other system). He got stuck a bit on control points.

A few points in summary:

• Starting point is Book 8 and MT Craft Design as for us
• Some minor modifications to Brains - power requirement per litre of brain
• Variable power interface, depending on power rating
• Weapons come straight from Imperial Encyclopedia with multipliers for installation
• Software range is identical, but Rob proposes a geometric progression of skill level vs. resource required. This would make robots less skilled in general.
• A nifty design evaluation where the Robots UPP is included in CraftID in the format NNxNNx - x because endurance and social standing are not relevant to robots (AB-101 role playing notwithstanding)
• Assigns tasks to unusual situations for robots - e.g. doing something they are not programmed for
• Some comment on robots in starships that could be expanded.
• Rob notes that "remember that open frames are treated as armour factor 13 and cannot have more armour added to this". I can't see that in the MegaTraveller rules or the errata myself - but as aramis has noted he was a guru at this, so it's probably me, not Rob.

Happy reading! It's not complete, but contains some great material that would be sensible to expand.

@conanlibrarian, you are right that armour and hits are two different things, but it is a very fine distinction. The important thing in-game is the net effect.

I do understand that the overall situation is that either the robot is disabled or it's untouched - there's no "gradually reducing the hit points". And yes, in a role-play game that would add drama to a session.

But combat in Traveller tends to be all-or-nothing. If you're struck with a weapon, there is a tendency for it to bounce off and do nothing, or render you at least unconscious. This is a tradition dating back to Classic Traveller. Reducing one characteristic to zero renders the character unconscious - and remember characteristics are 2D rolls, so a 2D 'first blood' wound has a good chance of doing this; a 3D typical gunshot wound will probably do this; and drag in 'exceptional success' being quite common in MegaTraveller and blood flows freely in combat.

I've spreadsheeted results from a range of animal and melee weapons, and compared the net result of a hit on an unarmoured human at 2/5 and a robot at 1/2.

Note that the full damage is applied to the 2/5 human, and the "resulting damage" - calculated after taking the armour of 3 into account - is applied to the robot. I have not bothered with the 10% distinction as noted by aramis because in any case the damage is rounded down to nothing in all cases.

I think the two columns are reasonably equivalent and operate in-game reasonably well.

To heighten the story - if it's important - we can take a liberal view of 'inoperable' and allow inventive players to extract that all-important security footage from the robots brain with an appropriate task. The story over-rules everything. But whether a robot can get up again and attempt another task in this combat - I think the results here are reasonable.

Note that if we applied armour of 13 to the open-frame robot, all the weapons listed would have bounced off.

 

[OjnoTheRed]

Rob notes that "remember that open frames are treated as armour factor 13 and cannot have more armour added to this". I can't see that in the MegaTraveller rules or the errata myself - but as aramis has noted he was a guru at this, so it's probably me, not Rob.

The hazards of unformatted text!

Actually, what he meant was "remember that open frames are treated as armour factor 1 and cannot have more armour added to this".

The "3" after the "1" indicates a footnote. Note 3 at the end of the text says: "Actually, I couldn't find this in the Referee's Manual, but it seems reasonable (there just isn't an outer skin to provide armour, the weight/price for a factor 1 represents the cost of bracing to support everything else. "

What I will be proposing is that all craft regardless of configuration or size have a built-in armour of (3) unless they have better armour installed. Robots will generally have an armour of 4 and will not often be open frame.

 

[OjnoTheRed]

I have created a rough draft of how the supplement might look. It is not complete. It is informed by all the discussion on this thread and I have listed contributors as joint authors. I have made calls on questions such as how volume, control, and the toughness dilemma will work, but it has all been informed by everyone's contributions.

The Robots In MegaTraveller chapter needs expansions with more tasks for dealing with robots, especially operation. A design example would strengthen the supplement. More discussion on "what is a robot" is needed, although this would involve a lot of direct copying from Book 8, JTAS 2 and JTAS 3 and perhaps other sources. If we did this, I would be seeking permissions and acknowledging sources.

Anyway, here are the links:
PDF Version
Microsoft Word Version
Open Office version

Note that this was originally edited in Open Office. I have provided the other versions for convenience of reading.

Note that the spreadsheet of robot designs I posted earlier is not done according to this supplement precisely. It is a mash of Book 8 and MT Craft Design including some older ideas of mine such as the Robot Config multipliers. I will post a spreadsheet updated to comply with this set of proposed rules in due course.

I would very much appreciate other's thoughts.

 

[Major B]

I would very much appreciate other's thoughts.

Ojno, first impression is that you are making me crazy (er?) because I'm caught up in working the tranfer of authority to the next unit here and don't have time to give you feedback.

But the good news for me is that I can print these and have some good reading for the transatlantic flight...

This is incredible work - thanks for it. I've been following the thread discussions and you will hear from me eventually.

 

[OjnoTheRed]

I'm slowly updating the Robots spreadsheet to test out the effect of variants to the design rules.

The links are the same but posted here again for your convenience:

Excel Version
Open Office Version

What I have done is implemented a "Control Points Provided" column for every robot ("CP Prov") to test the control rules. As it turns out, nearly all the robots have no need of any further control electronics when I use the rule (Total CP required) / (Brain CP multiplier) < 0.05 = no control panels required.

I also noted that the Slave Unit supplies 0.4 CP per litre (as discussed earlier in this thread) rather than the 0.08 of Computer Linked panels. What I experimented with was reducing each Slave Unit of 2 litres to supplying 0.16 CP. The results were interesting. There is one robot with no brain, entirely controlled by slave units - but for the rest what I did was put in a rudimentary brain if one was not present already. The one robot where we could put multiple slave units (the Waitress Slave Robot - number 39) is a good example of where slave units might be preferable to adding a brain - in short, cost.

But for the most part, introducing a rudimentary robot brain to make up the necessary controls was a preferable solution. I think this balances slave and master units very well compared to other electronic control, and makes slaved robots make more sense in my mind: a robot entirely controlled by slave units would need a master control where the operator has to 'stand in' and provide brain power for all slave function; limited autonomy in a slave makes better sense - the master/slave network is a distributed network. This moves our network model from a Mainframe / Dumb Terminal model (the original volume was, after all, published in the 80's) to a WAN / LAN model.

Two more things in the design spreadsheets to do:
(1) Modify the mass rating of each robot to provide a loaded / unloaded rating. Unloaded shall be the same as the MegaTraveller Craft Design (=no fuel, no cargo, no personnel). Loaded shall be the same PLUS the full load of all arms and tentacles.

(2) You may notice for the first five robots that the design evaluation is provided below the spreadsheeted components. The design evaluations are formula-based - that is, when you modify the design, the evaluation is updated.

The supplement needs some layout work - in particular, a set of charts MegaTraveller style that keep all of the tables together and layout the sequence in an easy-to-follow manner.

 

[sfchbryan]

I am looking at the spreadsheet right now, nice work, lots o' robots!

How difficult would it be to use this for building ships? My Excel-Fu is weak, since Excel 2011 is the first version that seems to work with equivalent Windows version. If this can scale up to ships, hmmm... I could rework all of the FSOSI ships.

Would you like some help with formatting & integrating text? I have gotten a lot of practice since I reformatted & retypeset my MT manuals.

 

[OjnoTheRed]

Would you like some help with formatting & integrating text? I have gotten a lot of practice since I reformatted & retypeset my MT manuals.

(sound of jaw hitting the floor)

You've reformatted & retypeset your MT manuals!?

Yeah, go for it! I'm using OpenOffice at the moment, and I've made some minor updates to the supplement and I'm starting to lay out the flow charts in the Craft Design Sequence style. Would very much like some help.

Word 2003
OpenOffice
PDF

Sorry, these are all still works-in-progress and so some of the updating I've done has messed up other things - and I'm struggling to replicate the flow chart "look" in Open Office. Any help appreciated - and let me know which format is most useful for you. And I should also list you as a contributing author, sfchbryan - you've contributed to this and other threads on this topic and I'm sure your ideas have informed what is in here as well.

Slight updates to the spreadsheets as well.

OpenOffice
Excel 2003

I'm now working on Robots perhaps having three weight ratings: loaded and unloaded defined the same way as the MegaTraveller Craft Design (i.e. unloaded is minus cargo and fuel), while the third rating "burdened" would mean loaded plus the full carrying capacity of all appendages.

The first five or so robots, as before, have minor updates to the evaluation.

 

[OjnoTheRed]

Sorry, forgot to add, yes, the spreadsheets should be immediately scalable to craft design for vehicles and ships.

 

[sfchbryan]

(sound of jaw hitting the floor)

You've reformatted & retypeset your MT manuals!?

Well, yeah, I got tired of constantly flipping through the manuals & losing post-it notes with errata. I started by just doing a couple of charts in the Craft Design chapter, & it sorta grew from there.

When you are between campaigns, some folks work craft design, some folks work scenarios, I decided to fix my manuals.....

I finished the Players' Manual, the Referee's Manual, & Referee's Companion. The Encyclopedia is about 75% done (I am adding all of the monographs that didnt' make the transition from CT - the Rebellion never happened IMTU, so I run with the GURPS timeline), World Builders Handbook is about 60% done & I consolidated 1 Small Step & the Early Tech supplement into my Referee's Manual.

As a seperate document, I took the the Wet Navy series of articles & added the expanded Char Gen for sailors from HIWG document 2128 - comes out to about the same size & scope as COACC. I haven't had a need for sailors, but if I ever do, there it is.

The rest of the MT manuals don't have very much errata at the moment, so they have been a lower priority. The MT CD has a number of very bad scans, but I have everything in dead tree, so they can be fairly easy to fix.

 

[OjnoTheRed]

Next iteration of the draft supplement!

PDF Version
Word Version
OpenOffice Version

This is now much more complete but there are a few things to settle.

Despite all of the discussion re: CP multipliers and INT 0 robots, I am contemplating a simpler solution. Let's say the "tech level intelligence DM" instead of Tech Level minus 12 becomes Tech Level minus 12 with a minimum of zero. Then ditch all of the complexity of the INT 0 rules calculating a CP multiplier. This will mean that robots rated at INT 0 will need to install control panels - but we'll allow fractions of as small as a litre which are very cheap way of installing the required number of CP. If this breaks designs of TL8 - TL11 still, perhaps we could say INT 0 = multiplier of 10 or something of that nature.

I've also outlined in a bit more detail the role of robots in combat including war.

There are also reasonably complete design flow charts, although the charts now use the new CP rule as outlined above, while the text still has the old rule. I've left it that way for comparison.

I'd really like a pointer towards some art, if anyone's got any ideas.

The use of pointlessly harsh criticism is now approved.

 

[OjnoTheRed]

I've uploaded another iteration of the supplement. Same links as in my previous post.

Firstly, I have made the flow chart and text say the same thing re: INT 0 robots - that is, no CP multiplier, but no negative INT modifier for robot brains less than TL12 either. I will attempt to test designs to see how bulky they might need to get re: control electronics.

Secondly, I think I've struck a simple rule for robot brains. This is a proposed change from what has previously been published.

It's simple: a robot brain replaces sophont operators / crew only. Not vehicular / ship computers. For vehicles and small craft, this simply means a brain replaces the vehicle / small craft operator (assuming commander and gunners made redundant). For starships and spacecraft, it means we still require a ship's computer for jump-grunt-calculation-thingy - mainly this is a game balance issue as I see it.

Control is balanced simply. If there are any sophont crew at all, Craft Design Sequence control panel provisions apply, and any robot brains do not supply a multiplier. If there are none, the robot brain multipliers apply for control of the craft. This represents the lack of interfaces and the compact electronics needed to directly wire the brain to craft sensors.

This effectively draws a line between a "robot" (i.e. a small vehicle with the operator replaced by a robot brain) and a craft that has robot brain control and/or robot crew.

I'm serious, by the way, about any criticism needing to be offered. I would still very much like another pair of eyes, or re-open any of the debates on this thread. I've made some calls - but I'm still open to argument.

I would also like to see if anyone thinks that the tasks and role playing sections need expansion - e.g. are there situations which would be useful to cover in a general way? Is combat with robots playable and reasonably balanced (having said that, the spirit of combat in Traveller always seemed to me to be if someone pulls out a gun, someone is likely to die).

My next task is to go back over the spreadsheet of designs and test the rule set in its current state against designs and evaluation. This is ambitious and will take a while, although a lot of the spreadsheet grunt-work is done already.

 

[sfchbryan]

I have gone through it.

The computer keeps eating my posts.

I have a number of suggestions on my other computer, I'll send tomorrow.

 

[OjnoTheRed]

Hey, sfchbryan, looking forward to hearing from you.

In the meantime, I'm continuing to make changes. Sorry if this is infuriating anyone!

My work on the robot design spreadsheet to update all designs to the proposed rules continues here in OpenOffice version.

I've done the first seven robots so far. The couple that were INT 0 needed quite a lot of space allocated to control electronics under the new rules for no CP multiplier for INT 0 robots. But the main result was a loss in fuel capacity / endurance - no great upsizes in volume so far, so I don't think I've broken the design system. Not yet, anyway.

But that INT 1+ bonus getting the great CP multiplier really helps robots of higher TL's / INT now.

I'm posting this update because the eighth robot only has the zero-G maneuver package for locomotion. I looked up the revised rules and discovered I hadn't ported it across. I spent some time researching typical compressed-gas thruster performance (and learned what 'specific impulse' is along the way, and its relationship to thrust) and I think I've landed some reasonable performance characteristics.

Anyway, revised supplement including Zero-G package rules under locomotion (in both the text and chart rules): PDF version and OpenOffice version.