Little over a year ago, I mentioned some work I was re-attempting with
Excel with no formal training/experience. Offers of help were given,
none were followed up by me. So, I'll put forth some of what I was doing, and
anyone who wants to give it a shot, or point out where it's already been done,
fire away!
My original plan was to use real star lists to generate a space campaign.
Taking WInchell Chung's HabHYG file,
http://www.projectrho.com/smap06.html
I dropped the list into Excel and began to massage. Before going on, let me
explain that I'm very comfortable with even near accurate X, Y, Z
coordinates over RA/D/P, and while he gave instructions on how to
convert, he'd done the work for me. "...serious researchers should go back to
the primary sources." I've been called a lot of things, never 'serious'.
Also, I figure I can give one player XYZ, another XZY, another -YZX,
etc, and unless someone is TRYING to cheat, folks won't know each other's
whereabouts until fairly far along.
So, I sort-largest-first by the habitability index, and select to about
18 parsecs, roughly the size of Niven's known universe, and I get about 300
stars. I then set up three cells that convert a particular star's XYZ to
0,0,0, and the propagate over the whole table to get all the other stars'
relative position. And then I quit.
What seems appropriate is a) figuring a way to get that info with each star
without having to manually repeat the process 300 times, b) give each star a
home coordinate pattern and a way to convert any location to the given star's
offsets, and c) come up with some guidance on choosing stars as empire
starters: not too close, too far, roughly equal number of nearby stars to
start empires.
Part of me says I should really be investigating whatever-M
$-is-flogging-as-VBA and doing a database, and at some point, I'm sure I
should, but I'd hope I could get started with just a spreadsheet.
The_Beast
> On Mon, Mar 21, 2011 at 02:16:52PM -0500, Doug Evans wrote:
> What seems appropriate is a) figuring a way to get that info with each
I think you'd do much better to use a programming language than to mess about
with Excel. This sort of thing is dead easy in Perl, for example.
Coordinate transformations are relatively easy. I'll see what I can knock
together.
What exactly is "that info" for (a)? (b) is pretty easy. (c) is quite a lot
harder.
R
> Doug Evans <devans@nebraska.edu> wrote:
Use a database. MySQL for example is free. As Roger said, doing this sort of
thing in a programming language is easy (though you need to know a programming
language).
Does it have to be real star lists? If you have four players, divide the
'universe' into 9 cubes, and randomly generate 'N' stars in each cube. That
gives you 9 volumes each with an equal number of stars. Place each player on a
random star in one of the edge cubes (so there's 5 initially unpopulated
cubes). This should be random but reasonably fair. You could bias starting
location to the centre of each cube if you want.
e.g.:
-+-
+-+
-+-
Each + is a starting cube, each - an unpopulated cube. Add
further cubes for extra players or extra obfuscation as to a player's place in
the universe (3x3x3 cubes gives 8 corners or 6 faces).
Roger Burton West wrote on 03/21/2011 05:31:29 PM:
> On Mon, Mar 21, 2011 at 02:16:52PM -0500, Doug Evans wrote:
Having 'grown up' on Basic, Fortran, Pascal, and even a bit of Rexx, Cobol and
VB, for reasons I'm too ashamed to analyze, I find myself unable to pick up
anything easily currently available.
> Coordinate transformations are relatively easy. I'll see what I can
Thanks, as long as you don't add 'easily run on your (MAC, LINUX, whatever)
box.' I hate M$, but am Winders dependent. ;->=
> What exactly is "that info" for (a)? (b) is pretty easy. (c) is quite
Sorry, "that info" as in creating a list of stars' relative coordinates. I
suspect my description was so convoluted as to be almost
self-referential.
As for c), didn't mean it should make choices, just give me a way of looking
at the mass of stars that I can make the choices myself. Now, THAT was
convoluted!
FYI, at one point, I'd a set of lists in the volume of about 10(?) or so
parsecs, and could chose stars that were close to equidistant from the Earth,
and none closer to each other. Seemed fairly good, as each list gave a small
group of closest stars.
Samuel Penn wrote on 03/21/2011 06:30:10 PM:
> Use a database. MySQL for example is free. As Roger said, doing
Doesn't HAVE to be, but the thought of actual stars leaves one with the
enjoyment of allowing someone to discover the Earth.
> e.g.:
Understood, but don't want it too regular; an apparent random fill isn't
something beyond my conception, just beyond my hurdle of learning a current
language.
For a DB, I've Access 2007, can play relatively painlessly though not
VB/Macro facile. I miss Paradox. As to the thought of trying to write
SQL... *shudder*
Sorry for being the blind to be led, but you knew the job was dangerous...
_______________________________________________
Gzg-l mailing list
Gzg-l@mail.csua.berkeley.edu
http://mail.csua.berkeley.edu:8080/mailman/listinfo/gzg-lAs Roger says,
doing 3 space translations of coordinates isn't that hard.
Myself, I'd pick a centre point (probably whatever my dataset was using) and
call coordinates with respect to that point Universal Coordinates. Then I'd
have Player X Coordinates by UC shifted via a particular transform matrix.
Player Y would have a different transform matrix, etc.
So the GM would secretly know the transform matrix for each player. The
players would not (at least until they had enough data and means to collude to
figure out relative positioning, which inevitably occurs).
To allocate players evenly in 3 space is a challenge if the dataset had no
particular enforcement of standardized density (such as using real starmaps).
If you can enforce standardized density for fairness in regions, by generating
your map region by region and incorporating generation rules that enforce fair
distribution (note that this term is subject to some specific definition),
then you can use those regions to allocate starting player positions.
But even then, you need to consider if you want players on map edges, if you
have enough players and can't allocate them all at an edge, who gets stuck in
the middle? Do you want a square universe? A round one? A spiral? Etc?
Universe shape will determine how you should allocate regions. In a square
(cube in 3 space), probably sub-cubes. In a circle (flat cylinder), you
can
do pie-slice regions. In a full sphere, you are looking at 5 sided
chunks with 4 sides that are along radii from the center and the 5th being on
the surface of the sphere (a 3D pie slice, if you will).
Automated allocation is a bit complicated, but manual allocation can be as
well.
You can form some easier to allocate (and print) maps by having a 2.5D
universe (all planets are laid out on an XY grid but then have a Z coordinate
up or down from the grid... it gives you 3D, but you prohibit multiple planets
at the same XY with different Z axis values... this means you can still map it
in 3D and use some 2D concept to layout the regions). If you constrain values
of Z, this can work out fairly well and is 'faux 3D' in my view.
> On Mon, Mar 21, 2011 at 10:31:29PM +0000, Roger Burton West wrote:
> Coordinate transformations are relatively easy. I'll see what I can
OK, here's a coordinate transformer.
http://firedrake.org/roger/ft/coordtransform.ods
http://firedrake.org/roger/ft/coordtransform.xls
I wrote it in OpenOffice; I don't do Windows, so I have no idea how well it'll
work under Excel.
Put into the first column of cells the XYZ coordinates of your base system,
and the rotation angles you want to use (these are Euler angles,
http://en.wikipedia.org/wiki/Euler_angles - if you don't care, just put
a value from -180 to +180 into each cell).
The rows at the bottom show star system names and coordinates -
paste in pre-transformation on the left, get post-transformation on the
right. (Ignore the "1" column in each case.) Duplicate the last row to get
more stars.
You'll probably want to reformat the numbers! This isn't meant to be pretty,
just to get the job done reasonably quickly.
Is this roughly the sort of thing you were after?
It will be a bit later in the day before I can get to Excel to check, but
sounds good, and I've OpenOffice at the shoppe even later, so no problem
there!.
I know how difficult it can be to write with vague specs. ;->=
Thanks!
The_Beast
Roger Burton West wrote on 03/31/2011 06:50:26 AM:
> On Mon, Mar 21, 2011 at 10:31:29PM +0000, Roger Burton West wrote: