Can there be more information on this:
"So we’re adding hexes, because they make better maps"
In GC2, there was no "unit" region. I actually liked this more than how Civilizations has it structured into finite cells. Thanks for listening.
Not that it really matters, but how do sectors tessellate if a hexagon made of hexagons doesn't have six sides?
Stsrbound_Dust, what you show here would force a great deal of sector overlap between adjacent sectors. It would make a lot of the mathematical aspects of the game difficult, especially of the "what sector am I in" kind.
That being said, the only way I can envision sectors of hexes is as a hex of hexes. After drawing some diagrams on paper it looks to me that a sector with a radius of 12 hex tiles is not a reasonable way to describe the size of a sector. I was unable to draw a regular hexagon containing either a radius or diameter of an even number of regular hexagons. Therefore, the diameter of a sector will always have to be an odd number of hex tiles, and the radius would have to include only half of the center tile.
I think the galaxy map's sector sizes will be best expressed as the number of hexes on a side. This can be done without any resulting overlap between sectors, and should reduce the confusion experienced by the game players. I also think it would make most (definitely not all) of the calculations the programmers must make easier.
*****************************************
Well, while I was typing up this reply, it appears that Starbound_dust edited his post, completely changing the diagram of a sector he had.
OK, so theoretically, a tiny map, would look something like this, not that i would know.
Okay, now everything makes sense. Thank you, mormegil!
Do you know offhand the formula for calculating the number of parsecs in a sector, given the number of parsecs along one side?
I realised I was being an idiot I was seeing things more complicated than they should have been. My mind works differently from most peoples, heh
Isn't that true of all of us???
Well they are building it in 64 bit which will help in processing power. Also Gal Civ II was one of the few games to utilize threads and I imagine Brad will do the same codewise since today's average technology has at a minimum of 2 threads if not 4 and upwards to 12 or even 16. This allows if I am understanding correctly the processors to 'think' in parallel (4/6/or 12 threads) so we should be ok with Titanic maps ( I hope).
Ack! What happened to the nice, useful squarey sectors?!?
They were executed for being a horrible idea.
Don't do anything to get in trouble... Then again, keep posting stuff.
3r^2 - 3r + 1
RIP dear squares ....... we knew you well
Ignore this. REALLY, REALLY dumb question haha.
I hope there will be some semblance of motion in x,y,z i.e. SPACE, although layers of 2D like in the 3-dimensional chess post would be acceptable. I will feel sick if it turns out to be 3d objects moving around on a tabletop universe...
Have you taken a look at the screenshot yet?
No I had not seen it in that much detail, so thank you. It looks like a table-top, but only because of the sheet of hexes. The hexes are what made me assume it's 3D because otherwise it would be too easy to blockade. There are some interesting buttons next to the mini-map in top right and I'm sure at least one of them accesses planes above and below the one projected on the main screen. It has to be 3D, right? I can't comprehend 4X in space without a z-axis.
No, the GalCiv games always used a 2D map. You can see some comparison screenshots here.
I prefer a hex grid over a square one. What I have a problem with is why does a Star and a planet/ship both take up only one hex? A star is much larger like a hundred thousand times or more. The Star should take up more hexes to be more realistic.
If you go back and read the GC2 manual (I think that is where it is mentioned) they hand-wave that away with the concept that 1 square (hex) is the distance that an unmodified ship can travel in 1 time unit. Out in the middle of nowhere with no local gravitational influences, this distance is very large. But as you get closer to stars/planets, the distance you can travel per time unit shrinks due to the gravity effect on the star drive.
I still prefer to play on sparse / dense cluster maps where there are large areas of open space between star systems. I'm fine with the "local" topography being flat with planets / stars taking up 1 tile and very little space between them, but I don't like the entire playing field to be that flat.
Because the map is an abstraction of what's going on and not a satellite view. If it were realistically sized, smaller ships would be so tiny that you wouldn't be able to see them.
According to this game's lore, nearby mass slows down hyperdrives. In this context, mass is the same as distance. As such, an empty tile far from a solar system might be light years across, while a planet might have a radius measured in thousands of km and occupy a single tile. Because the a planet would have a greater mass than empty space light years across, its mass effectively makes the volume it occupies to function like a tile as big as the other tile, despite occupying far less volume. Because of the local mass, traveling an entire solar system might take several to many turns, even though the entire distance would be less than a light year.As such, the speed of hyperdrive varies. Some times it is faster than light, other times it is slower than light. Really, the tiles don't measure distance; they measure the time needed to travel the distance, measurements compared to some hyperdrive rating.
There are many great features available to you once you register, including:
Sign in or Create Account
