Date: Fri, 27 Oct 89 09:26:09 PDT
From: Bill Morrison (Coordinator) [email removed]
Reply-To: [email removed]
Subject: Traveller System Generation Group Digest V1 #1
To: [email removed]
Traveller System Generation Fri, 27 Oct 89 Volume 1 : Issue 1
Today's Topics:
(And a proposal...)
3D space and usml
Area of Knowledge
Background? Me??
choice
Computer Background
Discussion group membership and programming workload
Gensec, Mapsub and more ramblings
In reponse to Bill's msg (2 msgs)
Maps
Maps, maps, maps
Maps and 3D space
Maps and 3D space (And a proposal...)
ok
profile
Re: What we should do
Request for background of group members
Starting point
Welcome [Comments on what we should do & background]
Welcome [What we should do & background]
Welcome to the Star System Discussion Group
What's in the works...
***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display. **
** All followups on this topic should be sent to [email removed] **
** They will be edited for clarity and resent to the Traveller Mailing **
** List in a following digest. **
***************************************************************************
First, I would like to give *much* thanks to Dan Corrin who made this
issue of the Star System Generation Group digest possible by supplying
me with a copy of his mailbox after I blew mine away.
- --Bill Morrison
[email removed]
Traveller Star System Group Coordinator
- ----------------------------------------------------------------------
From: [email removed]
Subject: (And a proposal...)
<Bill>
> 1) That we integrate existing software into one comprehensive
> package to generate systems in accordance with MegaTraveller
> guidelines. The existing software that (I think) we should
> integrate are James' mapsub program (PostScript output), and
> the "real" system generator. We would have to tweak the ...
I disagree. I have difficulty following the "real" system generator,(RSG)
plus how do we put in the data for the major planet? I was thinking of the
opposite use MegaTraveller (and WBH) then add elements from the RSG or other
systems to make it a unique product.
>
> Right now, we need a working prototype to give us something to play
> with. ...
Yes but we need some discussion to get the right prototype to start with.
perhaps a vote on some of the issues would give us a starting point...
- -Dan
- ------------------------------
From: [email removed]
Subject: 3D space and usml
>Last, are we going to open the 3D can of worms? It wouldn't be
>*that* difficult to doand it would be easy to implement realistic
>stellar distances, but there are a *lot* of Jump-1 shipd out there
>that could very easily get stuck in the sectors that we would generate.
I like the idea of using 3D space, but haven't been able to figure out how
to create maps that are both interesting and readable. I don't think that
Jump-1 ships would be affected too much, since the mean separation of stars
would not be changed.
All of this hierarchical universe-building sounds an awful lot like the
Universe Simulation Mailing List ([email removed]). For those of
you with internet access, try ftp'ing to hc.dspo.gov (192.12.184.4) to
check out the usml archives there.
-matt
- ------------------------------
From: [email removed]
Subject: Area of Knowledge
(A bit late, but...)
General: Astronomy (college level, 1 year, plus casual reading)
System formation/planetology (basic familiarity)
Geology (formation of continents, landforms, etc; 1
term, plus reading)
I have two VERY good textbooks on these subjects (the system formation
subsumed under astronomy); my experience is not deep, but I can do
basic reality checks.
Programming: BASIC (several years, casual)
PASCAL (2 terms)
Obviously, not a heavy programmer-type.
8 )
- ------------------------------
From: [email removed]
Subject: Background? Me??
My turn. I received my BSICS (Information & Computer Science) almost
3 yrs. ago from Georgia Tech. I've been programming for about 7 yrs.
in Pascal, Modula-2, C, and FORTRAN. Most of my background is in
networking and software engineering. The project I'm on now has
me dabbling in X11R3 and systems programming. Simply put, the only
experience that I have that will be worthwhile to the effort will be
software engineering and I'm sure everyone else has the same experience there.
- --Bill
- ------------------------------
From: [email removed]
Subject: Computer Background
[email removed]
[ stuff deleted ]
>>
>> Now for my questions:
>>
>> What machine is everyone working on...I have a sun 3/60 on my desk, and
Myself I am working on a HP 9000/850 super mini but I have access to all sorts
of Vaxes and 3Bxx machines.
>> 1) Political (only useful if sector/subsector is not owned by a single
>> government as most of the Imperium was)
A lot of my frontier worlds that lay outside the imperium (actually 99% of my
own campaign) falls into that category.
>> 2) Jump maps - There is a section of the old rules describing the
>> connectivity of stars based on their starport and distance. I take this
>> to be a transportation map, which is significantly different from the
>> usual Xboat maps
>> 3) Trade maps - A lot of worlds are good trade partners while others aren't
>> (I think the trade and commerce group would like somthing like this with
>> all the good trade routes marked perhaps as weighted vectors?)
As well, some of my worlds have import quotas and restrictions. In one of my
worlds, tea is a very valuable commodity. Too much of it imported at any one
time causes enough of an outflow of cash and goods to cause problems with the
economy.
>> 4) Navigation maps - Stuff as much data onto the map as possible for players
>> to make visual comparison of destination worlds (This is the closest to the
Here you would want to mark navigational beacons and the like as well as post
the frequencies that are used by the starport control authorities as well as
transponder requirements...
>> current maps)
>> 5) Strategic Maps - (This is still a foggy concept) Presumably the military
>> would want different information on their maps than the civilians...
>>
Pete
- ------------------------------
From: [email removed]
Subject: choice
Like Bill, I am also in favor of the first choice. Except the project
leader is going to be difficult to pick. And it would be hard for the leader
to decide who does what too.
- ------------------------------
From: [email removed]
Subject: Computer Background
I have been programming in C for 7 years, none for C++. I have a B.Sc from
UWO, and I am finishing my Master's Thesis in a dual concentration:
Software Engineering and Computer Graphics. My specialty is Visual Programming
I have been on 3 fairly large projects, once as chief programmer, and once
as Project leader. (Note: I don't particularly want to lead this project.)
Most of my experience is on Sun's and a Vax750 running 4.2BSD. My current
project involves me with translating a set of UNIX programs to the PC (Ick).
-Dan
- ------------------------------
From: [email removed]
Subject: Discussion group membership and programming workload
Currently, the discussion group has a membership of 12 people,
not all of whom are Computer Science/programmer types (not at
least from what I understand). First we need to determine how
many people in the group have programming skills (software
engineering, structured design, etc) -- just to get things
going. Then we can approach this in several ways:
1) Pick one of the programmers as lead (perhaps a co-lead also),
and have those individuals come up with a preliminary design
and then discuss the design with the list and then make coding
assignments to the remaining programmers. Those who are not
programmers will be the test/evaluation group and will be
responsible for making sure that the progam does everything
it is supposed to, and also try their hardest to get the
program to crash (we can't turn out a bad system ;-).
2) A more "free-for-all" approach (everybody does everything).
Everybody does the prelim design, evaluates each others
work to get rge final design. Then, everybody codes a
part.
There may be other options, but over the internet, I don't think
we can refine it much. Opinions?
I am in favor of #1 -- but those involved in the preliminary design
(everybody evaluates that to get the final design) must communicate.
Once they have a preliminary design, the discussion group evaluates
that and either rejects it, approves it, or can make changes to get
what they want. Once we have a final design, we can mix and match
people with modules to code (according to what they want to do, ability,
etc). This is the best way to ensure a modular system.
Now this will obviously have to be adjusted. Not all the programmers
may have the time to program, and I' sure there are those who don't
program as a profession but would love to work on the prelim design or
code on this system. Some people have sent email about their 'areas of expertise'
and I would like to have everybody post and design/coding experience just
so we know what we have the capabilities of doing.
- --Bill
- ------------------------------
From: [email removed]
Subject: Gensec, Mapsub and more ramblings
To: sysgen-group
Now that I have had a chance to look at Gensec and Mapsub, I think they could
be a good basis for future work. I particuarily like the postscript
output on the mapsub program.
The data I would like to see is as follows:
Size Data Map
1. Grand None at this level Contour Map of stars highlighting
(Info taken from level 2) rift regions.
2. Sector Star Locations, High Tiny squares with dots for stars (name
population worlds of high pop. planet?) (As in atlas of
indicated the imperium)
3. Subsector Standard gensec output As mapgen, perhaps with stats on left
side as in "Spinward marches"
4. Solar All planets basic info (No real precidence.perhaps a landscape
Stars' info. page with a scale of the system at the
top, and some details of the planets
E.G:
System:O-.-.--.---.----%----o-----------o-------------o----------o-----------.
Zone: I O
Moons: - - 1 2 - 24 16 9 3 -
etc.
5. Planetary Detailed info such as Standard squashed dodecahedron, with
temperature, tilt etc. major cities, roads etc. marked.
6. Regional ?Unknown? One "triangle" from planet map, more
cities, terrain marked.
7. Local ?Unknown? City map, jungle map, etc. I have
doubts about this one still.
As far a I can see, we will have to split the data file at some point, as all
the data would fill up too much space, and obscure the basics when the file
was editied. Perhaps if each system could be located exactly, a sorted database
could be maintained seperatley for the systems done in detail. Locating a
system in detail would only require identifying the secotr somehow, as the
location in the sector is already present. If memory serves me there are only
about 140 sectors described (not all in the same detail) in the official
Traveller/Megatraveller Universe. I hate to use the Imperial reference point
as the origin of the coordinate system. The Zho's would probably want to use
the center of the galixy as the origin, but that would probably result in
sector numbers being too large. (quick what's the radius of the galixy
divided by 10 parsecs?) Any ideas on what to use?
-Dan
P.S. There hasn't been much response yet to my last mailing (one private Email
message) is anybody out there?
- ------------------------------
From: [email removed]
Subject: In reponse to Bill's msg
To: sysgen-group
1 Which version of Traveller
I think we should use MegaTraveller. Mainly because Traveller is now
consider outdated. And really for this program to be useful, MegaTraveller
seems to make more sense.
2 Grand Survey
Well, I don't think Grand Survey for MT is out yet, but we should
use World Builder's Handbook. DGP's stuff is official as far as both GDW and
everyone else concerns. No reason why we shouldn't use it.
3 what type
I figure with all these people on this project, we should be able to
create a huge program that covers all aspect of it.
I do have a question about using C, I am wondering how many people know c++?
Mac
- ------------------------------
From: [email removed]
Subject: In reponse to Bill's msg
To: sysgen-group
I go for MT too. In the star system area, there are not great
quantities of differences that former Traveller players would complain
about.
I think the entire thing should be written for (Mega)TRAVELLER, not so
general-purpose that it makes life hard for referees who have to convert
from super-realistic real-world modeling into game terms. In
otherwords, I think we should use published game forms and symbols
for our output formats, wherever possible. This means I'd like to use
procedures adapted from the World Builder's Handbook and the MT Referee's
Manual.
I want to consider a modular program approach (okay, so I'm a UNIX
wizard and it shows). Maybe a set of filters that take the input and
randomly/user-guidedly generate additional information.
I am doig my first project in C++, having become fairly whizzy at C over
the last few years, and would enjoy using C++ instead of C. But, I
wouldn't chafe at using plain old C.
- ------------------------------
>From [email removed] Fri Oct 13 01:54:13 1989
Subject: Star System Group: Area of Expertise
To: sysgen-group
> I almost forgot - In order to help with the "realism" aspect of
> star system generation, I would appreciate anybody/everybody to let
> the group know their particular area of expertise (if applicable).
I have a broad knowledge of Astronomy and Astrophysics. It's not really
deep, but is about as deep as a Upper Division 6-month course in
Astronomy/Astrophysics would be at a major University. I was at the top
of my 1-year course in Classical Physics w/Calculus at my University. I
play with Simulation of Physical systems on the computer. I am somewhat
familiar (broad but not deep) about planetary geology (or whatever you
call what we learn from Mariner, Pioneer and Voyager). I have some
familiarity with Biochemistry and Biology, broad but not deep at all. I
love all knowledge, and tend to be a generalist. I read Scientific
American cover-to-cover, but tend to skim on biochemistry and
anthropology.
I have a BSCS and much experience in programming on Unix systems. I am
one of the handful the power-users and wizards in my engineering group
of about 50 people where I work. I am a computer and science nerd.
- ------------------------------
From: [email removed]
Subject: Maps
To: sysgen-group
In Archive Message Number 621,
Richard Johnson [email removed] writes:
> I am getting tired of new/better/different ways to map sectors and
> subsectors. I've already got all I can handle.
Yes, it does seem to be the thing everyone does first when they come to
Traveller. I remember spending many hours rolling dice coming up with
my first subsector in about 1980. There are a lot of systems in a
subsector. You have some useful suggestions for the people on the Star
System Digest group.
As for generating minor bodies in a stellar system, well, I would tend
to think you'd be rather overwhelmed by detail. Still, it wouldn't be
unreasonable to list the major planetoids in a system and map out the
Trojan points 60 degrees before and after large gas giant planets. Any
system will have planetoids of some kind.
The orbital map would be easy; it would be simple to derive interesting
orbits where satellites would be likely to be concentrated. For economy
reasons, most satellites live in low planetary orbit, whereas those that
need to hover over the same point in space by definition must be boosted
to Geosynch.
World/Satellite maps, both physical and political, have always been a
fascinating topic to me, and undoubtedly it is a very complicated one.
A real simulation designer's nightmare. But it sounds like fun
research. My previous exposure to this sort of idea was in generating a
map of terrain, simulated by volcanoes, then raining on it and letting
the water drain to locate rivers and lakes. I met with mixed success.
Generating Life forms should be possible using clever randomized tables.
One could come up with a list of general attributes the larger popular
creatures on the planet have (like on earth, they have hair and four
legs, etc.), the vary it to generate different creatures. The tables
and mechanism for doing this would be probably be good material for
submission to the Traveller's Digest, too.
What is a "net list"; Is it a listing describing the attributes of each
object/hex printed on the map? If it is, this sounds valuable:
Player: "what do we get when we scan this hex by the ocean?"
Ref: "Hex 2109 on the planet map, let's look it up. Uh-huh. Sensors
reveal a major city with a metropolitan/suburb area of 12km x 15km in
size, a major river passing through on its way to the ocean, and a class
F Spaceport. Library data indicates that this city has a population of
1.4 million inhabitants, and is called Port City."
Like I said before, I lean toward developing output forms that are
recognized for their similarity to existing forms published by GDW and
Digest Group.
James
- ------------------------------
From: [email removed]
Subject: Maps, maps, maps
To: sysgen-group
Just got this mail from Richard. Thought it'd be okay to share it with
you guys as useful feedback.
James
- ------- Forwarded Message
To: [email removed]
Date: Sun Oct 15 19:22:45 1989
>From : [email removed] (Richard Johnson)
James;
We're in complete agreement about maps needing to match the needs
of the users AND be somewhat compatible with what has gone before.
Your idea is better than a net list (complete concordance of what
is in each hex on the map). A net list is an idea from CAD programs
that tells which pins on which chip are connected together, and
sometimes some limited information about those chips.
My original thought went something more like what you said, though.
This would enable the party (or each player) to have a map with
"player" information, the GM to have a similar one and a complete
description with confidential information.
Richard
- ------- End of Forwarded Message
- ------------------------------
From: [email removed]
Subject: Maps and 3D space
> Ted Kim writes:
>
> >>
> >> I think, I would like to have one package to generate the natural
> >> universe and then a separate one to populate and civilize it. The
> >> second program would have to take into account the differences between
> >> races and different star empires. It could operate on several scales.
> >>
>
> Last, are we going to open the 3D can of worms? It wouldn't be
> *that* difficult to doand it would be easy to implement realistic
> stellar distances, but there are a *lot* of Jump-1 shipd out there
> that could very easily get stuck in the sectors that we would generate.
>
<Matt>
> I like the idea of using 3D space, but haven't been able to figure out how
> to create maps that are both interesting and readable. I don't think that
> Jump-1 ships would be affected too much, since the mean separation of stars
> would not be changed.
I have an old game from TSR (Star Empires?) that uses squares (a very old game)
with dots representing the stars and a number representing the height above/
below the ecliptic. Unfortunately it is difficult to give much additional
information without cluttering the display. This solution does make the stars
easy to locate (unlike Traveller.. oops. 2300AD which however is very accurate)
Jump-1 ships *are* a problem, as making a 3D map dense enough for their
movement will cause considerable congestion in the hexes.
>
> All of this hierarchical universe-building sounds an awful lot like the
> Universe Simulation Mailing List ([email removed]). For those of
> you with internet access, try ftp'ing to hc.dspo.gov (192.12.184.4) to
> check out the usml archives there.
>
Maybe they have some good ideas....
A lot of this discussion can be summarized as: are we going to support the
standard Traveller/MegaTraveller rules and supplements or do some other
interesting things as well.
As far as I am concerned being on the traveller list, we should first
and foremost be able to represent the Tr/MTr system as is with no enhancements
from any program we generate. Then worry about the optional details.
Now let me argue against myself: We need to have some idea what enhancements
we are going to use to allow us to design the program and data structures
well. If our program is exactly according to the books, then we are not really
adding anything and may be in violation of copyright.
Furthermore I noticed an ad by DGP in the back of world builder's handbook:
Coming in Jan 1990, World builders handbook for computer, as well as the
second? survey data (ie. stats for the 11000 worlds)
This will be available for PC's, Mac, and two others of that ilk.
What does everyone assume about stellar phenomenon? There has never been a
place for generating black holes, neutron stars, nebula, dust clouds,
pulsars etc. I have always assumed that there were a lot more stars out there
than are actually drawn on the map. The other "unmapped" stars would only
be of passing interest to Scientists (1 month research trips and unmanned
montioring probes). All of these "stars" would have two things in common:
a) no fuel to speak of (interstellar hydrogen) b) no solid surfaces to
put bases or other strucures on.
Therefore they are not placed on the maps as jumpspace effectively ignores
everything between the entry/exit points (maybe the navigator worries about
them and their possible influence).
<I think I will post this last bit to the entire list as well>
-Dan (verbose as usual)
- ------------------------------
From: [email removed]
Subject: Maps and 3D space (And a proposal...)
Dan has a good point in that we need to get going with something. Here
is my proposal:
1) That we integrate existing software into one comprehensive
package to generate systems in accordance with MegaTraveller
guidelines. The existing software that (I think) we should
integrate are James' mapsub program (PostScript output), and
the "real" system generator. We would have to tweak the
Traveller side of the program to take input from the "real"
side (in terms of hydrographic percentage, etc) for more
realistic systems, or vice-versa for "tunable" systems.
2) We plan on the next extension to the system generator, which
can be whatever the group wants (Determining trade routes,
implementing 3D, planetary mapping, whatever).
Right now, we need a working prototype to give us something to play
with. We might want to consider getting a group of people to Alpha test
whatever we develope and tell us what else we might have overlooked.
For those of you that don't have these two programs, let me know and
I'll send you the source.
- --Bill
- ------------------------------
From: [email removed]
Subject: ok
So, we got about 20 people on this list. Now, I see a problem
here. If we are going to write a phototype program, how would we spilt the
task and work load?
- ------------------------------
From: [email removed]
Subject: profile
Well, since Bill asked for a post describing the programming experience.
here goes, I am a computer science major in Ohio state university. I have
been programming for 3 years now. 3 years of pascal, 2 years of c, and
4 month of C++. I have written programs ranging from less than 10 lines to
100,000 lines before.
Mac
- ------------------------------
From: [email removed]
Subject: Re: What we should do
To: sysgen-group
[First, I hope everybody got Peter's correct email address].
<>From dan>
>> need to be consistent with the data we generate. There is no way (correct >> me if I'm wrong) with a low denity and mass is going to have many heavy
>> elements to support that TL15 society.
>
> Define support...A TL15 society wouldn't be native to such a system, but it
>could be a game reserve and hunting park for the nobility.
OK. Caught me on that one. I've been in one too many games where there
was an advanced culture with nothing to support it.
>City map could be very difficult, but I don't see any problem with the
>others all should be optional however. I don't want 11000+
>planetary maps...
I agree. I was envisioning several programs that would work like UNIX
pipes: feed the output of one into the input of the next. If you
want a planet map, you would first have to have a sector map,
then you'ld have your subsector extracted from that. You feed that into
system generator to get the number of planets, etc. You'd extract the
one or more planets you were interested in and feed that into the
map generator. The hard part is that the cohesion between the subsector
and system generators have to be tight (too much interaction between
determining the types of planets, where they are, trade routes, X-boat
routes, etc). Ideas?
BTW, I heartily agree with the need for modularity. The programming of this
over thethe internet is going to get heady.
I'm working on a Sun-3/280 (for the moment). The project I'm on will be
over by January, so I don't know what system I'll be working on
then (maybe my PC :-). I'll still have email anyway.
- -- Bill
- ------------------------------
From: [email removed]
Subject: Request for background of group members
To: sysgen-group
I almost forgot - In order to help with the "realism" aspect of
star system generation, I would appreciate anybody/everybody to let
the group know their particular area of expertise (if applicable).
Metlay told me he knows a bit about Astrophysics so he can advise us
on the partical dynamics and evolution of star systems. Other than
what I pick up here and there, I know nothing (I think ;-) that might
help (I do know computer science and programming). If anyone knows
about planetary evolution and geology (formation of contenents, the
elemental mix on the "average planet of mass X", biology to
predict the type of life form (I know *that's* grasping at
straws :-) that might develope given the elements available on the
planet, or anything else, I'd appreciate you letting the group know.
- --Bill
- ------------------------------
From: [email removed]
Subject: Starting point
To: sysgen-group
I think Dan has come up with a good starting place on breaking
up the resolution and scope of the various levels. Each of
these levels (as applicable) could be an individual program
taking data from a collection of data files generated by the
appropriate other levels. I think that having one common
database store the information would simply be too large and
unwieldy (access times on low-end [PC} systems would be
horrendous). I think we could come up with some sort of "pointer"
system -- one file for sectors containing the bare bones information
and name pointers indicating the names of the file to go to for
the system, which would have the name of the file(s) to go to
for each planet, etc. Also, unwieldy but it would be simple
to implement -- the hardest part would be gaurenting unique file
names.
I also received a message indicating an optional way to modularize
a generation system -- at least at the universe level. Ted
Kim writes:
>>
>> I think, I would like to have one package to generate the natural
>> universe and then a separate one to populate and civilize it. The
>> second program would have to take into account the differences between
>> races and different star empires. It could operate on several scales.
>>
Last, are we going to open the 3D can of worms? It wouldn't be
*that* difficult to doand it would be easy to implement realistic
stellar distances, but there are a *lot* of Jump-1 shipd out there
that could very easily get stuck in the sectors that we would generate.
- --Bill
- ------------------------------
From: [email removed]
Subject: Welcome [Comments on what we should do & background]
To: sysgen-group
<>From Bill>
> what version(s) of Traveller do we want to support, and how 'realistic'
> do we want to get. Also, how many different generation systems do we
> want to work on (one for systems, one for specific information on the
> planets in each system, etc.).
I believe that there is no problem as to what we should cover, the old rules
for system generation are a subset of the Megatraveller rules, Megatraveller
just provides a labeling of the values presented in traveller (ie. wet world
instead of 60% hydrographics). Similarly with grand survey, it just provides
additonal information for the worlds (including a nifty plate tectonics and
surface mapping description). IMHO the "Program" should really be a series
of programs, each taking the system/subsector data to greater levels of detail,
If you don't use the Megatraveller rules for instance, stop running the
programs before the megatraveller info gets added.
BTW does anyone have a short form for Traveller and MegaTraveller so a discussion
of the differences doesn't take forever to type?
>
> Other considerations would be, do we want to adapt to something like the
> Grand Survey and/or the World Builders handbook (both of which I don't
> have - yet), how, too what extent, and copyright laws if we do.
I don't know if grand survey is still available...However, the World builders
handbook seems to cover everything in grand survey and grand census, but in
one book, and provides a more organized presentation.
> planets (some habitable) all in stable orbits, something like Niven's Tree
> world [I can't remember the name of the book, but it's a torus with no real
> ground, but habitable non the less]) - you get the idea. In any event, we
(The Integral Trees, and Smoke Ring I believe are the titles of the two books.)
> need to be consistent with the data we generate. There is no way (correct
> me if I'm wrong) with a low denity and mass is going to have many heavy
> elements to support that TL15 society.
Define support...A TL15 society wouldn't be native to such a system, but it
could be a game reserve and hunting park for the nobility. Often the most
interesting adventures occur when the GM makes up a reason for what looks to
be conflicting data on a world. However as a GM I often find it difficult to
make up the reasons.
>
> So main things to decide now:
>
> - Which version of Traveller (Classic and/or Mega) do we want to
> target?
Both...(Look up...Look way way up...) see earlier description.
> - Do we want to tie in with the Grand Survey and the World Builders
> Handbook?
Yes, as an optional program.
> - What type(s) and how many different generation system(s) do we want
> to create (sector/subsector/planetary info/ planetary map/city map)?
City map could be very difficult, but I don't see any problem with the others
all should be optional however. I don't want 11000+ planetary maps for a sector
map of the Imperium.
> - Aside from the standard information that any referee can find/make
> in the various books, what other useful information do we want
> to provide (planetary history, relations with the Imperium, etc)?
I usualy use a lot of other SFRPG systems as source books for traveller. They
quite often have alternate information on their planet descriptions. I will
mail these when I get a change to llok them up. One that sticks in my mind though
was a % value for the locals reaction to off-worlders (assuming outside the
starport.)
>
> I almost forgot - In order to help with the "realism" aspect of
> star system generation, I would appreciate anybody/everybody to let
> the group know their particular area of expertise (if applicable).
My area of expertise is 1) Master of Computer Science (almost completed)
2) Finished 2yrs out of 3 in astronomy program (was specializing in
stellar atmospheres) (Almost completed is the story of my life :-) )
<>From Mac>
>
> 2 Grand Survey
>
> Well, I don't think Grand Survey for MT is out yet, but we should
> use World Builder's Handbook. DGP's stuff is official as far as both GDW and
> everyone else concerns. No reason why we shouldn't use it.
World builders handbook *is* grand survey for MegaTraveller.
>
> I do have a question about using C, I am wondering how many people know c++?
>
Not only does the progammer have to know C++, but there has to be a C++ compiler
on everyone's machine. I think that we should stick to C as it is the "universal"
language for all UNIX machines.
Now for my questions:
What machine is everyone working on...I have a sun 3/60 on my desk, and
access to SPARCstation (Sun), MIPS M/2000, Silicon Graphics 4D/70 and Personal
Iris (Note all are UNIX machines but vary between BSD, BSDish, and SysV)
Copyright, In Canada, there is not a problem, as we are not doing this for
a monetary gain, and as long as there is a discaimer indicating that the
program is for those people who already own Traveller/MegaTraveller... I don't
know what the situation is in the States.
In any programming project among several people, coordination can be the most
difficult item. If I improve some code and you improve the same code, it can
take forever to get them the same. Remember modularity is a must.
I believe also that there cannot be too much information, just too much
presented at one time. Albedo while not important to most is essential
for calculating the temperature of the planet. If you want to fiddle with the
charateristics (ie. it is too cold for your garden planet) some of these
obscure statistics can be useful.
I find that most of my players cannot make sense of the traveller statistics
for a planet (eg. Fubar 0203-A456345-9 Na GAm) means nothing to them, thus
we saw the expansion of the sector map from just having dots Starport and
name to gross planet type, bases, gas giant symbols etc. Visuals are often
more understandable and should be present in any postscript representation.
As we have several types of maps for our planet (road maps, contour/geographical
maps, political maps) so should a complete sector/subsector map. The types of
maps I can think of right away are:
1) Political (only useful if sector/subsector is not owned by a single
government as most of the Imperium was)
2) Jump maps - There is a section of the old rules describing the
connectivity of stars based on their starport and distance. I take this
to be a transportation map, which is significantly different from the
usual Xboat maps
3) Trade maps - A lot of worlds are good trade partners while others aren't
(I think the trade and commerce group would like somthing like this with
all the good trade routes marked perhaps as weighted vectors?)
4) Navigation maps - Stuff as much data onto the map as possible for players
to make visual comparison of destination worlds (This is the closest to the
current maps)
5) Strategic Maps - (This is still a foggy concept) Presumably the military
would want different information on their maps than the civilians...
-Dan Corrin
- ------------------------------
From: [email removed]
Subject: Welcome [What we should do & background]
To: sysgen-group
To begin, I have BS's in computer science and astrophysics, but I've been
neglecting my astrophyics, so I'm probably a bit rusty.
> - Which version of Traveller (Classic and/or Mega) do we want to
> target?
I would rather design a program that can be used with any space RPG. I
wrote the "starform" program with that in mind, so if there is information
that you're not interested in, it is simple to ignore it. I'm fairly happy
with the output from starform, but it does tend to generate boring systems.
One thing I'd like is to be able to specify what planets/stars I'd like to
see in a given system ("Hmmm. How about a yellow star with a planet with
breathable atmosphere, bearable gravity, and no water...").
Also, I think C would be the most portable language to use. The starform
program used to be in Pascal, but I ported it to C for portability.
-matt
- ------------------------------
>From [email removed] Wed Oct 11 19:15:53 1989
Subject: Re: What we should do
Sorry to those of you who have already received this, but I had a typo in
my aliases list and it didn't get sent to everyone.
To begin, I have BS's in computer science and astrophysics, but I've been
neglecting my astrophyics, so I'm probably a bit rusty.
> - Which version of Traveller (Classic and/or Mega) do we want to
> target?
I would rather design a program that can be used with any space RPG. I
wrote the "starform" program with that in mind, so if there is information
that you're not interested in, it is simple to ignore it. I'm fairly happy
with the output from starform, but it does tend to generate boring systems.
One thing I'd like is to be able to specify what planets/stars I'd like to
see in a given system ("Hmmm. How about a yellow star with a planet with
breathable atmosphere, bearable gravity, and no water...").
Also, I think C would be the most portable language to use. The starform
program used to be in Pascal, but I ported it to C for portability.
-matt
- ------------------------------
From: [email removed]
Subject: Welcome to the Star System Discussion Group
To: sysgen-group
Welcome one and all to the Star System Generation Discussion group. I'm sure
most of you are wondering what we are going to do and what we should talk
about. Well, that's the first thing we have to decide. There are several
main points we need to consider before we even begin discussing what
we should include in our generation system(s): what we want to generate
(besides pure star systems), what type(s) of systems do we want to target,
what version(s) of Traveller do we want to support, and how 'realistic'
do we want to get. Also, how many different generation systems do we
want to work on (one for systems, one for specific information on the
planets in each system, etc.).
Other considerations would be, do we want to adapt to something like the
Grand Survey and/or the World Builders handbook (both of which I don't
have - yet), how, too what extent, and copyright laws if we do.
MY ROLE
- -------
I am merely coordinating communication between the members of the discussion
group and the rest of the Traveller Mailing List membership. I'll take
all of the messages each week, "digestify" them and post the summary to
the mailing list. Another job of mine is to make sure that we stay on
track with the topic of creating a viable star system generation system. I
am by no means dictator of this group. My job is to keep personality conflicts,
flaming, etc to a minimum. My vote on design issues and implementation counts
no more nor less than anyone elses. The next section describes my *opinion*
on where I think this group should go within the area of star system
generation and what we should do. If the majority of the group thinks
otherwise, we can change our methods.
OUR FUTURE
- ----------
I envision us taking functionality from James' PostScript program and the
"real" star system program and then adding lots of features for something
with lots of bells and whistles (with a varying level of detail at the
referees request, PostScript or ASCII output, and generating sector to the
planetary level of information). Things we can also add are planetary maps,
city maps, and anything anyone wants.
For those who want specifics, here is my humble opinion on what we
should aim for:
We should target both PC and UNIX system primarily, with other machines
(Atari/Amiga, VMS) systems pending demand - and our time). We should use
C as the language of choice (since that's what most people know). Down
the line we may want to port to PASCAL, FORTRAN, and (oh no!) BASIC
for those on other platforms (VMS and PCs), but that's a long way off. I
would like to see the program be as realistic as possible without giving
too much 'technical' information that doesn't do much for the game(eg.
albeido, etc). However, we need to add a 'make believe' mode for outrageous
star systems (eg. ringworlds, Dyson spheres, trinary systems with 15
planets (some habitable) all in stable orbits, something like Niven's Tree
world [I can't remember the name of the book, but it's a torus with no real
ground, but habitable non the less]) - you get the idea. In any event, we
need to be consistent with the data we generate. There is no way (correct
me if I'm wrong) with a low denity and mass is going to have many heavy
elements to support that TL15 society.
But this all comes from what people want. Well, you are all
players and/or referees - what do YOU want out of a system? We've all
heard lots of "Wouldn't it be nice if..." questions. Let's give them
what they want.
So main things to decide now:
- Which version of Traveller (Classic and/or Mega) do we want to
target?
- Do we want to tie in with the Grand Survey and the World Builders
Handbook?
- What type(s) and how many different generation system(s) do we want
to create (sector/subsector/planetary info/ planetary map/city map)?
- Aside from the standard information that any referee can find/make
in the various books, what other useful information do we want
to provide (planetary history, relations with the Imperium, etc)?
- Are James Perkins' subsector program and Matt Burdick's "real"
generation program useful starting points?
Well, you can tell already that I ramble.
Well, that's enough from me. You have my ideas on where I think the group
should head. We have some decisions to make.
- --Bill Morrison
- ------------------------------
From: [email removed]
Subject: What's in the works...
Dan came up with the idea of distributing a questionnaire as an easy
to get programming experience, ideas for implementation and functions,
etc. I'll get this out in a couple of days.
Also, I'll get the first digest out by Friday. Right now, I'm under
a big crunch to get an X application going by the end of the month.
[No, this doesn't mean that I'll be the 'leader' - I'll help, but
I don't have a lot of time.]
- --Bill
- ------------------------------
End of Traveller System Generation Group Digest
******************************
All opinions and material above is the responsibility of the originator.
Submissions: [email removed], or [email removed]
Administrator: [email removed] (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.