CT and 3D ATUs

[sgbrown]

Originally posted by Malenfant:
</font><blockquote>quote:</font><hr />I checked your page briefly - interesting system. There seems to be a lot there - is there stuff on the non-mapping rules there?

What do you mean by "non-mapping rules"?

I basically figured out the locations of the stars on the RECONS list relative to Sol, and plotted where there'd be on a layered stack of subsector maps spaced apart by one parsec vertically. [/QB]</font>[/QUOTE]Well - what I'm after is IF I get mapping licked, (which with the right software isn't that hard - you just don't use hexes - you let the software tell you the difference) are there any rules that wouldn't work right in a 3D mapped universe?

EDIT: For instance - I know the starship economics don't work well because the number of available systems jumps WAY up at higher jump numbers or there aren't enough available at lower jump numbers depending on your star density. I see this as a setting issue as well - but I'm wondering about hidden ties that I haven't thought of. What else is hiding in the rules that could bite me in my fourth point of contact if I don't consider them up front?

 

[sgbrown]

Originally posted by Malenfant:
</font><blockquote>quote:</font><hr />I checked your page briefly - interesting system. There seems to be a lot there - is there stuff on the non-mapping rules there?

What do you mean by "non-mapping rules"?

I basically figured out the locations of the stars on the RECONS list relative to Sol, and plotted where there'd be on a layered stack of subsector maps spaced apart by one parsec vertically. [/QB]</font>[/QUOTE]Well - what I'm after is IF I get mapping licked, (which with the right software isn't that hard - you just don't use hexes - you let the software tell you the difference) are there any rules that wouldn't work right in a 3D mapped universe?

EDIT: For instance - I know the starship economics don't work well because the number of available systems jumps WAY up at higher jump numbers or there aren't enough available at lower jump numbers depending on your star density. I see this as a setting issue as well - but I'm wondering about hidden ties that I haven't thought of. What else is hiding in the rules that could bite me in my fourth point of contact if I don't consider them up front?

 

[Scott Martin]

Starship economics isn't really a big deal for a 3-D universe, since ships with J-Drives larger than Jump-1 tend to be "uneconomical" to operate. It doesn't matter how many systems you can reach if you can't pay for the ship

There are implications for the military though, since the "border" gets a lot closer. Ass an example if you have a system every "hex in 3-D then a J-1 empire has an "interior" with 7systems using 2-D and 13 systems in 3-D (using hexagonal close packed arrays) For each increase in jump, a 3-D empire will need more systems to have a "border" than a corresponding 2-D empire, which is offset by higher overall strategic mobility, but in effect Large 3D empires will have much closer "borders" than 2-D empires.

AstroSynthesis gives some *really* large variability for stellar density, and even the most "sparse" maps that I have generated (with the exceptions of the ones with less than 10 stars in a million light year cube) are massively higher than in the region of Sol.

I'm working on some PERL scripts to automagically generate stars in a 3-D volume. The current (simple and complete) one takes # of systems wanted, maximum values for L, W and H and generates X,Y and Z values for system positions. The next three I need to write (the hard ones) are:</font>

