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

T5 Worldgen Notes and Suggestons

Garnfellow

SOC-13
Peer of the Realm
In working on the “Missing Worlds of Magyar” I had a chance to play around with many pieces of T5 worldgen. Based on that experience, here are a few notes and suggestions:

1. Mainworld Orbit and WorldGen Sequence.

The mainworld orbit is determined early on in Checklist B, chart 2b (before mainworld size is generated), resulting in HZ-2, HZ-1, HZ, HZ+1, or HZ+2. Chart 2c determines whether the mainworld is a satellite or planet.

Checklist C (Worldgen) determines size. If size is 0 (asteroid belt) then the initial results of both chart 2b and 2c get thrown out. Belts can appear in virtually any orbit in the system and can’t be satellites.

Mainworld orbit is again considered much later on Checklist G, step P1. If the mainworld is an asteroid belt you roll on chart P2, which has a much wider range of orbits than chart 2b. But this begs the question, why couldn’t any airless mainworld have as wide a range of orbits as asteroid belts? It doesn’t matter if they’re in the hospitable zone or not.

A slight reshuffling of the worldgen sequence avoids redundancies, creates a smoother workflow, and gives us better opportunities to tweak downstream results:

  • Recommend moving step 1b (spaceports) to Checklist G and moving step 2a (homestar), 2b (mainworld orbit), 2c (satellite), and 4 (gas giants and belts) to Checklist C.
  • Recommend moving all worldgen from Checklist C up to B, so the whole UWP sequence of StSAHPGL-T is on one page. Rename Checklist B Worldgen.
  • Rename Checklist C System Basics. Add step 2a (homestar), 2b (mainworld orbit), 2c (satellite), and 4 (gas giants and belts) from old Checklist B. Also move to Checklist C the following steps from Checklist F: step 1 (generate system stars), 2 (spectral type and size), and 3 (place stars in orbit).
So you would generate the whole mainworld UWP of StSAHPGL before you generate any other system details. This allows mainworld data to inform and modify the system details and prevents us from going back a couple steps and potentially overwriting system results.

With this sequence, you only generate orbit and determine whether the mainworld is a satellite once. The following chart could be used in lieu of chart 2b:

Mainworld Orbit
Flux Size 0Size 1+
- 6 HZ - 2 HZ -2
- 5 HZ - 1 HZ -1
- 4 HZ HZ -1
- 3 HZ + 1 HZ -1
- 2 HZ + 2 HZ
- 1 HZ + 3 HZ
0 HZ + 4 HZ
+ 1 HZ + 5 HZ
+ 2 HZ + 6 HZ
+ 3 HZ + 7 HZ + 1
+ 4 HZ + 8 HZ + 1
+ 5 HZ + 9 HZ + 1
+ 6 HZ +10 HZ + 2
This reshuffling allow us to use mainworld details to modify system details.

Atmosphere, for example, could now modify homestar and companion. Say if Atmo > 0, homestar cannot be D. If Atmo >0 and a companion D star is generated, companion must be placed in far orbit.

Atmosphere could also modify mainworld orbit, allowing any world without a breathable atmosphere -- and not just belts -- to range further from the hospitable zone. Take the table above and substitute “Atmosphere” for “Size” and you’re done. You could also create an intermediary column or two between for Atmo codes of 123 or ABCDEF.

Similarly, size could (should?) influence whether the mainworld is a satellite or not -- smaller worlds might get a DM making them more likely to be satellites, bigger worlds might be less likely.
 
2. Climate Trade Classes

The climate codes, particularly Frozen (Fr), are a little odd. It is not clear whether or not Tropic (Tr) and Tundra (Tu) replace Hot (Ho) or Cold (Co) or appear in addition to the latter codes. I think it’s redundant to include both: all Tropic worlds are Hot, all Tundra worlds are Cold. Tundra and Tropic indicate worlds that otherwise would be highly desirable to humans but for the temperature.

Frozen is truly strange because the restrictions are so different than the other climate codes: HZ +2, size >1 and < A, Hydro >0. I’m just not sure what that’s supposed to model.

