***************************************************************************
** 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. **
***************************************************************************
Subjects in today's digest:
Summary of ideas for Database approach to star/system etc gen.
- --------
From: [email removed] (Fred Schiff)
Subject: Summary of ideas for Database approach to star/system etc gen.
All these ideas are Fred Schiff's with some help from James Perkins.
The following is a summary of ideas we hashed together in some discussions
about computer generation and storage/reclamation of star system information
in the MegaTraveler universe.
Basic idea:
ability to create and output (in serveral ways) any multiple
layers of detail inherent in the MT system (galaxy/quadrant/sector/
subsector/system/star/orbit/planet-belt/moon/planet-map/
region-map/local-map) in a portable form on a computer.
Points:
You should be able to comment any sort of object (Sector, Subsector,
System, Star, Planet, Moon, Etc.)
All these things should be optional, in fact I think you should be able
to fill stuff out from the top down. Oh, you want to look at THIS
subsector? Quick... generate all the systems in it, stow it away. And
you want to look at THIS system's extended generation stuff? Quick,
generate the expanded system data, stow it away. Oh, a world map, QUICK,
generate a world map at the grainy level. This region? Quick, generate a
regional map... etc.
Free form data base: a general rule is that you shouldn't make things with
fixed fields. This is important since, for example, the trade codes will
probably be kind of long; besides the trade codes there are about a dozen
odd things that can be put in there.
One thing we want to be careful to avoid is duplicating information.
Each separate item should have its own "Key" data item. For example,
we have the hex id for systems.
We should have a passwd-style database, with the fields seperated by a field
seperator (in unix passwd file, ":"). Its stupid to have to line
everything up on the columns.
Like this:
Name.{filetype}
.sector - UWP's, sector, subsector, and system names
.routes - trade, xboat, other routes
.expand - expanded system data for systems
.text - commentary on sector, subsector, systems, worlds
.map - world map information for individual worlds
.key - (optional) explanation & code for each new base code,
classification data and alegiance code used in .sector file;
used to make explanation key box in outputs
The Name.sector file is organized as follows:
#Sector: Spinward Marches
#Subsector_A: Chronor
Zeycude 0101 C330698-9 A Na Ni Po De 613Zh M9 V
Reno 0102...
Errere 0103...
Cantrel 0104...
Gyomar 0108...
...
#Subsector_B: Jewell
#Subsector_C: Regina
...
#Subsector_P: Trin's Veil
...
Note: lines are not shown with ':' field separators for clarity.
I originally thought that star generation should not be part of basic
system (ie. mainworld) generation, since that info is not really needed
at that point, but have since changed my mind. The stars should be
place in the .sector file but do not need to be output along with the
rest of the mainworld data. Generating the stars at the mainworld
creation time allows you to place Ia, Ib and O stars and other such
objects which must be placed explicitly by the Ref.
The "#" lines are comments, unless everything up to the first leading
whitespace matches a "magic pattern", like "#Sector:" or
"#Subsector_B:".
The Name.routes file is organized as follows:
#Route: Xboat
# Zhodani Xboat Routes
0103 0304 0303
0412 0614 0712 0610 0608 0307 0304 0705 0904 1103 1402
# Darrian Confederation Xboat Routes
0421 0223 0325 0426 0527 0727
0325 0624 0724
...
#Route: Megacorporation
# Oberlindes Lines (Starts at Regina)
1910 1912 1815 ...
...
#Route: Free Trader Routes
# Tureded and vicinity
2414 2514
Here the magic pattern is "#Route:".
Note that rather than having pairs of connected systems, we have a "run"
of connected systems, which avoids a lot of repetition when there is no
branching. There is nothing to stop you from listing everything as
pairs, though, and this is probably what automatic software generation
will do.
The Name.text file would be something like this:
#Sector
The Spinward Marches...
...
#Subsector_A
The Chronor Subsector is the home of the Zhodani, who...
...
#System_0101
The Zeycude system is organized as follows...
...
and here are some world maps...
...
If there is browsing software, it will use the magic code fields to
correlate data with the Name.sector file and the name.route file.
This:
Zeycude 0101 C330698-9 A Na Ni Po De 613Zh M9 V
is only one possible output format (Spinward Marches list type)
I prefer Traveler's Digest form:
Zeycude 0101 C330698-9 A Na Ni Po De 613 Zh
with travel zone at end, no stars listed and allegiance separated
from data values by a blank.
We also need to talk about clever programs which operate on the data.
I can think of lots of programs to emit postscript:
sector2ps - Sector map of systems, ala the Spinward Marches map
sub2ps - SubSector map of systems, ala Digest Group map
routes2ps - Sector map transparency overlay for each kind of trade route
extend2ps - Program to format extended information pages
You'd use the above to create pages for a 3-ring binder, for example.
Browsing programs (ascii output):
showsub - show a subsector map
showsys - show UWP of system and expansion data
showsysroutes - show map of vicinity around a system with routes
As well as programs which do generation:
gensec - generates sectors
namesec - replaces "Unnamed" on everything with random names
expandsys - generates expanded data for a system, adds into name.expand
genroutes - generate automatic routes
annosys, annosub, annosec - add anotation text to the .text file
And of course we need some sort of menu program to tie everything together.
Maybe one big master program that gives you different windows onto the
data, allows selections and operations via a graphics interface on a Mac
or Sun. Preferably something simple to begin with of course.
Its needed to keep real, useful, and complete information in each file.
Thus, everything necessary for basic generation is in .sector, including
all standard sector mapping info. All route information is additional
information, and resides in .routes. Similarly, textual discussion,
and whatnot are listed in .text and expansion data, in .expand.
- --------
End of STAR SYSTEM DIGEST