• one to determine the nearest stars within a given threshold for each star (this is computationally intensive, and I'm grinding my way through various sort algorithms to minimize the search space)</font>

</font>

• a second one to list "mains" or chains of systems that are "clustered" within certain distances of each other (within 3-5 ly or so)</font>

</font>

• a final one to do automatic system generation (GURPS Space may be the winner here: Astrosynthesis does some pretty bizarre things as far as "habatibility" ratings go: take a look at the mean temperature of the most habitable stars, and wonder why they can't have liquid water on their surface...)</font>

Anyway, once you have derived the distances from systems you can look at the statistics for "your" universe and determine what a good threshold for Jump-1 is (is it 1 parsec / ~3 ly? or 5 LY? or 2 lY?) I plan to do this with the second (as yet unbuilt) program and just use it until I have a dozen or so "mains" of more than 30 worlds in my 1,000x1,000x1,000 LY cube, and define that as the basic jump distance.

Of course, I don't allow jumps into deep space (woll, I do sort of: ~1% of those "systems" will not have a primary but you can't jump into just *any* empty space)

More details when I have more bugs worked out, but if you want the raw generator let me know, it's less than a dozen lines of PERL

Scott Martin

 

[Scott Martin]

Starship economics isn't really a big deal for a 3-D universe, since ships with J-Drives larger than Jump-1 tend to be "uneconomical" to operate. It doesn't matter how many systems you can reach if you can't pay for the ship

There are implications for the military though, since the "border" gets a lot closer. Ass an example if you have a system every "hex in 3-D then a J-1 empire has an "interior" with 7systems using 2-D and 13 systems in 3-D (using hexagonal close packed arrays) For each increase in jump, a 3-D empire will need more systems to have a "border" than a corresponding 2-D empire, which is offset by higher overall strategic mobility, but in effect Large 3D empires will have much closer "borders" than 2-D empires.

AstroSynthesis gives some *really* large variability for stellar density, and even the most "sparse" maps that I have generated (with the exceptions of the ones with less than 10 stars in a million light year cube) are massively higher than in the region of Sol.

I'm working on some PERL scripts to automagically generate stars in a 3-D volume. The current (simple and complete) one takes # of systems wanted, maximum values for L, W and H and generates X,Y and Z values for system positions. The next three I need to write (the hard ones) are:</font>

• one to determine the nearest stars within a given threshold for each star (this is computationally intensive, and I'm grinding my way through various sort algorithms to minimize the search space)</font>

</font>

• a second one to list "mains" or chains of systems that are "clustered" within certain distances of each other (within 3-5 ly or so)</font>

</font>

• a final one to do automatic system generation (GURPS Space may be the winner here: Astrosynthesis does some pretty bizarre things as far as "habatibility" ratings go: take a look at the mean temperature of the most habitable stars, and wonder why they can't have liquid water on their surface...)</font>

Anyway, once you have derived the distances from systems you can look at the statistics for "your" universe and determine what a good threshold for Jump-1 is (is it 1 parsec / ~3 ly? or 5 LY? or 2 lY?) I plan to do this with the second (as yet unbuilt) program and just use it until I have a dozen or so "mains" of more than 30 worlds in my 1,000x1,000x1,000 LY cube, and define that as the basic jump distance.

Of course, I don't allow jumps into deep space (woll, I do sort of: ~1% of those "systems" will not have a primary but you can't jump into just *any* empty space)

More details when I have more bugs worked out, but if you want the raw generator let me know, it's less than a dozen lines of PERL

Scott Martin

 

[kaladorn]

Of course, if you want to use the area around Terra, there are a number of data archives cribbed from Hipparcos(sp?) and other catalogs (I'm doing this from memory, so don't beat me if I've got muddled) available with X, Y, Z coordinates. Nyrath the Indispensable (stellar cartographer and writer of Ogre - aka Winchell Chung) has a few files up somewhere around the Interweb, one of which was the list of all stars within say 50 ly of Terra (or was it 100? I forget) and then another with all of the ones not likely to contain anything even vaguely interesting for habitability.

Having some database like this, you could use appropriate analysis tools on real star data to find out both how far apart systems tend to average and how far apart useful systems tend to average and maybe draw some conclusions about an appropos jump distance.

But that's just one sort of 'real star layout' based approach. The one thing such a DB does is give you some good ideas of real star density.

One interesting point I also learned, though I'm not sure if it is true or urban myth, is that GDW, when producing the lovely 2300 AD 3D star chart, used some real data. But for reasons of their own, probably associated with catching people lifting their work, they introduced some errors (I think a few systems that don't exist or were moved). This is close enough to accurate to be a good source, but different enough to be unique if someone just lifted the data - a good plan I think from a game design perspective. But such a set of maps and charts with X, Y, Z's might be useful to the aspiring 3D traveller GM.

Heck, file off the names, keep the locations the same, and you've already got a 50 ly sphere around "not Earth" laid out, complete with stellar data. That's pretty handy. Center on a non-Earth location and suddenly it is really hard to recognize it as real Earth-base data.

Lots of ways to skin the 3D cat.

 

[kaladorn]

Of course, if you want to use the area around Terra, there are a number of data archives cribbed from Hipparcos(sp?) and other catalogs (I'm doing this from memory, so don't beat me if I've got muddled) available with X, Y, Z coordinates. Nyrath the Indispensable (stellar cartographer and writer of Ogre - aka Winchell Chung) has a few files up somewhere around the Interweb, one of which was the list of all stars within say 50 ly of Terra (or was it 100? I forget) and then another with all of the ones not likely to contain anything even vaguely interesting for habitability.

Having some database like this, you could use appropriate analysis tools on real star data to find out both how far apart systems tend to average and how far apart useful systems tend to average and maybe draw some conclusions about an appropos jump distance.

But that's just one sort of 'real star layout' based approach. The one thing such a DB does is give you some good ideas of real star density.

One interesting point I also learned, though I'm not sure if it is true or urban myth, is that GDW, when producing the lovely 2300 AD 3D star chart, used some real data. But for reasons of their own, probably associated with catching people lifting their work, they introduced some errors (I think a few systems that don't exist or were moved). This is close enough to accurate to be a good source, but different enough to be unique if someone just lifted the data - a good plan I think from a game design perspective. But such a set of maps and charts with X, Y, Z's might be useful to the aspiring 3D traveller GM.

Heck, file off the names, keep the locations the same, and you've already got a 50 ly sphere around "not Earth" laid out, complete with stellar data. That's pretty handy. Center on a non-Earth location and suddenly it is really hard to recognize it as real Earth-base data.

Lots of ways to skin the 3D cat.

 

[Fritz_Brown]

SGB, the issue with jump-masking is making jumps harder. If you can't go anywhere near 100D without dropping out of jump, then bypassing intervening stars is tougher. (You might have to go a bit out of your way to go around things - both other star systems and planets within the source or destination systems.) If you introduce a third dimension, calculating what's in the way becomes a bit harder.

There are plenty of folks who don't agree with jump-masking (calling Bill Cameron!), and don't use it. It is not part of CT, but was made explicit in GT (which has its own problems, of course).

On the economics, the only real change will be the complication of your routes. You might have more options in some cases, but you might lose some trade connections, as well.

 

[Fritz_Brown]

SGB, the issue with jump-masking is making jumps harder. If you can't go anywhere near 100D without dropping out of jump, then bypassing intervening stars is tougher. (You might have to go a bit out of your way to go around things - both other star systems and planets within the source or destination systems.) If you introduce a third dimension, calculating what's in the way becomes a bit harder.

There are plenty of folks who don't agree with jump-masking (calling Bill Cameron!), and don't use it. It is not part of CT, but was made explicit in GT (which has its own problems, of course).

On the economics, the only real change will be the complication of your routes. You might have more options in some cases, but you might lose some trade connections, as well.

 

[sgbrown]

Originally posted by Scott Martin:

-clip-
AstroSynthesis gives some *really* large variability for stellar density, and even the most "sparse" maps that I have generated (with the exceptions of the ones with less than 10 stars in a million light year cube) are massively higher than in the region of Sol.

-clip-

More details when I have more bugs worked out, but if you want the raw generator let me know, it's less than a dozen lines of PERL

Scott Martin

Astrosynthesis is what I'm looking at using - and I concur that density is an issue. But the program allows you to import files and a couple of files with actual known star locations are available.

Always interested in learning and exploring - but I'm ignorant of PERL - will it run in script form or will I need special software/skills to run it? If I can get it to work fairly simply I'm interested.

 

[sgbrown]

Originally posted by Scott Martin:

-clip-
AstroSynthesis gives some *really* large variability for stellar density, and even the most "sparse" maps that I have generated (with the exceptions of the ones with less than 10 stars in a million light year cube) are massively higher than in the region of Sol.

-clip-

More details when I have more bugs worked out, but if you want the raw generator let me know, it's less than a dozen lines of PERL

Scott Martin

Astrosynthesis is what I'm looking at using - and I concur that density is an issue. But the program allows you to import files and a couple of files with actual known star locations are available.

Always interested in learning and exploring - but I'm ignorant of PERL - will it run in script form or will I need special software/skills to run it? If I can get it to work fairly simply I'm interested.

 

[kaladorn]

To do a 3D jump mask, you'd have to know the position of the start point, end point, and points you care to check for intersection. Then I think you'd have to figure the mask sphere size for each of those possible interfering points and then you'd have to calculate if a line from start point to end point intersected the surface of any of the mask spheres (check one at a time).

This is probably a pretty standard computer/geometry type problem by now, but would undoubtedly be best done using Mr. Computer and a bit of programming. Doing it by hand would be... painful. And on the fly would be interesting.... (argh!) (like Math Test interesting...)

 

[kaladorn]

To do a 3D jump mask, you'd have to know the position of the start point, end point, and points you care to check for intersection. Then I think you'd have to figure the mask sphere size for each of those possible interfering points and then you'd have to calculate if a line from start point to end point intersected the surface of any of the mask spheres (check one at a time).

This is probably a pretty standard computer/geometry type problem by now, but would undoubtedly be best done using Mr. Computer and a bit of programming. Doing it by hand would be... painful. And on the fly would be interesting.... (argh!) (like Math Test interesting...)

 

[Malenfant]

I think jump masking is a bit overblown to be honest - the chance that a straight line drawn from an exit point in one system to an entry point in another system will cross a 100D limit of any body in between is going to be miniscule - especially in 3D where objects can basically be anywhere within a 1 cubic parsec volume, and with orbits at any orientation or inclination relative to other systems.

Within a given system, it's going to be a real problem if you have to get from one side of the system to another, because then you are probably more likely to intersect the primary's 100D limit.

 

[Malenfant]

I think jump masking is a bit overblown to be honest - the chance that a straight line drawn from an exit point in one system to an entry point in another system will cross a 100D limit of any body in between is going to be miniscule - especially in 3D where objects can basically be anywhere within a 1 cubic parsec volume, and with orbits at any orientation or inclination relative to other systems.

Within a given system, it's going to be a real problem if you have to get from one side of the system to another, because then you are probably more likely to intersect the primary's 100D limit.

 

[Fritz_Brown]

You're right, Mal, but some folks seem to really not like it. It's easier on gameplay to just go by CT: nothing can affect a starship in jump. Then there are NO geometry problems to work.

 

[Fritz_Brown]

You're right, Mal, but some folks seem to really not like it. It's easier on gameplay to just go by CT: nothing can affect a starship in jump. Then there are NO geometry problems to work.

 

[Scott Martin]

Originally posted by SGB - Steve B:

Astrosynthesis is what I'm looking at using - and I concur that density is an issue. But the program allows you to import files and a couple of files with actual known star locations are available.

Always interested in learning and exploring - but I'm ignorant of PERL - will it run in script form or will I need special software/skills to run it? If I can get it to work fairly simply I'm interested.

You can get a (Free if you're not a commercial user) PERL Interpreter At ActiveState Here which is most of what you need to run PERL scripts.

Yes, it's a scripting language, so it's pretty dead easy (no funky UI's or anything, feed in parameters, get out what you want...)

As for the 2300 AD map, the stars that were "moved" were to allow the "Arms" to work and be within (IIRC) 7.7 LY, which was the "range limit" of stutterwarp.

Scott Martin

 

[Scott Martin]

Originally posted by SGB - Steve B:

Astrosynthesis is what I'm looking at using - and I concur that density is an issue. But the program allows you to import files and a couple of files with actual known star locations are available.

Always interested in learning and exploring - but I'm ignorant of PERL - will it run in script form or will I need special software/skills to run it? If I can get it to work fairly simply I'm interested.

You can get a (Free if you're not a commercial user) PERL Interpreter At ActiveState Here which is most of what you need to run PERL scripts.

Yes, it's a scripting language, so it's pretty dead easy (no funky UI's or anything, feed in parameters, get out what you want...)

As for the 2300 AD map, the stars that were "moved" were to allow the "Arms" to work and be within (IIRC) 7.7 LY, which was the "range limit" of stutterwarp.

Scott Martin

 

[kaladorn]

Originally posted by Scott Martin:
As for the 2300 AD map, the stars that were "moved" were to allow the "Arms" to work and be within (IIRC) 7.7 LY, which was the "range limit" of stutterwarp.

That seems fairly likely. Yet at the same time, that doesn't necessarily explain a few non-existent entities. :0)

Still, I really enjoyed that one aspect of 2300 AD more than almost anything else. A game that used a 3D map and distance formulae! And of course, the whole 'Colonial Period' feel to the game was neat too.

 

[kaladorn]

Originally posted by Scott Martin:
As for the 2300 AD map, the stars that were "moved" were to allow the "Arms" to work and be within (IIRC) 7.7 LY, which was the "range limit" of stutterwarp.

That seems fairly likely. Yet at the same time, that doesn't necessarily explain a few non-existent entities. :0)

Still, I really enjoyed that one aspect of 2300 AD more than almost anything else. A game that used a 3D map and distance formulae! And of course, the whole 'Colonial Period' feel to the game was neat too.