Here are a few theoretical worlds in different orbits to illustrate what I’m talking about.

ExampleUWPHZHZ+1HZ+2
AX000000-0-Co-
BX111000-0-Co-
CX222000-0-CoFr
DX550000-0-Co-
EX666000-0-TuFr
FXAAA000-0-Co-
It seems odd that an asteroid belt (A) would ever have any climate code, and it seems odd that one would qualify for Cold when in the HZ +1 orbit but would not qualify as Frozen in HZ +2.

Why does hydro drive Frozen? Why do examples C and E qualify as Frozen but example D does not?

And it seems odd that a BigWorld (F) would qualify for Cold but not for Frozen due to Size.

Maybe Cold and Hot codes should require size 2+ or maybe even better Atmosphere 1+?

And maybe Frozen should be extended to include sizes A through F?
 
3. Non-Mainworld Restrictions

T5 places two hard restrictions on non-mainworlds: spaceports instead of starports, and population capped at mainworld population -1. These restrictions have been in Traveller for a long time, but don’t necessarily need to be in T5. The new Importance mechanic shows us that starport and population certainly influence a world’s importance, but are not the sole determinants.

Remote systems in the same hex as the mainworld’s star would be a good case to allow exceptions to one or both of these restrictions, using the logic from “Statistics from the Second Imperial Grand Survey” from the Travellers’ Digest 10 (1987). In that article the Scout Service automatically counts remote systems as major worlds separate from the mainworld.

I would recommend that, if the system has a secondary star in far orbit, when using the Other Worlds sequence in Chart G generate the first non-mainworld orbiting that far companion using the mainworld generation sequence with no restrictions. If the non-mainworld ends up with a starport better than the mainworld, the non-mainworld becomes the mainworld.

For example, you generate a mainworld with UWP of B555555-6. The primary star has a far companion. When generating the first world orbiting the far companion you use the mainworld generation sequence and get C666666-6. The first world is still the mainworld but there is a second, more populous non-mainworld with an inferior starport.

Let’s use another example: you generate a mainworld with UWP of B555555-6. The first non-mainworld generated around the far companion has a UWP of A444444-A. In this case the second world is declared the mainworld. The first world gets to keep its class B starport and population, but otherwise is considered a non-mainworld.

This one little tweak gives us a few more interesting options in system generation.
 
4. Wordlets and Satellites

Chart G, Other Worlds, notes that the total number of worlds in the system "does not include Worldlets and Satellites (except if the MainWorld is a Satellite)" (413). But it's not clear that either prohibition is useful or desirable.

I think the rationale is that it's too easy for a large number of Satellites and Worldlets to dominate a system world count; removing them from the count gives the referee more latitude. For example, a typical system has 7 other worlds plus 1.5 Gas Giants. A Gas Giant has an average of 2.5 Satellites so an average system has 3.75 Gas Giant Satellites, more than half of our average total of other worlds.

But on the other hand, if you are using a more rigorous system generation method like GURPS Space it becomes very hard to find a reasonable orbital pattern for a binary or trinary stellar system that can accommodate all of T5's other worlds without counting Satellites.

The other problem with eliminating Satellites from the total world count in the system is that many satellites are going to be populated and more important than many other worlds in the system. Terra’s own Satellite Luna, for example, would not be included in the system world count – and Luna is canonically established as an important world in the Sol system. In fact, a Satellite of the mainworld is probably the most likely secondary world for development simply due to proximity.

I recommend adding a step to Chart G, P1 right before “Place Gas Giants”: Determine Mainworld Satellites. If the mainworld is not a Satellite or Asteroid Belt, determine number of Satellites using Table S. These worlds are included in the total system count.

In any case, the rationales for excluding Satellites from the world count doesn’t really apply to Wordlets. There is roughly a 17% chance that any non-mainworld will be a Wordlet. If Worldlets do not count toward the system's total number of worlds, why do they appear on the world type tables? If I'm generating a system, trying to determine what the other worlds are like, a result of Worldlet is a waste of time.

Further, the Population of a Worldlet is generated using 2D - 2, with Pop capped at the mainworld's pop -1. Worldlets, then, are much more likely to be populated than Iceworlds, RadWorlds, Inferno worlds, Inner Worlds, or Stormworlds. And to my mind, that makes them more likely to be of interest. So my recommendation is to include Worldlets in the system world count.

So, to sum up, I would recommend changing the text on 413 to read something like, "Satellites are not normally included in the system world count. Two exceptions are MainWorlds that are Satellites, or Satellites that orbit the MainWorld."
 
Last edited:
5. Other World Sizes

While we’re talking about Worldlets, here we have a little bit of T5 strangeness. Worldlet size is generated by 1D-3, but no minimum size is specified. If we allow Worldelt Size to be 0, then 50% of all Wordlets are technically Planetoid Belts. But the total number of Planetoid Belts in the system was already generated far earlier . . . back on Chart B in the unrevised procedure or Chart C in my recommended revision. In either case, do we override the earlier results? (Note that Planetoid Belt is not a result on the other world tables.)

And for that matter, the size for Inner Worlds and Hospitables are generated by the standard 2D -2. This means 2.78% of all Hospitables and Inner Worlds are actually Planetoid Belts and 25% qualify for Worldlet status. Further, the size range for BigWorlds overlaps with Inner Worlds and Hospitables. Nothing else in the UWP but size distinguishes these four world types.

The various other world types in T5 suffer from a lack of distinctiveness anyway, so I recommend tweaking the world type descriptions to remove this overlap.
  • Worldlet: Size 1D - 3, minimum of 1
  • Inner and Hospitable: Size 1D + 3
  • BigWorld: Size 1D + 9
 
6. More Distinct Other World Parameters

Building on the suggested tweaks to size, in order to create more distinction between the T5 Other World types and to reduce overlap between the types, I went back to GURPS Interstellar Wars and GURPS Space to look at different world types there.

GURPS groups worlds by size and then atmosphere type; T5 primarily by orbit. By slightly adjusting the T5 types we can get distinct world classifications that (roughly!) map over to one or more GURPS world types. The following table details my suggested tweaks to the T5 other world types:

Other World TypeRevised ParameterGURPS World Types
HospitableSize = 1D + 4, Atmo = 1D + 3, Hydro = Atmo + FluxStandard Garden worlds
PlanetoidsSize = 0, Atmo = 0, Hydro = 0Asteroid Belt
IceworldSize = 1D + 2, Atmo = 1D/3 + 9 (min 10), Hydro = 1D, Pop = 2D - 6Small, Standard, and Large Iceworlds
RadWorldSpaceport = Y, Size = 2D + 2, Atmo = 1D - 2, Hydro = 1D - 4, Pop = 0, Gov = 0, Law = 0, TL = 0Small, Standard, and Large Rock and Hadean worlds
InfernoSpaceport = Y, Size = 2D + 2, Atmo = 1D/3 + 10 (min 11), Hydro = 1D - 2, Pop = 0, Gov = 0, Law = 0, TL = 0Standard and Large Greenhouse
BigWorldSize = 1D + 10, Atmo = 1D + 3, Hydro = Atmo + FluxLarge Garden worlds
WorldletSize = 1D - 2 (min 1), Atmo = 1D - 5, Hydro = 1D - 5Tiny and Small Ice, Hadean, and Rock worlds
Inner WorldSize = 2D + 3, Atmo = 0, Hydro = 0, Pop = 2D - 4Standard and Large Cthonian Worlds
StormworldSize = 2D + 3, Atmo = 1D/3 + 9 (min 10), Hydro = 1D + 4, Pop = 2D - 6Standard and Large Ammonia, Glacier, Ocean, and Pre-Garden worlds
Many of these revised T5 types intentionally create combinations that could not be generated through standard mainworld generation – for example, a large world with a vacuum atmosphere.
 
Last edited:
And here are the same tweaks, but expressed as physical parameter ranges:

