Yet Another Traveller System Generator...

Okay, I'm announcing that I think that I'm at the point where I can
share the code with other people for my Traveller System
Generator[1]. There are already a lot of generators out there but
making my own has been a personal project ever since I started working
with SQL databases in the mid '90s. My code's in private github
repository right now. I'll grant access and send the link to serious
users who are already in github and who request access via a message
to my personal email address.

I don't think that I'm at the add contributor stage but I'm willing to
talk ideas in either private email or on the list.

---------------------------------------------------------------------------

# OVERVIEW

## The System

My generator is designed to build CT: Book 6 expanded systems. It
stores the resulting systems in an SQL database with a small schema so
that other people, who understand basic SQL, can extend it. Right now
there are two components, the database, and a python/sqlalchemy
program to generate and store 1 sector, mostly according to the rules
in CT: Book 6 / MT: The referree's manual. This program is under
development and it's by no means complete. Look at the roadmap section
to see where I am and what I plan to do next.

I choose to build another yatsg because I'm unaware of a Traveller
System Generator that stores its output in a SQL database. I've been
building these systems since I was a kid in high school and I've
always thought that Traveller was the kind of game that could use a
Computer Aided Referreeing or CAR system. [2] Furthermore, this
program seemed to be a good use for sqlalchemy, which I've wanted to
learn for a while. I feel that the major advantage of storing the
systems in SQL is that you can leverage good cutting edge open source,
yet free, technology like PHP, or Ruby on Rails, or my favorite,
Django to build your referee's aids. Then your ref is just using an
iPad to access your software via a webserver on his local network. I
envision that this will be distributed for normal users as a Virtual
Box VM which hosts the database and web server through which you'l
manipulate the system and access your sector (and other) data.

---------------------------------------------------------------------------

# DETAILS

I've left out the technology stuff so far. I'll go on to write that if
you aren't a "technology guy", then this project isn't ready for you
yet. You probably want to skim or even skip the rest of this.

## System Requirements

## Operating System

Linux: I code on FreeBSD 9.2 Stable and test on Ubuntu desktop 16.04

The system is coded in python and builds a SQL database on
postgresql. If the combination of VMs, Ruby on Rails, python, and
postgresql hasn't screamed it yet, it should be obvious by now that
this it targeted for a Linux/Unix/BSD stack. That's the stack I know. I'm not
trying to be exclusionary. I personally develop on a Mac with a
FreeBSD VM for a back end so if you can use macports or homebrew and
the terminal client of your choice on OS X you won't have any issues
jumping in now.

I also don't live off-the-grid. I know that many if not all of these
tools have been ported to work in the Windows environment. I just
don't work on Windows. If someone works on windows and wants help
getting this to work there, and it's reasonable, I'm open to the
idea. Email me.

## Database

Postgresql after 9.1

The database is implemented using foreign key constraints by
design. In my opinion, no open source database does that better than
postgresql so that's what I'm using. [3] That said, changing the
database to mysql or Oracle or any other rdbms for which there's an
sqlalchemy "driver" won't be hard. I also don't plan to use any
postgresql specific features. So, if someone wanted to build on MySQL,
they could probably do so right now by changing two lines of
python. Finally, I'm not adverse to making the database flavor:
postgresql, mysql, oracle, sqlite, or whatever configurable at
runtime. As far as sqlalchemy is concerned, it's just a string in the
db_url.

## Development language:

python: 2.7 or later, python 3.x is not tested.

I need to learn python3. At some point I will. Until then,
python27.

## Python libraries:

I tend to stick towards what I can install with the operating system's
package manager here. I do understand pip and virtual_env so if you
know enough to build a virtual_env directory for this project on a Mac
against the OS X's python, you'll be okay.

# ROADMAP

## Where we are now

The system right now is in a proof-of-concept stage. If the question
was: "Can I build a program using python and sqlalchemy to generate
and store systems in the database that I've designed?", then the
answer is "yes". At it current stage, it builds Solo star systems and
populates each orbit with a world that has no moons. It does not
properly implement the DMs for planet size, atmosphere, hydrographics,
and population by orbit number and it uses a pidgeon of the rules to
determine which world is the main world. The government of subsidiary
worlds is also done completely wrong.

Having said that, under OS X with a FreeBSD backend, it can build a
sector with an average of 6 ~ 7 rocky planets per system in less than
a minute. On Ubuntu 16.04 with an untuned postgresql 9.5 backend it
does the same thing in about the same time. My backends are virtual
machine guests hosted on Mac OS X under VMware Fusion. My FreeBSD
guest is hosted on a Quad Core i7 laptop. Ubuntu is hosted on a Quad
Core Xeon Mac Pro. The guest OSes have about 1GB of ram. The Ubuntu
Guest uses 6.6GB of space and is solely serves as a host of this
project.

## What's next?

I plan to implement the size... DMs by orbit next. After that I will
put in Gas Giants. Then I will put in moons, and multi star systems.

## Where do I want to be?

I want to get to the point where the system can generate any system
the CT: Book 6 / MT rules allow. Slavishly following that ruleset
would be nice but anyone who played CT knows that those rules left quite
a bit of latitude. In fact, the reason I'm calling it CT: Book 6 / MT:
Referee's manual is because systems are nearly identical but the MT
version has much of the Book 6 errata applied and then adds its own
errata.

At the end of the day, this is just generating and storing a setting
anyhow. Given that this system stores enough information to calculate
almost any parameter about any world in the database I don't see the
CT / MT ruleset as a limitation. Furthermore the system is designed to
be extended to keep notes for the referee etc.

---------------------------------------------------------------------------

[1] As I write this I can see the scene from Full Metal jacket where
Vincent D'Onofrio recites "The Rifleman's Creed"...

[2] I wrote my first sysgen in BASIC on a TRS-80 model I around
1981. This program just generated mainworlds. I used it to run my
"house universe" for about 15 year except for one summer when I used
the stock Traveller setting to run the Twilights Peak Adventure.  I
wrote my first CT Book 1 style Character Generator about 1982 in
Pascal at Lehigh University on a TOPS-20 system.

[3] I spent years using MySQL as my main SQL database only to be surprised
time and time again by MySQL's priority of speed over compatibility
and data integrity. The first time I was exposed to postgresql I knew
it was time to learn a new RDBMS.