Re: [nbos] Astro3 Experimental Build
"Mike Oliver"
Tue Nov 24th, 2009
The Worldbuilder supplement to which I referred was a booklet by Digest
Group Publications and was designed as an adjunct to the MegaTraveller
role-playing system but the points made by Cam are no less relevant and
valid for that. The points he makes are in line with what I was saying.

Cheers,

Mike
www.warmodelling.co.uk <http://www.warmodelling.co.uk/>
www.cartography-services.co.uk <http://www.cartography-services.co.uk/>

-----Original Message-----
From: nbossoftware-bounces-at-nbos.com
[mailto:nbossoftware-bounces-at-nbos.com] On Behalf Of Cam Kirmser
Sent: 24 November 2009 17:12
To: nbossoftware-at-nbos.com
Subject: Re: [nbos] Astro3 Experimental Build


I believe the way Heaven & Earth - a Worldbuilder based program, as I
recall - does it seems to be satisfactory. At least, from a gaming point
of view.

Games are full of times where the reality of the science has to take a
back seat to the fun of the gaming. For instance - and, realizing this
is a movie, not a game, but the imagery illustrates the point well - in
Star Wars I, The Phantom Menace, Qui-gon shoves his light saber into the
blast doors separating him from the bridge of the Trade Federation ship.
A very dramatic moment as the power of the light saber is displayed,
melting the metal of the door, turning it to red-hot slag, as his hand
twists it to open a way through.

There's his hand, holding the light saber deep into the molten metal,
cutting a hole in the thick doors.

Right next to the red-hot metal is his hand holding the light saber.

Ever put your hand in an oven while the element is glowing? And, that's
nowhere near the apparent temperature - going by the color - of that
molten metal.

Had that been reality, Qui-gon's hand - at the very least - should have
been char-broiled.

So, to suit the drama of the scene, the reality of convection heating
had to be suppressed. And, no one complained. It is accepted as part of
the suspension of disbelief.

And, again using Star Wars, every space battle uses World War II
dogfights as a foundation. So, every ship in space behaves as if it is
flying through an atmosphere. But, the mind expects this, so it ignores
that they are not behaving realistically, given the environment. For
example, when Obi-wan and Anakin are flying through that space battle in
the beginning of Attack of the Clones, those little bots are eating away
at their fighters. R2D2 zaps one of them and it slowly slides off the
wing of Anakin's fighter.

That's what should happen, right?

Not at all. There's no evidence of any acceleration of that fighter, so
it should have stayed right where it was until some sort of course
correction. But, instead, the dead bot behaved as it would have in an
aircraft's slipstream. And, everyone accepted it, because that was
believable, within our realm of experience.

So, the same, I believe, is true of the placement of binary or trinary -
let alone systems with five stellar components - elements. Sacrifice
just enough reality to make it acceptable to the players. After all,
they already accept FGMP-15s - even though, if reality were maintained,
the discharge from one would incinerate everything for hundreds of yards
around, or more. What's one more little detail? Just keep the stellar
system within our realm of experience; which is, have a central body -
the main star - and any other stars in orbit around that primary with
believable dead orbits that would be in close proximity to the lesser
stars.


----- Original Message -----
From: Sam Orton <mailto:pictngrin-at-yahoo.com>
To: nbossoftware-at-nbos.com
Sent: Tuesday, November 24, 2009 10:33 AM
Subject: Re: [nbos] Astro3 Experimental Build





>Yep, that sums it up. Basically there's no way that I know of to
calculate stable orbits of >stars and their planets in multiple star
systems, particularly when there's 3 or more stars. >What I'll probably
end up doing is assigning the component stars a fixed position in a
>multiple-system display. They just wont orbit each other.




>The way the "Worldbuilder" Traveller supplement worked was to place the
subsidiary suns >in orbits around the primary (orbit numbers generated
randomly). It then made certain >orbits, close to these, unavailable for
planets. Then, each remaining orbit was given the >chance of having a
planet using it.

>No attempt is made to generate stable orbits or have the planetary
bodies generated >behave according to astrophysical laws.




There might be a middle ground, if you like. Build a database of known
stable *types* of orbits for multiples, including the *relative* masses
and distances of the stars in it. That allows you to include "common
center" orbits with no mass occupying them. Then if you generate a
multiple, generate ONE star for it and randomly select a multiple orbit
pattern. That tells you the mass and distance of the other star(s),
right? They are what they *must be* in order for the one star you have
to be in that place in *that* orbit.




"Close" multiples will be a separate, more complex problem, but with
"long" multiples the orbits should be far enough apart that "wanderer"
planets between stars should be a vanishingly small percentage, no?




Close multiples, where the gravity wells of the stars interact closely
enough to interfere with planetary orbits.... now that will be the
really hairy problem.




Sam




P.S. If all I'm doing is showing my ignorance of both astronomy and
programming, just kick me and I'll shut up again.








"Never attribute to malice that which can be adequately explained by
stupidity, but don't rule out malice." - "Heinlein's Razor"

"Any sufficiently advanced incompetence is indistinguishable from
malice." - Grey's Law






_____




_______________________________________________
Nbossoftware mailing list





_______________________________________________
Nbossoftware mailing list



Copyright © 2003-2007, NBOS Software. All rights reserved. 'Fractal Mapper', 'ScreenMonkey', 'Character Sketcher', 'Inspiration Pad', 'Fractal World Explorer', 'Goblin API', 'AstroSynthesis' are trademarks of NBOS Software. 'Dwarven Beserker' art by V. Shane.
Member contributed resources