Other World TypeSizeAtmoHydroLocation
Planetoids000Any
Worldlet12340101Any
Iceworld345678AB123456Outer
Hospitable56789A4567890123456789AHospitable
Inner World56789ABCDEF00Inner
RadWorld456789ABCDE0123012Any
Stormworld56789ABCDEFAB56789AAny
Inferno456789ABCDEBC01234Inner, Hospitable
BigWorldBCDEFG4567890123456789AHospitable
With these tweaks, BigWorlds no longer make sense in the Inner or Outer system, but Stormworlds could work anywhere.
 
Last edited:
Amazing... it's always inspiring to see someone absorb the complex material at hand and synthesize something elegant from it. Thank you, for this.
 
Agreed, it takes me ages to work through the wonky system generation. A more streamlined approach is needed.
 
I agree with others, this raises excellent points about the other-world generation system.

Two thoughts I have.

In relation to mainworld and population: I like the way you formulate it; it would be possible to have a second world with a starport that is not the mainworld and is perhaps more populous. I had assumed that, by definition, the 'mainworld' was the most populous world in the system, hence the restriction. In MegaTraveller when you used the alternate extended system generation you generated the star first, placed all worlds and rolled for the UWP except for Starport. Then wherever the highest population landed was the mainworld and got the Starport; everything else got the spaceport. Generally the world in the HZ had the least negative DMs to population and would get the mainworld tag. But I think you're right, there's possibilities in the T5 system that allow interesting exceptions; and why should only one world in a system get a starport?

Size of worlds is an interesting question. I think the problem here is that the T5 rules are not sure whether to go for abstraction or not. Again, in the MegaTraveller system generation rules there was a size 'S' - a small world less than Size 1 but not part of a planetoid belt (and auto Atmos='0', Hydro='0'). I think T5 has ditched these in favour of MOARN. But this works against a 'Worldlet' classification at all; I would be in favour of lowering the number of satellites and worlds further and getting rid of Worldlets. That leaves us with less odd figures to calculate or adding back in a size 'S'.
 
I was just adding back in size 's' for '0' especially for satellites of planets, but also wherever it seemed appropriate, otherwise you seemed to end up with 'rings' around satellites around planets.

The rules around satellite sizes and orbits also needs some work.
 
In the stellar generation tables, pp.412, the table goes to 8.

For Spectral Type, the rules have: "Roll Flux for Primary. For all others, Primary Flux + (1D-1)."; Flux + 1D - 1 can be as high as 5 + 6 - 1 = 10.

For Stellar Size, the rules have: "Roll Flux for Primary. For all others, use Primary Flux + (1D+2)."; Flux + 1D + 2 can be as high as 5 + 6 + 2 = 13.

Has this been noted before?
 
I can't find a reference in 5.09 but I remember from errata discussions somewhere that the universal convention is that results that are higher than the maximum value in any table are taken to be the maximum value, and similarly for results below the minimum value.

This makes Brown Dwarfs more likely as companions for K and M spectral class stars; I would have thought it would make smaller companions more likely for smaller primaries but the table goes back to IV, V and VI over 'D'; although I find Traveller's version of spectral classification confusing at the smaller end compared to real life.
 
I can't find a reference in 5.09 but I remember from errata discussions somewhere that the universal convention is that results that are higher than the maximum value in any table are taken to be the maximum value, and similarly for results below the minimum value.

Thanks!

Other nits:

* It does not seem possible to generate O or B stars without some negative modifier applied to primary flux; admittedly, these should be very rare.

* Generating D (white dwarfs) as primaries seems inconsistent with the setting, although plausible in reality: http://www.centauri-dreams.org/?p=23911
 
Thanks!

Other nits:

* It does not seem possible to generate O or B stars without some negative modifier applied to primary flux; admittedly, these should be very rare.

* Generating D (white dwarfs) as primaries seems inconsistent with the setting, although plausible in reality: http://www.centauri-dreams.org/?p=23911

Interesting read. I find it amusing that the more we learn about exoplanets the less implausible CT worldgen seems. Hot jupiters, habitable planets orbitting a white dwarf star? I await the first evidence of a size 3 world with a dense oxygen-nitrogen atmosphere.
 
