Aurora 4x
VB6 Aurora => Newtonian Aurora => Topic started by: Steve Walmsley on September 05, 2011, 03:39:34 PM
-
I am starting to think about how the galactic map will be laid out. Bear in mind there will be no jump points so systems will have a fixed location on the map, although non-primary stars will orbit. The first question is whether I use real stars or random stars. In recent Aurora games I have always used real stars because it felt more realistic. For Newtonian Aurora, which is intended to be a little more realistic than standard Aurora, real stars seems an obvious choice. However, there is a problem.
The locations of real stars are in three dimensions, so they won't work out well on a 2D map. One option is a 3D galactic map, although I am not sure how useful that would be as 2D is usually a lot easier to handle. Even then, with a 3D galactic map and a 2D tactical map, translating from one to the other wouldn't be very easy. Which part of the system do you fly to before entering FTL if the destination system is above you? I don't even want to contemplate a 3D tactical map. BTW, I think FTL will involve something along the lines of Weber's honorverse where FTL speed depends on different bands of hyperspace, with higher tech FTL engines able to lift you into higher (and faster) hyperspace bands. Ships won't be able to enter FTL within the gravity well of a star or a planet. More on that in later posts.
Obviously with random stars then a 2D map is fine as systems would only have x,y coordinates and every game would be very different. However, then realism becomes an issue. Would it detract significantly from suspension of disbelief if Sol was surrounded by random stars. Or do I also generate a random home system too?
I suppose another factor that would be in favour of a random galaxy would be that players would have a degree of flexibility in how the galaxy was generated. High density, low density, spiral arm, ellipitcal, more useful stars such as type G or more realistic with a lot of red dwarfs
So I guess the question is: How important is having real stars in Newtonian Aurora?
Steve
-
Personally I don't think real stars are needed. Also if you are using fixed star locations then you end up with a bit more of a challenge on replayability. If I play ten games I'm going to pretty quickly have an idea ofwhich stars to head for first to get access to more distant stars etc.
I like the idea of being able to randomly generate a map and provide some parameters to that generation as you mentioned. Keeping it in 2D is also better than trying to battle with 2D v 3D from my perspective.
-
For me, since you introduced real stars I've never played anything else, for the same reason you mentioned it feels much more real and personally I'd like to keep them. Personally I don't think the shift between 3 axis strategic and 2 axis tactical would be too jarring (2300 basically had that and I've never found a game I love more, though Newtonian Aurora would probably hit that sweet spot for me) Something you may want to consider is a maximum distance allowed in hyperspace to allow it to be more of a terrain (like 2300 having the hard 7.7ly range due to radiation build up), it gives you chokepoints and means you can't simply bypass enemy defences
Matt
-
Two Cents...
How about two options...
1) Earth start using real stars and Milky Way
2) Random start using random stars random or selected type of galaxy
Adam.
-
For transiting from strategic to tactical use a little handwavium and say that ships only translate in on the plane of the system. If you want you could also say that they could only translate to hyperspace when on the same plane. This makes the 3D to 2D fairly easy.
As for the real stars vs random stars I would try both. One of the things I remember about 2300 was the star map was a piece of paper. If you use the xyz coordinates then have an arrow indicating how far from the stellar ecliptic plane the system is it should work. The representation does not need to be perfect if the computer has the exact coordinates in memory. It can calculate the time and distance at that point for you. For the random map you wouldn't even need to go that far as you could just use the xy coordinates and leave out z entirely.
Just my two cents worth.
Brian
-
As for simulating 3D on a 2D you could use different colors to represent whether the adjacent system is above or below the plane of the originating system.
-
Given limitations of the engine, I see no reason to object to a 2d represenation of 3d space. I find the 3d represenation of SoTS to be more trouble than its worth.
Unless of course you can license the engine that spore runs on, and build the game directly into the spore galaxy.
-
I prefer random stars, mainly cause I do not know what to expect. The realism for me is always in my imagination.
Replay ability is a big thing, fixed systems would make the game a little boring after first run through.
Also a 3D system is more trouble then it worth, look at 3D space games, the majority of the time you sort of run on a similar 2D plane anyway
-
I would use a 2D randomly generated map. The only thing i would keep is Sol and its planets, moons, asteroids etc... as for the realism I would keep the real stars names in, but have them generated randomly with closer ones being closer etc. I don't think many people know or care enough about the locations of all the named stars in our galaxy to be offended by mistakes. So the locations being wildly off shouldn't be a issue for fans. Just keep some basic consistency with the stars themselves if you must.
-
I would say that doing a 2D Representation with a shade difference (I. E. Darker is Deeper) would probably work best. You might encounter some difficulties with systems where the stars are immediately above/below each other, and I sadly don't have a suggestion that might fix that.
-
Might be easy to just flatten into 2D - here's a fine example:
http://www.classicamiga.com/images/stories/jreviews/games/F/manuals/Frontier_Elite2(map)(scan).jpg
I agree with voknaar above - a pseudo random system with real stars.
-
Yes, I agree with jRides: a good idea for real stars would be to use a projection onto the galactic plane.
Personally, though, I would probably play more with a random option to improve re-playability.
An option might be to start with a 2-D random map, and add a real stars map in a later version.
-
Might be easy to just flatten into 2D - here's a fine example:
http://www.classicamiga.com/images/stories/jreviews/games/F/manuals/Frontier_Elite2(map)(scan).jpg
I agree with voknaar above - a pseudo random system with real stars.
Frontier ELite..)
Awesome..Age ago:)
-
Would be cool to start on a random galaxy imo. Randomness makes the game more of an adventure - You don't know what awaits!
-
I'm going to join the Both! category.
I think there are ways to fake the 3d part of it adequately.
Doug
-
I think the flattened 3d map is the best/easiest and still realistic way to do a real star game.
Instead of starting in the Sol system in a real star game, you could give people to option to start in a planet in a random system (like someone a few posts back said). This would make it possible to still use real stars, without reducing the replay-ability. You might see a bunny-NPR race living on Earth if you manage to find the Sol system :).
-
"Naturally, these higher psuedo-dimensions, while similar to Einsteian or Cartesian space, have a few distinctions. Most obviously, while three dimensional volumetric objects can exist in them, real-space three-dimensional maps, when projected into "hyper-space" appear to be two-dimensional. The fact that they allow faster than light travel is merely a practical application of this fascinating theory. "
So yeah, you could simply rearrange a real space map onto a 2D area with some kind of algorithm based on the real distance to the star; a star that is above the orbital or galactic plane but close might end up being adjacent to a star that's below the galactic plane but just as close to Sol. . . but that's just the "mysteries of Hyperspace" for you.
Now, that all said, a random galaxy map would be interesting and allow for a lot of control over the generator. I'd say that on balance, I'd rather have the random galaxy with controls, but there's no reason why having a premade "real" galaxy map wouldn't work- or even having a galaxy construction set for other premade galaxies.
-
Star Control 3 to me had a very nice way of doing a 3D map, basically rotateable 3D points. This does however require the ability to display 3d points, often suggesting GL or DX rendering (though not required with some math. )
Alternatively I like Brian's 'lanes' idea, though it would basically be predefined connections between stars, since on the fly recalculations might create some gameplay confusion, such as two stars further away on xy being closer than another star.
But on a pure gameplay I would suggest jRides' suggestion of flattening and basically just throwing away the Z. Yes, you lose some 'realism', but not that much and it is MUCH easier to handle.
I don't like a 3D tactical map however since all the interesting stuff in a star system is in a single plane anyway. Adding a third dimension might allow spacecraft some extra tactical freedom, but it would all be in vacuum and not around stuff. Theres no reason to go up or down except to pursue ships who are up or down.
-
If you have to use 3D, then a flattened version. I'd vote for real stars and then random stars. Just my opinion.
-
Just randomly take out a third of the real stars and add a very small amount of randoms, and it'll not always be the same.
Though I much prefer a random start anyways, what do I care for real starts then?
Earth is boring, I already live on it.
-
2300AD or Megatraveller Star map are the best for RPG and strategical effort..more addictive for me.
My 2 cents
-
IMHO, a semi-random approach might prove useful. I do totally agree that if a player chooses a non-Solar start the generation of system must be random. However, for a Solar start it might be feasible to use the following method:
Select several stars (say, two or three dozens at most), that are either the closet to Sol or the most prominent upon the sky and place them at their appropriate places, projecting them on the galactic plane. Then divide the whole 360 circle in sectors roughly corresponding to constellations, again projected on the galactic plane. Then randomly place systems giving them names according to sector - just like the innumerable Glieses at present. Maybe the placing should not be random, but rather have a fixed distribution - set a direction for the Galactic core and star density growing in that direction, while the opposite happens in the other.
-
Here's a solution. Use the real positions of stars, and then flatten them onto a randomly aligned flat plane, with some maths to keep them from cluttering, and voila. Real stars, real-ish distances, and different each time.
-
Random map, random start please. I have no objection if you want to build a 'real galaxy' map for those that want to play on it, but I'm bored with the Sol System and would probably never use it as a starting location. I'd be SMing an empire on to a chosen body somewhere else on the map.
I'd be renaming virtually every system as soon as I explored it - I can't stand having to deal with Wolf 359 and Wolf 352 and Wolf 456 and Wolf 7 something something or remembering if I wanted Sigma Draconis Rubens or Sigma Draconis Luteus, or Tau Draconis Minimus, etc.
I see nothing wrong with a 2D map - it's what almost every game uses, and since the galaxies I'm familiar with are essentially 2D spirals, I find it an adequate approximation.
-
Flatten the 3d map to a 2d. Should not be too much of a problem. I'd prefer real stars over random stars, though it is true that for replayability, some randomness is good.
-
My vote is for both in 3D, though I know that's not exactly on the table. I'd prefer real stars, though, all in all.
-
Realistic 3D map, as closely to the link as possible.
hxxp: kisd. de/~krystian/starmap/
Combat could be 2d, even if full realism would ultimately mean 3 Dimensions.
-
And an equal amount of extra required processors and programming years.
-
If you wanted to keep the 3-dimensional distances you could still use a flattened 2d map or a Mercator projection. Just preserve the 'vertical' position of each system in the background and the math calculating travel times will work fine. Then the easiest way to intuitively display the relative vertical positions (that I can think of, others may have better ideas) in a 2d mode would be a simple color coding. Something like red shift for 'higher' systems and blue shift for 'lower', so traveling red to red or blue to blue with the same horizontal distance would take less time red to blue.
-
If you wanted to keep the 3-dimensional distances you could still use a flattened 2d map or a Mercator projection. Just preserve the 'vertical' position of each system in the background and the math calculating travel times will work fine. Then the easiest way to intuitively display the relative vertical positions (that I can think of, others may have better ideas) in a 2d mode would be a simple color coding. Something like red shift for 'higher' systems and blue shift for 'lower', so traveling red to red or blue to blue with the same horizontal distance would take less time red to blue.
It is an interesting idea and I have considered something similar. It wouldn't be too bad if local space was a relatively thin disk but it is spherical so it could get crowded and hard to read the map.
One other option I am considering is to flatten real stars to 2D by changing the x,y coordinates of real stars so that without the z coordinates they are still the same distance from Earth. The ratio of x to y would be the same. This would preserve the distances and general direction from Earth but could significantly change the distances from known stars to each other. As the vast majority of players would probably be familiar with the star names, a smaller proportion would be generally aware of their distances from Earth and a very small proportion would be aware of their distance from each other, this might achieve the illusion of a real stars map without affecting the suspension of disbelief for most players.
Steve
-
It is an interesting idea and I have considered something similar. It wouldn't be too bad if local space was a relatively thin disk but it is spherical so it could get crowded and hard to read the map.
One other option I am considering is to flatten real stars to 2D by changing the x,y coordinates of real stars so that without the z coordinates they are still the same distance from Earth. The ratio of x to y would be the same. This would preserve the distances and general direction from Earth but could significantly change the distances from known stars to each other. As the vast majority of players would probably be familiar with the star names, a smaller proportion would be generally aware of their distances from Earth and a very small proportion would be aware of their distance from each other, this might achieve the illusion of a real stars map without affecting the suspension of disbelief for most players.
Steve
Personally, I like either this idea a lot. I'm torn between this one and HaliRyan's.
-
That's a good idea too... but won't that trade a major thickening of the stellar density near the center of the map for one near the edges? Hmm.
Edit - Although now that I think about it, you could solve the problems with either option by taking whatever stellar DB you're going to use for your info and running an editor to remove any entries that don't fit into a cube/cylinder.
Edit #2 - Actually, I was wrong, your way won't result in a thickening of the stellar density, which is nice =D
-
The problem with a Mercator projection is that if we were to take a pic of a room, this would be it,
hxxp: www. flickr. com/photos/sbprzd/148862768/in/set-72057594138628700/lightbox/
We might have become used to it, when looking at a map of the world, like this, (edited because this pic shows what I meant precisely),
hxxp: www. mrkay. org/mrk/rants/2000-2001/mercator. html
However, it is wrong, in the sense that to portray a map we can use, the map is distorted as much as the pic of that room is.
That's why I propose a full 3d projection, that could move in the same time. We can get away with having a sphere (that's Earth) map translated into a Mercator projection, however, we CANNOT get away with having a 3d universe as a 2d Mercator projection, because it would distort the distances between the stars themselves, conveying a false image of the universe around us. That's why I propose a 3d map/2d battle hybrid, where, when battle begins (or any kind of player interaction with a ship or a flottila of ships), a seamless transition to 2d could happen. The same thing that Sword of the Stars does. Still, I am grateful for what we have and what we can have. Thanks Steve. Perhaps in the future a full 3d map like the one I proposed in my earlier post can be implemented, along with full 3d battlemap, using of course Newtonian physics. Now, that'd be a game I 'd love to play someday.
-
3d combat in space is completely pointless.
Given the distances that fights may occur, and that any object of interest with few exceptions are on what can easily be assumed a 2d-disk in most single-star systems, a 3D map would be a horrible hassle for displaying that is simply not worth the effort, as it will be two fleets opposing each other, and them moving up or down would just tilt the 2d plane between them.
Sword of the Stars has an extremely simplified system that isn't anywhere close to what Newtonian Aurora could be like, there is no differentiation between combat and no combat.
A star system, roughly equal to Sol in build, is easier to put on a 2D plane than a Sphere, and it has no such things as Terrain.
Whether space is 2d or 3d within this system makes absolutely no difference, as position is only important when calculating the distance to interactive objects.
On the star map, I have no oppinions, but I'd like to remind you of what Auroras current system map looks like.
In 3D, it'd be even harder to work with it, especially since non-explored systems show up as well.
-
about random vs real.
(I know, I'm late)
using real stars give you the same map and strategic choices every time.. because earth is where it is.
but you can have random playthrough and real star system too: just don't start at earth/sol but on some random star within the other real stars.
with all the gazillion combinations, every combination would feel different.
(I think I saw this in a game elitelike, the hard mode was using a random starting position)
-
I personally like a lot the way the map works in eve-online. With a 3D display that is possible to flatten when needed.
-
Stuff
You're right about the Mercator, that was a bad suggestion, but you can still flatten a 3d map into 2d without distance distortions.
I personally am against a 3d map display because I don't feel it can add anything over a 2d map except for a more cumbersome interface. Any information I can think of which can be displayed in a 3d map can be displayed more quickly in 2d (although if we had 3d monitors it might be different).
The other thing about making the game 3d is that - like Unlimited said - unless you're dealing with more than 3 points (fleets) in space, any combat can be viewed on a 2d plane.
-
I think I have concluded by this point that 3D probably isn't workable. Someone mentioned EVE, which made me realise that I always flatten the map so I can work out connections. Given the option of 2D or 3D in a game, it turns out I choose 2D :)
Steve
-
In terms of the actual content, what sort of "terrain" are you planning? Are you thinking of something more realistic, which given the current scale would be a thousand stars forming a few star clusters? Or something a bit less accurate, but perhaps more interesting, such as a 1000-star galactic arm or spiral galaxy, complete with nebulii and a central black hole?
Nebulas alone may be interesting, since they might slow hyperspace travel. Odd "galaxy" shapes may also provide interesting tactical considerations-jumping across the gap between arms might take a long time, but get you past some fortified system near the core.
-
In terms of the actual content, what sort of "terrain" are you planning? Are you thinking of something more realistic, which given the current scale would be a thousand stars forming a few star clusters? Or something a bit less accurate, but perhaps more interesting, such as a 1000-star galactic arm or spiral galaxy, complete with nebulii and a central black hole?
Nebulas alone may be interesting, since they might slow hyperspace travel. Odd "galaxy" shapes may also provide interesting tactical considerations-jumping across the gap between arms might take a long time, but get you past some fortified system near the core.
For the moment the random stars will be randomly scattered and the real stars will be in their squashed positions with the x/y coordinates corrected for the missing z coordinates. Nebulas are included. Below is a screenshot of my test game galactic map (a random map). Obviously this screen is still 'under construction'.
(http://www.pentarch.org/steve/Screenshots/GalMap2.PNG)
Steve
-
The map looks awesome! *bounces on chair* Can't wait to have that for a game on my screen!
-
I like the map too ;D. Althought i wonder how it would look in black with some (colored) graphicsfor the stars.
-
Now that certainly looks awesome.
Definitely better than current Aurora, everything has it's place.
Though, if you originally have the Z coordinate, couldn't you reduce it drastically, and outfit the star with a 'halo' to show that it is Z-distorted and thus takes 10% longer to get to?
So, you'll essentially just have stars that are "more distant" despite being where they are.
-
Now that certainly looks awesome.
Definitely better than current Aurora, everything has it's place.
Though, if you originally have the Z coordinate, couldn't you reduce it drastically, and outfit the star with a 'halo' to show that it is Z-distorted and thus takes 10% longer to get to?
So, you'll essentially just have stars that are "more distant" despite being where they are.
To give my 2 cents, I feel that that would be overly confusing. I think it's fine to just compensate along the X and Y. The star would simply be moved up to the flat plane, and it's distance from sol represented in that direction (say it's 2 light years away, slightly to the "right" and a lot "down" it would be represented by being two light years from sol to the "right". Yes, I pulled that number out my ass, I'm aware there's no star that close). I guess that's how it's going to work, but I haven't really been paying attention. I like the look of it as it is anyhow.
-
I just hope there'll be a random stats option, I certainly don't want a game type where a single system has a special role, and I happen to be in it.
-
I've written the code to generate a real stars map, using a formula that maintains the correct distance from Sol by pushing out the x,y coordinates while maintaining the bearing of the system from Sol. This means everything is the right distance away from Sol and everything is the right direction from Sol but other stars may not be the correct distance/direction from each other. I haven't decided if this is the final method yet but here are some screenshots, each one more zoomed out than the last. I only generated 500 systems rather than the full 1800.
(http://www.pentarch.org/steve/Screenshots/RealStarsZoom0.PNG)
(http://www.pentarch.org/steve/Screenshots/RealStarsZoom2.PNG)
(http://www.pentarch.org/steve/Screenshots/RealStarsZoom4.PNG)
-
I looked again at the possibility of 3D map but it is much easier for people to comprehend 2D. I also considered a 2D map with depth, so a star would appear in the correct x/y position with some graphical representation of the Z coordinate. The problem is that something could appear next to Sol on the 2D map and be 100 LY away, which is not very intuitive. One thing I may do is take the maps above and move stars a little in cases where they are very close together as a result of the projection method.
Steve
-
That'd be nice, because, sorry, that looks silly.
Theres a huge amount of open space around Sol, and then the stars are all bunched up.
I really dislike the feeling of being in a system that is somehow special for some inconceivable reason.
On the other hand, i prefer random generation anyways.
Also, on a graphical representation, you could pick a middle ground, where something very close but high or low would move a bit, but not all the way.
It would be an option to just have a dual 2d map, with top and bottom layer.^^
-
That'd be nice, because, sorry, that looks silly.
Theres a huge amount of open space around Sol, and then the stars are all bunched up.
I really dislike the feeling of being in a system that is somehow special for some inconceivable reason.
Well, you could pick plenty of other systems on that map that have similar space around them so Sol isn't really special. As to whether it looks 'silly' :), I would suggest that having totally made up systems is slightly more silly than having real systems at the correct distance/direction from Earth. I am open to better suggestions.
On the other hand, i prefer random generation anyways.
The good news is that both real stars and random generation are available.
Also, on a graphical representation, you could pick a middle ground, where something very close but high or low would move a bit, but not all the way.
It would be an option to just have a dual 2d map, with top and bottom layer.^^
I wish it was that simple. Don't forget that stars are just as far above us or below us as they are to the 'left' or 'right', so you can't have a map with only two layers any more than you could have a map with only one distance left or right. The 2D mercator projection of the Earth that is so familar to everyone isn't representative of the way the surface of the Earth really looks either. It's just the best we could come up with to show the surface of the globe on a 2D surface. The problem I have is showing the interior of the globe as well on that same 2D surface.
Stve
-
Maybe there could be something along the line of dwarf fortress, with several Z level. The stars of the level you are not in would just become greyish so it would be more clear. Red for the one aboves and blue for the ones under. (Though this look like what Unlimited just said)
-
Maybe there could be something along the line of dwarf fortress, with several Z level. The stars of the level you are not in would just become greyish so it would be more clear. Red for the one aboves and blue for the ones under. (Though this look like what Unlimited just said)
The issue is making it readable. For example, if you have a star 50 LY to the left of Sol that would be far off the left hand edge of the map on normal zoom. If you have a star 50 LY directly above Sol and one 50 LY below Sol, they would both be in the centre of the map. In fact, at normal zoom, the majority of the stars on a map centered on Sol would be far above or far below while the ones actually close to Sol on a similar plane would be off the map edge. You would get a clustering of stars in the centre of the map, most of which wouldn't be close to Sol or each other. I think that would make it hard to understand what was actually being displayed.
As a way to try and visualize the problem, here is a link to an map showing the closest 100 stars (bear in mind the Aurora map will have to show 1800+) : http://www.atlasoftheuniverse.com/20lys.html
I am working on the assumption that all the map has to do is create the right flavour. How many people playing the game will be able to say that Tau Ceti and TZ Arietis are too close to each other for example? Or, while a decent proportion would know if Alpha Centauri was the correct distance from Sol, how many would know if Alpha Centauri was too close to Bernard's Star or Lalande 21185?
Steve
-
Would it be possible or even feasible to do a 3d projection like this one (http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Nearby_Stars_%2814ly_Radius%29.svg/600px-Nearby_Stars_%2814ly_Radius%29.svg.png)?
-
Would it be possible or even feasible to do a 3d projection like this one (http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Nearby_Stars_%2814ly_Radius%29.svg/600px-Nearby_Stars_%2814ly_Radius%29.svg.png)?
Yes, it's possible. The problem is that it looks OK with 30-50 stars in but when you have 1000 stars, the lines will start to get a little crowded and they will go far higher and lower than in that diagram. I have seen a few diagrams like that when I looked at possible map formats. If you can find one with a lot more stars, I wouldn't mind seeing it just to see if its workable
Steve
-
i think you should stick with 2d flat out. :P
From having played games with 3d strategic maps, they're more trouble than they're worth.
The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.
-
i think you should stick with 2d flat out. :P
From having played games with 3d strategic maps, they're more trouble than they're worth.
The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.
Yes, that is my plan at the moment. I have adjusted the formula that creates the 2D position so it stores the bearing as well. I can adjust those bearings by a degree or two where stars are very close together and then tell the program to regenerate positions based on the adjusted bearings. In that way, I keep the distances correct and the bearings very close to correct.
I just generated a map with all 1800 known stars. When I was creating the known stars list from the Hipparcos Catalogue I tended to add stars close to Earth plus well known stars. That was fine for Standard Aurora but now I have realistic numbers of stars closer to Earth and a halo of very bright or giant stars further out. This isn't an issue for say 500 stars, which will be more than enough for most games, but it makes the full 1800 map look odd. Therefore I am going to start putting more Stars into the DB. Hipparcos has 120,000 stars so I don't think I will finish that job any time soon :)
Steve
-
For adding 120000 stars, I think it'll be easier to just create a quick program to read them out and put them into the correct format, instead of doing it yourself?
Aside, will it be possible to have a setting to, say, leave 0-50% of known stars out randomly, as to make games more different every time?
Could RP it as them just not being lockable for hyperspace travel...
-
i think you should stick with 2d flat out. :P
From having played games with 3d strategic maps, they're more trouble than they're worth.
The only real trouble with the 2d is the clustering and I believe that either futzing the generation or fiddling the stars around manually will be plenty sufficient.
From a graphics point of view I agree with this, which is surprising because the lack of 3D in space games drives me nuts.
If you were willing to go to a full 3D viewport (using XNA, for example, which you can't use 'cuz it's in C#/.NET and you're using VB6), then I would consider going 3D, but this is because you (or users) could then rotate the view to let the brain's circuits kick in and give depth perception. Without that, you're kind of toast. An alternative would be to color-code the names with a depth dependent color (red-high, blue-low, or vice-versa), but then you'd have to have a good query tool to give precise distances.
Reading back through the thread (oh, look, color-coding was suggested), I see you worrying about clustering around Sol. That's because you're using a sphere as the selector for what's displayed. This is a mistake - you should be using a cube as the selector (in the same way you use a square for the viewport, not a circle). If you use a cube, with total depth equal to the horizontal distance displayed, then you shouldn't see any particular clustering in the center.
So the alternative (I think) is to display a cube, with names (and/or dots) labelled with zoom-dependent color that goes through the whole spectrum, with blue near the top of the cube and red near the bottom (or vice versa). This really works a lot better though if you can rotate the view, since that gives separation between stars that get unlucky and lie on top of each other.
If you don't go 3D, then I would just smoosh everything down into the plane. This avoids the weird clustering effects away from Sol. Since you're already not going 3D, you're only in "Almost Real Stars", and it's no big deal to go from 3D to 2D (other than the fact that it's easier to envelope an enemy because the circumference of a circle goes like R, while the surface of a sphere goes like R^2). Interstingly enough, smooshing gives you exactly the same view as the cube ideas.
Ok, here's a weird idea, which might be the one you're already talking about. As far as I can tell, you've proposed changing the actual positions of the stars to rotate them into the equatorial plane, keeping the bearing the same, to generate a new set of 2D locations for the stars. You also mentioned Mercator projects. What if you kept the star locations 3D, but used your rotation trick to generate a 2D Mercator-like "distance" view centered on whichever star happens to be picked (not just Sol). You could still use the color code to flag which stars have actual locations that are either high or low. So white would mean "in the equator - not distorted", blue (because blue-shift is coming at you) would mean "above the equator - actually closer to Sol in xy" and red would mean "below the equator". You could then have two different modes of the map - one undistorted with color-depth coding, and one "distance". Having a quick toggle between modes would give the brain an additional cue for picking out depth. This means that your actual locations would still be exactly correct, but the distance view would simply be a distorting visualization centered on a star, like Mercator.
Note that, from my point of view, I'm MUCH more interested in 3D in the tactical map than in the strategic/galactic. I think Elite's system (with lines into an equitorial plane and rotation of views) is the best I've seen.
John
-
For adding 120000 stars, I think it'll be easier to just create a quick program to read them out and put them into the correct format, instead of doing it yourself?
Aside, will it be possible to have a setting to, say, leave 0-50% of known stars out randomly, as to make games more different every time?
Could RP it as them just not being lockable for hyperspace travel...
Oh I wish it was that simple :)
There are some things that are relatively straightforward, such as converting the HIP catalog's right ascension and declination into XYZ coordinates. However, Aurora has a Stellar Type ID that links each star into the StellarType table. Aurora differentiates between about 500 different star types. The trick is deciding which of those 500 types matches the HIP data. Sometimes that would be possible by taking the Stellar Classification type and converting it but not every record has a full spectrum type, or they aren't stored consistently, or there is only partial information, or there are random characters in the field, or there is additional detailed but unformatted information, or the field is simply blank, etc. The only way is to look at each one and make a decision. Every star is stored independently so multiple star systems aren't obvious. Sometimes the name gives it away such as GJ 1194 A and GJ 1194 B but often the components of a multiple star system have completely unrelated names. It isn't just a case of looking for stars that are close to each other because they are only a multiple star system if they orbit each other. And of course there are several different star catalogs and each one often has a different name for the same star so cross-checking the data is not easy either. Then, if it is a binary system, I have to figure out the orbits and convert to AU. And a few other things I won't bore you with :)
Randomly removing stars defeats the object of a real stars map. If you want a random map, there is a random map option. I might allow the option of removing stars below a certain mass perhaps, using the reason you mentioned as technobabble.
Steve
-
From a graphics point of view I agree with this, which is surprising because the lack of 3D in space games drives me nuts.
If you were willing to go to a full 3D viewport (using XNA, for example, which you can't use 'cuz it's in C#/.NET and you're using VB6), then I would consider going 3D, but this is because you (or users) could then rotate the view to let the brain's circuits kick in and give depth perception. Without that, you're kind of toast. An alternative would be to color-code the names with a depth dependent color (red-high, blue-low, or vice-versa), but then you'd have to have a good query tool to give precise distances.
Reading back through the thread (oh, look, color-coding was suggested), I see you worrying about clustering around Sol. That's because you're using a sphere as the selector for what's displayed. This is a mistake - you should be using a cube as the selector (in the same way you use a square for the viewport, not a circle). If you use a cube, with total depth equal to the horizontal distance displayed, then you shouldn't see any particular clustering in the center.
So the alternative (I think) is to display a cube, with names (and/or dots) labelled with zoom-dependent color that goes through the whole spectrum, with blue near the top of the cube and red near the bottom (or vice versa). This really works a lot better though if you can rotate the view, since that gives separation between stars that get unlucky and lie on top of each other.
If you don't go 3D, then I would just smoosh everything down into the plane. This avoids the weird clustering effects away from Sol. Since you're already not going 3D, you're only in "Almost Real Stars", and it's no big deal to go from 3D to 2D (other than the fact that it's easier to envelope an enemy because the circumference of a circle goes like R, while the surface of a sphere goes like R^2). Interstingly enough, smooshing gives you exactly the same view as the cube ideas.
Ok, here's a weird idea, which might be the one you're already talking about. As far as I can tell, you've proposed changing the actual positions of the stars to rotate them into the equatorial plane, keeping the bearing the same, to generate a new set of 2D locations for the stars. You also mentioned Mercator projects. What if you kept the star locations 3D, but used your rotation trick to generate a 2D Mercator-like "distance" view centered on whichever star happens to be picked (not just Sol). You could still use the color code to flag which stars have actual locations that are either high or low. So white would mean "in the equator - not distorted", blue (because blue-shift is coming at you) would mean "above the equator - actually closer to Sol in xy" and red would mean "below the equator". You could then have two different modes of the map - one undistorted with color-depth coding, and one "distance". Having a quick toggle between modes would give the brain an additional cue for picking out depth. This means that your actual locations would still be exactly correct, but the distance view would simply be a distorting visualization centered on a star, like Mercator.
Note that, from my point of view, I'm MUCH more interested in 3D in the tactical map than in the strategic/galactic. I think Elite's system (with lines into an equitorial plane and rotation of views) is the best I've seen.
Interesting point about the cube. I was using the closest x number of systems from Sol when the user picks a number of system, which naturally ended up as a sphere. I could convert that to a square without too much trouble, although then you would then include some stars further away from Sol than other stars which were excluded. I am not keen on the color-coding idea as the stars are already color-coded by stellar classification, which I would lose if I coded by z distance. I also don't want to just squash everything straight down as there would be stars close to Earth. I think most people who play would know that Proxima/Alpha Centauri is the closest system to Earth and that it is a little over 4 LY away. Many will also know which systems are fairly close to Earth. I also want to be able to include distances from Sol in fiction and those need to be correct. So I don't want to use any system that changes the distances of stars from Earth. On the other hand, hardly anyone will know the distances between other stars so that is a far easier suspension of disbelief.
Looking at the zoomed out map, the gap around Sol is not noticeably different than similar gaps around many other stars on the map so that doesn't bother me. Star density will be obviously higher than in real life but the projection means that density will be uniform across the map. My only real concern is that in fiction terms it would be nice to have the correct distances between stars.
The idea of two different map types is interesting too, although it would lead to one map with coloured systems obscuring each other and the second map would look different for every star, which might be disconcerting for a lot of players.
I have been scouring the internet for other star maps to try and find something that shows hundreds of stars in a clear way but so far I haven't found one. I assume if there is a good way to do this, someone will already have done it. If someone is going to change my mind, pointing me to an example of that type of map is definitely the best way.
Steve
-
Oh I wish it was that simple :)
There are some things that are relatively straightforward, such as converting the HIP catalog's right ascension and declination into XYZ coordinates. However, Aurora has a Stellar Type ID that links each star into the StellarType table. Aurora differentiates between about 500 different star types. The trick is deciding which of those 500 types matches the HIP data. Sometimes that would be possible by taking the Stellar Classification type and converting it but not every record has a full spectrum type, or they aren't stored consistently, or there is only partial information, or there are random characters in the field, or there is additional detailed but unformatted information, or the field is simply blank, etc. The only way is to look at each one and make a decision. Every star is stored independently so multiple star systems aren't obvious. Sometimes the name gives it away such as GJ 1194 A and GJ 1194 B but often the components of a multiple star system have completely unrelated names. It isn't just a case of looking for stars that are close to each other because they are only a multiple star system if they orbit each other. And of course there are several different star catalogs and each one often has a different name for the same star so cross-checking the data is not easy either. Then, if it is a binary system, I have to figure out the orbits and convert to AU. And a few other things I won't bore you with :)
Randomly removing stars defeats the object of a real stars map. If you want a random map, there is a random map option. I might allow the option of removing stars below a certain mass perhaps, using the reason you mentioned as technobabble.
Answering both parts of the above gave me an idea. The HIP catalog has a lot of stars, especially at longer distances, that only have a partial classification, such as M, instead of M5V, or M2V. I haven't been including these due to a lack of data on their exact type. However, to add some randomization to the real stars map, I will include these and randomly generate the rest of the classification in each game. I'll assume they are main sequence stars unless there is some information to the contrary.
Steve
-
I have been scouring the internet for other star maps to try and find something that shows hundreds of stars in a clear way but so far I haven't found one. I assume if there is a good way to do this, someone will already have done it. If someone is going to change my mind, pointing me to an example of that type of map is definitely the best way.
Oh, I wasn't trying to change your mind - I was just throwing stuff out there :)
I think the "good way to do this" that "someone will already have done" is full "fly through" 3D rendering, which of course you can't do in VB6. There's an example at the scale you're looking for at about 3:52 in this clip
An example of what I meant about small rotations in the view giving 3D depth can be found at this app: http://areu.free.fr/univers/index.php - I think the 20ly and 50ly neighborhoods are exactly what you're looking for.
What I was looking for with my googling IIRC was this: http://www.shatters.net/celestia/ I didn't download it today, but I think this is what a colleague showed me a few years ago - it was pretty cool.
Too bad you don't have a good 3D viewport available in VB6....
John
-
Steve, check out Astrosynthesis from NBOS. You can create a starmap in 3D and export it. Then you'd just need to import it into Aurora. Astrosynthesis also takes care of the generation of the map (though that can be cpu intensive).
Edit: I'd not yet read RedKing's post where he mentions this software also.
-
What about using multiple reference points, not just Sol?
- Divide the map into square sectors.
- Choose center stars for each sector which are in the same z-plane as Sol. These are reference points. (Alternatively just use absolute coordinates as sector centers and therefore reference)
- Calculate maps for each reference point using your method.
- Blend the maps together. Each star uses coordinates relative to its closest reference point. It is put into the sector with these coordinates. The other multiples are cut out. This will randomize high-Z stars somewhat, but not more than the current method.
-
Riffing on semirandomizing real stars: Quasireal map mode - Always includes well known stars and those proximate to Sol, but thins out other stars on a per-game basis to reduce clustering.
-
Steve, check out Astrosynthesis from NBOS. You can create a starmap in 3D and export it. Then you'd just need to import it into Aurora. Astrosynthesis also takes care of the generation of the map (though that can be cpu intensive).
Edit: I'd not yet read RedKing's post where he mentions this software also.
Yes, I had a look at Astrosynthesis a few days ago. I could generate star maps but I can't add Aurora-related information to them, such as number of habitable planets, survey status, location of fleets, shipyards, etc, and you wouldn't be able to double-click them to enter a system, or use the right-click menu, etc.. Also, I don't think the developer would be too keen on me buying his product and then distributing it with Aurora :)
Steve
-
Oh, I wasn't trying to change your mind - I was just throwing stuff out there :)
That was a general comment rather directed at you :)
I think the "good way to do this" that "someone will already have done" is full "fly through" 3D rendering, which of course you can't do in VB6. There's an example at the scale you're looking for at about 3:52 in this clip
An example of what I meant about small rotations in the view giving 3D depth can be found at this app: http://areu.free.fr/univers/index.php - I think the 20ly and 50ly neighborhoods are exactly what you're looking for.
The 50 LY star map has 133 stars and it isn't that easy to see how some of those stars relate to one another. However, this map is only showing stars that are visible from Earth. That volume of space actually has over 1000 stars, almost all of which are in Aurora. So imagine that map with 8x as many stars displayed and consider how readable it would be
What I was looking for with my googling IIRC was this: http://www.shatters.net/celestia/ I didn't download it today, but I think this is what a colleague showed me a few years ago - it was pretty cool.
Too bad you don't have a good 3D viewport available in VB6....
I had a look at the screenshots but they were all solar system related rather than interstellar.
Does anyone know of any other 4x games that use a 3D star map? Just looking for inspiration. It may just be me but I find 2D maps far easier to navigate and easily comprehend than 3D ones. The only game I can think of that has a 3D map is EVE and I always use the flattened 2D version. If anyone else plays EVE, which version of the Starmap do you use?
Steve
-
The 50 LY star map has 133 stars and it isn't that easy to see how some of those stars relate to one another. However, this map is only showing stars that are visible from Earth. That volume of space actually has over 1000 stars, almost all of which are in Aurora. So imagine that map with 8x as many stars displayed and consider how readable it would be
Going back to this point, I suppose you would zoom in on a particular star and see how everything else related to that. The map could be displayed with frame of reference based on the currently selected system, rather than a general map. In that way you could navigate around the whole map. Also filtering may be able to reduce the numbers actually displayed. I'll might try something along these lines just to see how workable it would be
Steve
-
Yes, I had a look at Astrosynthesis a few days ago. I could generate star maps but I can't add Aurora-related information to them, such as number of habitable planets, survey status, location of fleets, shipyards, etc, and you wouldn't be able to double-click them to enter a system, or use the right-click menu, etc.. Also, I don't think the developer would be too keen on me buying his product and then distributing it with Aurora :)
Steve
What I meant was to use AS to generate the maps, then import the data into Aurora. Use it to do some of the grunt work :)
-
There are now 2200 real star systems for Newtonian Aurora, including every catalogued star of M9 class or above within 50 light years of Earth (which is about 1000 stars)
Steve
-
What I meant was to use AS to generate the maps, then import the data into Aurora. Use it to do some of the grunt work :)
Interesting idea. I would have to look at the data output and see if it is any more useful than the Hipparchus data.
Steve
-
Does anyone know of any other 4x games that use a 3D star map? Just looking for inspiration. It may just be me but I find 2D maps far easier to navigate and easily comprehend than 3D ones. The only game I can think of that has a 3D map is EVE and I always use the flattened 2D version. If anyone else plays EVE, which version of the Starmap do you use?
The only ones I can think of were
master of orion 3 http://reviews.cnet.com/pc-games/master-of-orion-iii/4528-9696_7-30989341-2.html
ascendancy . http://en.wikipedia.org/wiki/File:AscendancyGameParameters.png
Regarding Eve, before I kicked the habit I must admit that I flattened the map but have to say with Eve jump gates it was more the route than the distance and when using a carrier I just used an external program to find me the best route. Where distance and hence travel time will be far more important I can how 3d could be more interesting but happy with a flat map in any case as per the old Elite maps even.
-
If anyone else plays EVE, which version of the Starmap do you use?
I only use the 3D map, because I don't like when stars are stack on each others, and for who knows reason, I just need the spatial sense of where I am. But reading all this, I realize that in EVE, the map is actually quite flat anyway, and there are the lines between systems that helps having a sense of depth. I guess a 3D map in Aurora would need some kinds of line, like constellation or whatever to help visualise the 3D. I know that real constelation wouldn't work as they are from an earth point of view. But it could be premaind "sectors" or something.
-
I like the clustering Idea, where you pick a random, large enough star and create a cluster based on it.
Stars in the border regions could be randomly assigned to one cluster, and thus might have slightly different positions.
I also really like the idea of having a large 2D map and when selecting a star it shows you the select distance around it in 3D.
You could also partially flatten it, like picking a cluster with a radius of, say, 75 LY, and giving it a maximum height of 50, and everything above that would be cut down by 50% Z coordinate or to 50 LY displacement, whatever is less change.
That way, it'd limit it to a reasonable sphere the player can look at.
The reason I suggested that some stars are not reachable (they don't need to be invisible, though toggling would be nice) was that otherwise, basically every game would play the same, the player visits the closest systems first that are large enough to have a good chance for whatever. Whatever's worth your fuel.
Those stars needn't be of limits, just not reachable in the start of the game, maybe require Hyper-Level 3 or just counting as a higher distance for the risk/accuracy.
Where, I suppose that horse's been beaten.^^
-
That was a general comment rather directed at you :)
The 50 LY star map has 133 stars and it isn't that easy to see how some of those stars relate to one another. However, this map is only showing stars that are visible from Earth. That volume of space actually has over 1000 stars, almost all of which are in Aurora. So imagine that map with 8x as many stars displayed and consider how readable it would be
I had a look at the screenshots but they were all solar system related rather than interstellar.
Does anyone know of any other 4x games that use a 3D star map? Just looking for inspiration. It may just be me but I find 2D maps far easier to navigate and easily comprehend than 3D ones. The only game I can think of that has a 3D map is EVE and I always use the flattened 2D version. If anyone else plays EVE, which version of the Starmap do you use?
Steve
I use the flattened 2D version of the Eve map - it is perfectly readable and usable.
In my opinion, for something this complex and information display intensive, you have to make some sort of compromise to make it usable in the end. If you were creating a navigational program for some kind of interstellar transport then yeah, make it realistic. But you are making a game/tech-dictionary for your fiction so use a couple of grains of salt :)
-
Sword of the Stars 2 has a 3D map, it might be worth checking out.
-
Sword of the Stars 2 has a 3D map, it might be worth checking out.
Oh, yeah - I'd forgotten that.... IIRC the way to get depth perception is to center the map on a star and rotate around that star.
John
-
It can be very difficult to work with a star near the center of them map. I prefer a semi-2d map when I play it.
-
The 2D mercator projection of the Earth that is so familar to everyone isn't representative of the way the surface of the Earth really looks either. It's just the best we could come up with to show the surface of the globe on a 2D surface.
No, it isn't. Not even close. The Mercator is an awful projection for anything except navigation, and it annoys me when people use it. There are far better projections for any other use.
Sorry, I'm a bit of a cartography geek.
-
On farther reflection, I don't think the current plan is a good one. It works fairly well towards the center, but at the far reaches, the distortion will be massive. For example:
Take three stars, A, B, & C, all 100 ly from earth, with the following coordinates:
Star Bearing Elevation
A 90 0
B 90 89
C 270 89
As you can see, B&C are quite close together (3.5 ly), while A is far from both of them (140 ly ish). However, under the current algorithm, A&B will have the same coordinates, and be 0 ly apart, while C will be 200 ly from both of them. I have to wonder if this is a good idea.
-
Well, the point is, does anyone care about the relative locations of stars that far from earth? Heh.
-
I'd look at radar or tactical displays in space combat games, as well. A number had reasonable solutions to these problems. (Homeworld's sensor displays and movement orders come to mind.)
The best I can describe it is to pick a plane of zero "height" (Presumably, this would be the species' home system.) Then draw the star map from the 3/4 perspective view, including height. Then, draw a line connecting the floating star icon to the 2d "zero height" plane.
The positions of the base of the lines on the 2d plane give you a sense of the x/y projection of the stars' positions, while the length of the line, and whether it's above or below the star gives you a sense of how far above or below it is from the zero plane. It works better when you can manipulate the map to get a sense of perspective from parallax, but it's still good enough to communicate what you need in a still image.
Here's the best image I could find: (The orange circles and lines are what you should be paying attention to, not the blue movement order)
http://firsthour.net/screenshots/homeworld/homeworld-tutorial-3d-scout-movement-scout-ships.PNG (http://firsthour.net/screenshots/homeworld/homeworld-tutorial-3d-scout-movement-scout-ships.PNG)
-
You need to actually have a 3d rotatable display for that, it's more confusing/less clear than 2d, and theres not a lot of actual gameplay value to being in 3d.
-
Didn't Sins of Solar Empire have a 3d map?
-
Yes.
Keep in mid though that most of these games are either actual 3D, which obviously eases navigation quite a bit, or a lot smaller in scale.
-
No, it isn't. Not even close. The Mercator is an awful projection for anything except navigation, and it annoys me when people use it. There are far better projections for any other use.
Sorry, I'm a bit of a cartography geek.
Yes, I know its a bad projection - that was sort of my point. People quickly learn to live with a view of the world that isn't close to reality but is enough for their needs.
Steve
-
On farther reflection, I don't think the current plan is a good one. It works fairly well towards the center, but at the far reaches, the distortion will be massive. For example:
Take three stars, A, B, & C, all 100 ly from earth, with the following coordinates:
Star Bearing Elevation
A 90 0
B 90 89
C 270 89
As you can see, B&C are quite close together (3.5 ly), while A is far from both of them (140 ly ish). However, under the current algorithm, A&B will have the same coordinates, and be 0 ly apart, while C will be 200 ly from both of them.
Absolutely true. However, the point of the 2D projection I am using is that facts that everyone is familar with, such as the nearest star to Earth is Proxima Centauri, or that systems close to Sol include Barnard's Star, Lalande 21185, Wolf 359, etc., will remain true, as will facts known to a smaller proportion of the playerbase, such as Vega is 25 light years from Earth. All of this helps to suspend disbelief and create an environment that feels real. Facts that virtually no one knows, such as three random stars 100 light years from Earth are the wrong distance from each other, are not a problem when it comes to suspension of disbelief.
I have to wonder if this is a good idea.
If I want to create an accurate star map then it wouldn't be a good idea. If I want to create a map that is easy to read, allows for suspension of disbelief and has a real stars feel to it, then it might be a good idea. although I haven't decided for certain yet.
Steve
-
I'd look at radar or tactical displays in space combat games, as well. A number had reasonable solutions to these problems. (Homeworld's sensor displays and movement orders come to mind.)
The best I can describe it is to pick a plane of zero "height" (Presumably, this would be the species' home system.) Then draw the star map from the 3/4 perspective view, including height. Then, draw a line connecting the floating star icon to the 2d "zero height" plane.
The positions of the base of the lines on the 2d plane give you a sense of the x/y projection of the stars' positions, while the length of the line, and whether it's above or below the star gives you a sense of how far above or below it is from the zero plane. It works better when you can manipulate the map to get a sense of perspective from parallax, but it's still good enough to communicate what you need in a still image.
Here's the best image I could find: (The orange circles and lines are what you should be paying attention to, not the blue movement order)
http://firsthour.net/screenshots/homeworld/homeworld-tutorial-3d-scout-movement-scout-ships.PNG (http://firsthour.net/screenshots/homeworld/homeworld-tutorial-3d-scout-movement-scout-ships.PNG)
I have been experimenting with a semi-3D view, that has an Elite style zero plane with systems above and below connected to the zero plane with stalks, similar to one of the screenshots John posted. I'm not happy with it so far on the ground of readability but I haven't made a final decision one way or the other. I think the 2D projection is still my preferred option so far.
Steve
-
Ironically enough, the biggest thing about spaceflight- the whole 3D thing- has remarkably little strategic effect when you get in-game.
-
Ironically enough, the biggest thing about spaceflight- the whole 3D thing- has remarkably little strategic effect when you get in-game.
Well, that's true on the solar system level, because those are mostly 2D, however if you did add a full 3D galactic map you would have some big differences. The main one being that you could have invasion forces coming from stars directly 'above' or 'below' the ecliptic plane, completely bypassing listening posts or fleets based out on planets, moons, or asteroids.
-
IMO, that tends to detract from gameplay more than add to it. The impossibility of picketing in three dimensions leads to centralization of forces. You just end up not having those listening posts and other pickets in the first place.
Although the nature of ship movement in Newtonian Aurora might lead to not having pickets in the first place. Or it might necessitate pickets. It kinda depends on how strategery and sensors work out. Hard to figure how interceptors (ships) will work, especially if you're trying to defend against a high speed strike on an inhabited world.
-
Well, that's true on the solar system level, because those are mostly 2D, however if you did add a full 3D galactic map you would have some big differences. The main one being that you could have invasion forces coming from stars directly 'above' or 'below' the ecliptic plane, completely bypassing listening posts or fleets based out on planets, moons, or asteroids.
That was another reason I was considering sticking with 2D. With a 3D galactic map, ships would still have to transition to a 2D system map, so ships coming from above and below might enter the system map from the same direction, if their systems of origin had the same xy coordinates but different z coordinates. There is definitely no way I am considring a 3D system map :)
Steve
-
I'm having an "adding real stars" blitz at the moment :). There are now 2850 real stars, including every star within 72 LY of Earth that is M9 class (small red dwarf) or larger.
Steve
-
I believe this was already mentioned, but being able to select the reference from which to base the flat projection would be my preferred method, if recalculating the projection wasn't a costly operation.
Otherwise, the point about how two stars far from Earth being the wrong distance apart won't be noticed is a good one.
-
Can't you offer options at game generation?
Like one that flattens and distorts completely, one that flatts by 80% and then clusters the result, etc?
Given that you're already experimenting with it, the cost must be there. ;D
Though I certainly think full 3D would distract me from the game.
Reducing all heights by 80% and clustering would be my favourite, that way, one could still watch it from "above" for simplicity, only the jump distances wouldn't be properly represented.
Which I wouldn't care for in the first place, it should be possible to select a task force, then select a system on the map, and it tells you how long a jump would last at, say, 1000kms.
Or daily acceleration, or whatever.
What do I care if the jump duration matches the shown distance, if I can actually see both if I have to?
-
I guess the table for the new stars looks a bit different then the one for the old by having some new attributes ;D. So my question is if the procedural generation could also be manipulated a bit more on Game-start? I would like to have some way to manipulate the density of clusters, average number of stars in a cluster, average distances between clusters, Startype distribuitions etc. .
Densely packed clustes which are far apart from each other could lead to a easy and fast start with strong empires clashing later on for example.
-
As Steve had mentioned, the idea of trying to mix a 3d star map with a 2d system map seems like a bad idea.
Given the issues with trying to turn a 3d solar system into a 2d map I also agree that once you get the most common stars in place you are probably better off with what is close to a random distribution of stars further out. If you are just packing down stars from their 3d locations I would think you would need a system to spread them out where they would otherwise be pretty much on top of one another.
Oh and Steve great going on adding all the new stars out to 72 light years, although I'm sure I read in the press recently that they had spotted a nice new planet in the goldilocks zone at around the 600 light year mark.....!
-
As Steve had mentioned, the idea of trying to mix a 3d star map with a 2d system map seems like a bad idea.
Given the issues with trying to turn a 3d solar system into a 2d map I also agree that once you get the most common stars in place you are probably better off with what is close to a random distribution of stars further out. If you are just packing down stars from their 3d locations I would think you would need a system to spread them out where they would otherwise be pretty much on top of one another.
I'm not using a random distribution. I am keeping their bearing and their distance but moving everything down to a 2D plane. Imagine every star connected to Sol by a string. I am keeping the string taut and moving the star down to the ground (or up to the ground) without changing its direction. They aren't on top of one another because they are moving outwards as well as down. The distribution of stars remains constant because although there are more stars as you move further out, they are spread over a wider area. This isn't a guess - this is based on generating the maps. Occasionally 2 stars will be too close to one another so I devised a way of overridng their bearing from Sol and moving them a degree or two left or right while maintaining the same distance. Within 25 LY of Earth I have had to adjust about 6 stars from 2-3 degrees so it isn't a major change.
Oh and Steve great going on adding all the new stars out to 72 light years, although I'm sure I read in the press recently that they had spotted a nice new planet in the goldilocks zone at around the 600 light year mark.....!
That might take a while :). Every LY out from Sol has an increasing number of stars so it becomes exponentially more work for each extra LY.
Steve
-
Do we really need all of them?
Because, that'll limit it to a very small distance if you take a small amount of systems...
Taht's primarily why I asked to be able to shut some off.
-
Do we really need all of them?
Because, that'll limit it to a very small distance if you take a small amount of systems...
Taht's primarily why I asked to be able to shut some off.
It's called Real Stars for a reason :). I won't be randomly removing some as that would then be random stars and there is already a random stars option. One possibility might be to exclude stars under a certain mass but that would take away a lot of the nearby stars that players will have heard of, which sort of defeats the object of a real stars map. For example, Proxima Centauri, Barnards Star, Wolf 359, Teegardens Star, Lalande 21185, Ross 248, Lacaille 9352, etc, are all low mass red dwarf stars.
Besides, there are no performance reasons not to have a large number of systems as the planets are only generated when someone first visits the system. The only difference will be the loading time of the galactic map. There is always random stars if you want a less realistic option.
Steve
-
Steve
Apologies for the tounge in cheek comment on getting further out on mapping all the stars, I realise what a huge laborious task task that is. Regarding your point on system generation and keeping as is with current aurora I was wondering if in fact players should have an idea of the planets in another system ahead of visiting them given our existing ability to detect planets at huge ranges even today. I guess this would mean a significant load at start up but systems could be thought of as fixed until visited and details around minerals, asteroids, moons etc plus aliens cold be left for generation once actually visited?
-
Perhaps "Deep Space Tracking Stations" might have a rating where as you add more stations, you can detect smaller planets at greater distances. Of course, you have to visit the system to know anything other than the mass of these planets.
I'm getting the feeling that the player will explore far more star systems in Newtonian, since you could build a very crude ship that might burn through fuel like mad, but could effectively travel through several systems in only a few months. As it is, you need to have a small squadron on ships to jump to a system, scan, scan, scan, scan and jump to the next system.
-
We can assume that this would only include superjovians being visible on distances above 10 LY, as "reasonable timeframe" is a fitting keyword here.
That that'd alone be interesting.
Most interesting planets we discover have a specific characteristic that makes them visible to us, like being very massive, very close to the star, traveling right in front of it....
Hard to just simulate this, though I suppose that entering the info we have would do no harm.
It does, however, include serious work.
-
We can assume that this would only include superjovians being visible on distances above 10 LY, as "reasonable timeframe" is a fitting keyword here.
That that'd alone be interesting.
Most interesting planets we discover have a specific characteristic that makes them visible to us, like being very massive, very close to the star, traveling right in front of it....
Hard to just simulate this, though I suppose that entering the info we have would do no harm.
It does, however, include serious work.
Actually it seems like it would be really easy to simulate that. If you know the mass of the star and the planet (and the game well) you can make some sort of metric for the probability of detecting it every month or so. The game also knows when big planets are in between the Sun and their star.
The real problem is that would involve generating the planets (at least) of a lot of systems before any ships ever actually went there, which could be a memory issue.
-
Steve
Apologies for the tounge in cheek comment on getting further out on mapping all the stars, I realise what a huge laborious task task that is. Regarding your point on system generation and keeping as is with current aurora I was wondering if in fact players should have an idea of the planets in another system ahead of visiting them given our existing ability to detect planets at huge ranges even today. I guess this would mean a significant load at start up but systems could be thought of as fixed until visited and details around minerals, asteroids, moons etc plus aliens cold be left for generation once actually visited?
Something along those lines might be possible but there are some issues. The first is that in order to be able to detect such planets I would have to generate them first. At the moment system bodies are only generated when someone enters the system for the first time. Having several hundred or even several thousand pre-generated systems would slow the game down considerably and it would take a long time to create the initial game. I couldn't simply leave out minerals, moons and asteroids, etc. without significant changes to system generation, not to mention that some moons are larger than some planets. A second lesser issue is that I would have to track which races know about which planets in which systems.
The major question though is whether knowing that system x had a large planet but you couldn't detect one in system y would significantly change your exploration of the galaxy. I would imagine players will generally visit all nearby systems using scout ships, regardless of whether a large planet had been detected, just to see for sure what was in the system. If nothing significant changes as a result of being able to detect planets at interstellar distances then it seems like a lot of work and a performance hit for no real gain in gameplay terms.
Steve
-
I've reached my target of all stars within 100 LY of Earth entered into the Newtonian Aurora DB. There are now 4250 real star systems, 3850 of which are within 100 LY of Earth. Outside 75 LY or so there are far fewer red dwarf stars, presumably because they are hard to detect at that distance with our current technology.
Steve
-
Since there's no evidence that there actually are fewer red dwarfs, doesn't it seem reasonable to add presumed stars? That isn't to say they'd be random- at least not in the sense of changing in every game- just that they are stars we expect to be there that we haven't proven.
It just seems to me that having a uniform set of realistic stars is more "real" than having only a few proven stars that are proven to exist.
-
Since there's no evidence that there actually are fewer red dwarfs, doesn't it seem reasonable to add presumed stars? That isn't to say they'd be random- at least not in the sense of changing in every game- just that they are stars we expect to be there that we haven't proven.
It just seems to me that having a uniform set of realistic stars is more "real" than having only a few proven stars that are proven to exist.
Yes, that is a good point. I will also look at finding more up to date information. The Hipparchus data is from 1998 so more red dwarfs stars will have been found since then. Unfortunately, it is a major task identifying them from many different sources whereas the Hipparchus data for 120,000 stars was available in an Access database.
Steve
-
Hi,
The distribution of stars remains constant because although there are more stars as you move further out, they are spread over a wider area. This isn't a guess - this is based on generating the maps.
But wouldn't the clustering problem remain the same? Real stars at distance R belong to a sphere with surface 4 PI R^2. On a 2D map, they get drawn over a circle 2 PI R long. If you double the distance, the surface of the sphere is multiplied by four, but all systems at this distance will be drawn over a circle only twice as long. Unless the density of stars falls drastically as one gets away from the "central system", you will have clustering.
This has two consequences. If star density is constant, the further you move away from earth, the more clustered the stars should appear on the 2D map (note this might be attenuated when using real stars, because star catalogues are segregated by magnitude: as you move away from Earth, smaller systems don’t get listed). Also, 2D projection greatly reduces the distance between two systems chosen at random. In my opinion, this is the main flaw in your “string method”. You are keeping the correct distances to Sol, but shrinking all the rest.
There is no simple solution: 3D space is just much larger than 2D space.
How are you modeling the actual positions of stars, in 2D or 3D (meaning you have bearing and elevation, or just bearing)? If your actual data model is 2D, I would suggest the following approach for real stars generation:
Generate random stars in 2D, from a density map (something that measures the average number of systems in every area of the map). Then pick one as Sol, sort all others by distance to it, and name them from a real star catalogue. The closest star would be Proxima, and then Alpha, Barnard, and so on. The resulting map would have the right stars at plausible distances (for the nearest ones, at least), and would not suffer from “projection clutter”.
Francois
(Be kind on me please, first post…. )
-
Hi,
But wouldn't the clustering problem remain the same? Real stars at distance R belong to a sphere with surface 4 PI R^2. On a 2D map, they get drawn over a circle 2 PI R long. If you double the distance, the surface of the sphere is multiplied by four, but all systems at this distance will be drawn over a circle only twice as long. Unless the density of stars falls drastically as one gets away from the "central system", you will have clustering.
This has two consequences. If star density is constant, the further you move away from earth, the more clustered the stars should appear on the 2D map (note this might be attenuated when using real stars, because star catalogues are segregated by magnitude: as you move away from Earth, smaller systems don’t get listed). Also, 2D projection greatly reduces the distance between two systems chosen at random. In my opinion, this is the main flaw in your “string method”. You are keeping the correct distances to Sol, but shrinking all the rest.
There is no simple solution: 3D space is just much larger than 2D space.
How are you modeling the actual positions of stars, in 2D or 3D (meaning you have bearing and elevation, or just bearing)? If your actual data model is 2D, I would suggest the following approach for real stars generation:
Generate random stars in 2D, from a density map (something that measures the average number of systems in every area of the map). Then pick one as Sol, sort all others by distance to it, and name them from a real star catalogue. The closest star would be Proxima, and then Alpha, Barnard, and so on. The resulting map would have the right stars at plausible distances (for the nearest ones, at least), and would not suffer from “projection clutter”.
Francois
(Be kind on me please, first post…. )
Its a good point about the surface of the sphere vs the circumference of the circle. Also a good point that as you move away from Earth, smaller systems don’t get listed. Looking at the map I have generated for the nearest 3000 stars for my test campaign, those two factors seem to balance out fairly well, leaving a much denser distribution of systems than a random map but with no greater density at greater distances. Besides, 'real stars' systems tend to produce less habitable worlds than random systems so the actual desnsity of useful systems may not vary much between the two options.
I wouldn't be keen on random systems with the only element of 'real stars' being the idea of naming them based on order of proximity. That is almost the same as random stars. The whole point of real stars is using the actual mass and spectral class of each star and having them in the correct xy direction.
I am pretty happy with what I have ended up with at the moment, at least enough to use it for playtesting. As I get into the test campaign, I'll be able to get a better idea of the playability of the mapping system.
Steve
-
I wouldn't be keen on random systems with the only element of 'real stars' being the idea of naming them based on order of proximity. That is almost the same as random stars. The whole point of real stars is using the actual mass and spectral class of each star and having them in the correct xy direction.
Can we have this as a random map option? Please? =)
-
Can we have this as a random map option? Please? =)
You mean an option to take the list of system names from the real stars table in order of distance from Sol and apply them to the systems in a random map games in their order of distance from Sol?
Steve
-
I wouldn't be keen on random systems with the only element of 'real stars' being the idea of naming them based on order of proximity. That is almost the same as random stars. The whole point of real stars is using the actual mass and spectral class of each star and having them in the correct xy direction.
You can do better than that: just randomize positions, and assign real names and properties according to distance. This way, you get plausible distances, correct class, mass and names.
I believe you could even change the bearings to their correct value (in your 2D projection system, that is). Such random corrections would not change overall density.
To summarize, the procedure would be :
1- generate a random set of nameless, massless and classless stars, according to some prior density (controlled by game parameters)
2- sort the systems according to their distance to the sun, and associate each one with a real star, thus determining name, class and mass
3- change the bearing of those stars, to match those of their real namesakes (therefore maintaining the constellations in order, a good thing since many stars are named from their constellation)
I haven't done the maths, but I believe that so long you don't change the distances from step one, you remain in line with the original density.
Francois
-
You mean an option to take the list of system names from the real stars table in order of distance from Sol and apply them to the systems in a random map games in their order of distance from Sol?
Steve
Yeah, that.
A bit like a random map, but without crazy names.
-
You can do better than that: just randomize positions, and assign real names and properties according to distance. This way, you get plausible distances, correct class, mass and names.
I believe you could even change the bearings to their correct value (in your 2D projection system, that is). Such random corrections would not change overall density.
To summarize, the procedure would be :
1- generate a random set of nameless, massless and classless stars, according to some prior density (controlled by game parameters)
2- sort the systems according to their distance to the sun, and associate each one with a real star, thus determining name, class and mass
3- change the bearing of those stars, to match those of their real namesakes (therefore maintaining the constellations in order, a good thing since many stars are named from their constellation)
I haven't done the maths, but I believe that so long you don't change the distances from step one, you remain in line with the original density.
Francois
I like this idea. While players will be able to tell whether a system has the name of a real star, the correct number of stars, and so forth, few will be able to tell whether the stars are placed accurately on a grid. I don't see it taxing the suspension of disbelief for the vast majority of players.
-
You can do better than that: just randomize positions, and assign real names and properties according to distance. This way, you get plausible distances, correct class, mass and names.
I believe you could even change the bearings to their correct value (in your 2D projection system, that is). Such random corrections would not change overall density.
To summarize, the procedure would be :
1- generate a random set of nameless, massless and classless stars, according to some prior density (controlled by game parameters)
2- sort the systems according to their distance to the sun, and associate each one with a real star, thus determining name, class and mass
3- change the bearing of those stars, to match those of their real namesakes (therefore maintaining the constellations in order, a good thing since many stars are named from their constellation)
I haven't done the maths, but I believe that so long you don't change the distances from step one, you remain in line with the original density.
Francois
OK, I am probably missing something here :) but if I generate a random map and then assign names/star types based on distance and change the bearing to match the real one - isn't that a more complex method of achieving what I already have?
Steve
-
No, because the range from Sol will be slightly random, and some stars might be missing if the random density doesn't equal the actual density.
-
if I generate a random map and then assign names/star types based on distance and change the bearing to match the real one - isn't that a more complex method of achieving what I already have?
Not quite. Your method will keep correct bearing, type, and distance, while projecting a 3D sphere onto a 2D disk. This will increase star density by a factor proportional to the distance of the sun. It will also make systems (save Sol) closer to each other (due to the absent third dimension).
Mine keeps the type and bearing, but allows the distance to vary from the actual value (only keeping the systems sorted with respect to their distance to Sol). This way, the clustering caused by the move from 3D to 2D, and the resulting asymetry of star density (ie its increase as one moves away from Sol), are corrected. You can also adjust the density to keep distances between stars more realistic (although I don't think you can completely eliminate the "shrinking effect" due to the projection).
Note, though, that the clustering will probably be reduced if some the less bright stars are absent from the catalogue you are using. But this means that such systems should be added, or the star type distribution will be wrong (ie biased in favour of the larger/more luminous systems).
Francois
-
I think given the option between:
a) Accurate distances from Sol
b) Accurate direction from Sol
c) Higher stellar density than reality
d) Incorrect distances between stars
or
a) Order of distance correct but not absolute distance
b) Accurate direction
c) Realistic stellar density
d) Incorrect distances between stars, although a more realistic average distance.
My preference is the former, although of course this is based on my personal bias of which factors are more important. I tend to think in terms of what the average player would accept in terms of the suspension of disbelief and also how I would mention star systems in fiction. The main one for me is accurate distance followed by accurate direction, so this factor drives the method I use to generate the map. The vast majority of players wouldn't know if stellar density or distances between stars (other than Sol) is correct.
However, it may be possible to generate the alternative as well. I'll have to look at how easily it would fit into the galaxy generation.
Steve
-
I see your point. The one thing I'm wondering about is the effect the change in stellar density may have on game play. My feeling is that the 3D to 2D projection, where you 'fold' all stars over and below onto the horizon, will reduce average distances between systems*, except distances to Sol, which are kept at correct 3D values. Also, this reduction will not take place in a homogeneous way. The further you are from Sol, the more "shrinkage" you get.
In other words, the problem is less that density or distances change, but that the universe becomes "centred" around Sol, which would be further away from other systems (because it is the only star with "unshrunk" distances). In contrast, your typical NPR race, which begins the game far from Sol would almost always live in a denser area of the galaxy. This might create some imbalance, no?
But then, this certainly can be tested, by generating a large "real star" universe, and calculating some indicator like 'average distance to the nearest N stars', for a significant number of stars, and plotting it against distance to Sol.
Francois
* this is on average, of course, for two systems very close to each other right at the "top" of the sky, distance can actually be vastly increased
-
I see your point. The one thing I'm wondering about is the effect the change in stellar density may have on game play. My feeling is that the 3D to 2D projection, where you 'fold' all stars over and below onto the horizon, will reduce average distances between systems*, except distances to Sol, which are kept at correct 3D values. Also, this reduction will not take place in a homogeneous way. The further you are from Sol, the more "shrinkage" you get.
In other words, the problem is less that density or distances change, but that the universe becomes "centred" around Sol, which would be further away from other systems (because it is the only star with "unshrunk" distances). In contrast, your typical NPR race, which begins the game far from Sol would almost always live in a denser area of the galaxy. This might create some imbalance, no?
But then, this certainly can be tested, by generating a large "real star" universe, and calculating some indicator like 'average distance to the nearest N stars', for a significant number of stars, and plotting it against distance to Sol.
* this is on average, of course, for two systems very close to each other right at the "top" of the sky, distance can actually be vastly increased
I am playing a 3000 system real stars game at the moment for test purposes. Because we can't detect smaller stars at greater distances, the density remains fairly constant across the 100 LY radius. The issue becomes the decreasing number of red dwarf stars as you move outwards, although I still don't really know how significant an issue that will be long term
Steve
-
So there's more useful systems on the edges, while in turn, starting outwards will result in "reaching the border" sooner, where there is nothing left?
Well, game balance wise, that could be fine, but that'd seriously hurt my suspension of disbelief.
-
So there's more useful systems on the edges, while in turn, starting outwards will result in "reaching the border" sooner, where there is nothing left?
Well, game balance wise, that could be fine, but that'd seriously hurt my suspension of disbelief.
Well, not necessarily more useful systems. With regard to the fact that starting near the edge will mean you reach a border where there are no more stars - unless I create an infinite universe then there is always going to be an edge.
Steve
-
Well, game balance wise, that could be fine, but that'd seriously hurt my suspension of disbelief.
I don't see a problem with reaching an edge, isn't this just representative of the confines of a single galaxy with stars in the next galaxy over just being too far away to be practically reachable? I guess it's just a scale piece in that you don't have all the stars in the milky way on the map?
-
We're on much smaller scales here than galactic radius, unless I misunderstood something, we're talking of a 100 LY radius sphere around Sol, and a few thousand stars, compared to hundreds of billions in our galaxy.
Francois