Thanks!

Other nits:

* It does not seem possible to generate O or B stars without some negative modifier applied to primary flux; admittedly, these should be very rare.

* Generating D (white dwarfs) as primaries seems inconsistent with the setting, although plausible in reality: http://www.centauri-dreams.org/?p=23911

I agree - the 'D' size classification is just wrong. "Red Dwarfs" simply mean an M or K spectral classification that is on the main sequence - i.e. size V. "Sub-dwarfs" mean size VI.

Really the system needs to be changed so perhaps a few White Dwarfs and Brown Dwarfs are generated and then skip the Size roll for those objects. But White Dwarfs would need nothing in the first few orbits being the husk of a red giant - so cold, more distant planets are the only options for settlement. And Brown Dwarfs are just cold.

In the words of Saul Ty, "the galaxy is a desolate place when it comes right down to it."
 
I agree - the 'D' size classification is just wrong. "Red Dwarfs" simply mean an M or K spectral classification that is on the main sequence - i.e. size V. "Sub-dwarfs" mean size VI.

The D notation was actually correct when Bk 6 was written... for what are now size VII.
And it's still used for Degenerate stars, it's just the "color" isn't the same as for big stars

D_Meaning
Astrong hydrogen lines
BNeutral Helium lines
OIonized Helium Lines
QCarbon Rich lines
Zpost-carbon metal-rich
Xuncertain (too Dim or weak lines)

When I first learned the spectral type system (about 1979), it went
OBAFGKMNS... with N and S being equivalent to the modern L and T.

N and S weren't found by observation, merely predicted strongly...
so they got abolished in the late 80's, and reused for other things...
and now, that we can see dim stuff, we can see what would have been N0-to S9, and they're now called L, T, and Y types. (L0-L5 are potentially stars, while L6-9, T0-9, and Y0-9 are brown dwarfs and even hot gas superjovians)

And, since the MK system's D codes for white dwarfs are now deprecated, some astronomers are taking to using Draper's notation again
c_ supergiant (0, Ia Ib)
g_ giant (II, III)
sg_ subgiant (IV)
d_ Dwarf (V)

Note that I've seen uses of
sd_ subdwarf (VI)
wd_ (VII)
but can't find them at the moment. They're almost always used with the Harvard color..


So, the Harvard colors as currently used, as best I can figure:

Codecolor Labeltemperature (° K)
OBlue> 25,000 K
WWolf-Rayet (low absorption)> 25,000 K
BBlue11,000 - 25,000
ABlue7,500 - 11,000
FBlue to White6,000 - 7,500
GWhite to Yellow5,000 - 6,000
KOrange to Red Ti/3,500 - 5,000
ROrange to Red Carbon Star3,500 - 5,000
MRed[2000] — 3,500
NRed Carbon Star[2000] — 3,500
SRed Zi/Yt/Ba Star[2000] — 3,500
LBrown Dwarfs1,300 – 2,000
TMethane Dwarfs700 to 1,300
YCool Dwarfs < 700

The coldest item formally admitted to the catalogues using the notations, according to Hillyard, is an L10 at about 600°, but it should be a Y0 or Y1. Two more candidates are noted, one of which is 375° K... just above liquid water at Std pressure, but may have hot water under pressure at surface...

Also note: the L0-L5 range may include some brown dwarf stars, not just brown dwarf planets.

http://www.whillyard.com/science-pages/type-lty-dwarfs.html
http://www.skyandtelescope.com/astronomy-resources/the-spectral-types-of-stars/
http://www.star.ucl.ac.uk/~pac/spectral_classification.html
http://www.star.ucl.ac.uk/~pac/obafgkmrns.html
http://btc.montana.edu/ceres/malcolm/cd/universe/assets/multimedia/spectral_classification.pdf
http://www.astronomy.villanova.edu/lward/Seattle Poster Final.pdf
 
Last edited:
Thanks for that aramis - really useful explanation and summary. Of course astronomy has developed since Book 6 was published.

It would be good to set up a star generation table based on the updated astronomy!
 
Back
Top