For an example of what I mean by pace and a long game, the game can be set up to it takes a LONG time to go through the tech tree.  Thus even if one has fast ships and long scanning ranges, it can still take a long time to complete the game.  But the exploring and moving of ships will make it seem like a quicker game because there will be more to do on indvidual turns.

For me at least.

Others like their pace from the speed of tech research.  Thus they can set up the game so it feels faster or slower by tech research.

Hence, pace pace pace.

====

tl;dr either post:  Games with large sensor ranges and fast ships can still take a very long time to play, but they can feel quicker to the user. Thus some want that fast feel of pace of play.  No more, no less.

Honestly, I don't think anything actually needs to scale to map size. I think a lot of stuff needs to be scaled to the number of planets divided by the number of races (tech and ideology, for example), but there's little good reason for scaling anything base purely on the size of the map.

A very sparse Insane map is essentially just the same as an abundant small map once you remove all the empty squares, which is what absolute scaling would effectively do. And in that case, just play the small map. Seriously. You're just taxing your PC, breaking the AI and slowing the whole game down for yourself by including an enormous amount of empty space between the stars and then increasing engines and sensors to cancel it out. With sensors, the argument in favour of scaling is a little better... but not by much tbh, since there's better solutions which can leave everyone happy.

Frankly, I've no objection to sensor boats as a concept (they're actually realistic), they were just massively overpowered at what they did. They needed toning down a bit but I don't see much problem with fully-decked out huge sensor boats having a sight radius of 50 or 75+ tiles; it's when a basic cargo hull can be put together that reveals half an insane map on turn two that there's a big problem. I think a small diminishing return on radius bonus (say -10% per module), or a slight hull space % cost (like engines) would be better answers than this new system really, since then we can still make long-range AWAAC-type units capable of watching a whole flank, but just not ones that can see more than the whole universe on all map sizes.

If you want a -X% sensor range per component system, you may as well impose a flat limit on the number of sensor components you can add to the ship and forget about the stacking penalty. The way that the stacking mechanics work, if you have a base sensor range of k, a percentile sensor bonus of c from sources other than sensor components, and a sensor component which provides a flat bonus of b and a percentile bonus of s to sensor range, the resulting sensor range for a vessel with n such components is

R(n) = (k + b * n) * (1 + c + s * n)

which for s < 0 has a maximum at

n = -(k * s + b + b * c) / (2 * b * s)

For b >> k, s = -0.1, and c = 0, that means that there is no reason to add more than 5 sensor components, as the fifth sensor component is the last sensor component that can possibly increase the ship's sensor range; components beyond that begin to reduce the vessel's sensor range, though the rounding of the computed range to an integer can conceal that for a few components (that rounding, however, can also mean that additional components cease to be useful before reaching the computed maximum useful number of components; for example, with b = 1, k = 2, c = 0, and s = -0.1, there is no point to adding more than 2 sensor components as the second sensor component brings the vessel to its maximum effective sensor range of 4).

I would also expect that there would be issues with communicating to the player what kind of benefit to expect from a technology which provides +Y% to sensor range. Using the parenthetical example and changing c from 0 to 0.1, the effective sensor range of a vessel with 2 sensor components does not change, and adding a third sensor to the vessel also does not improve the effective sensor range, which might lead the player to believe that the tech was worthless. A fourth sensor component, however, would allow the ship to attain its new maximum effective sensor range of 5, though the minimum sensor suite needed to achieve this costs twice what the minimum sensor suite needed for the maximum effective sensor range prior to the development of the tech needed, which leads one to question whether that +10% sensor range tech was worth much of anything.

Ok, so I only play on Insane maps. I play with RARE habitable planets and I play with A LOT of races. As a poster above state just play on smaller maps. Uh, no. Play 50 races, abundant minors abundant stars and planets but make your hab ones RARE and you will find a much different game. Having things like sensors, engines and life support scale to map size will give you the same pacing on a small/medium as here on Insane.  There has been a lot of discussion on having some things tied to map scaling. I am all for it. 

Research should be as Naselus mentions which should be tied to number of hab planets on map creation. Only got 200 planets on the entire map? Well you are going to take a loooooong time to get stuff done, especially if you have 30 majors and 25 minors. 

Pretty much, yes.

There's a maximum sensor range which the game's mechanics can handle properly. Once you figure that out, ensure that the biggest hull with all the bonus space techs loaded down with sensors has THAT sensor range, and then make everything else a percentage of that. Problem is, a huge hull with all max-tech sensors on it has a vast range; so vast that you can't make it into a sensibly-sized portion of the map without making early-sensor small ships essentially blind without basically saying at some point that sensors don't have any further positive effect.

A flat cap of X would work for that, so would a diminishing return (not necessarily just -10% ship-wide sensor range per sensor, as the previous system allowed for - it could be that each NEW sensor is 10% weaker than the last, so 1 sensor has 100%, sensor output, 2 sensors 190%, 3 sensors 271%, 4 sensors 344% etc).

To be honest, if you scale exactly (i.e., map 10 times as big, movement multiplied by 10) then it's not the same pacing. It's just the same game. The only difference is lots of empty space and dead planets, which may as well not exist because you've increased the move speed to travel across it just as quickly and the sensor radius to see just as far. You really may as well just play on the smaller map, otherwise a bigger map is basically just a way of benchmarking your PC rather than a different gameplay experience. The game will populate the races and minors in addition to the rare planets regardless, so really you're not changing much between, say, large and insane - you just get like 2 more minors and a more or less equal % of additional planets.

Map size really ought to have nothing scaled off it at all. I could see an argument in favour of scaling speed on the Game Pacing setting (so on fast everything is 3 times faster than on normal). Not from the map itself. though, and certainly not with massive and draconian reductions in engine speed and sensor strength (otherwise we'd be straight back to the start with all the problems caused by having very very fast ships or very very long-range sensors).

Not to hab planets - to #of habs divided by # of races. 200 planets with just 2 races will tech a lot quicker than the exact same map with 50 races.

You can adjust sensor components so that you can make early-game ships which have a reasonable sensor range without allowing late-game ships to have enormous sensor ranges without making it so that there is a point where additional sensor components cease to be beneficial. For example, consider a set of sensor components which all provide +2 range per component and have a base cost of 10 capacity. The basic version you get at the start of the game has a stacking penalty of +30% capacity required per component, which is reduced by 5% with each new generation of components (so 25% for the second-generation sensor component, 20% for the third generation, 15% for the fourth generation, and 10% for the fifth and final generation). An early-game Cargo hull with 90 capacity can fit 4 first-generation sensors for a total sensor range of 10, a late-game Huge hull with 500 capacity can fit 17 fifth-generation sensors for a total sensor range of 36. Even a ship with 1000 hull capacity is only going to be able to fit 27 of the fifth-generation sensors despite having a minimum of +300% hull capacity (you can get +70% from the tech tree, another +20% from empire design, perhaps another 70% from a Hyperion Shrinker, so that's a lot of events and Helios Ore). Even with the full -60% sensor component size you can get from technology, that only increases the number of fifth-generation sensor components which fit into 500 capacity from 17 to 20, for 42 sensor range instead of 36.

You can play with the numbers to adjust the upper and lower limits, but in my opinion a sensor range of 36-42 on a ship that spends virtually all of its 500 hull capacity on sensor components is not excessive, certainly not at the point in the game where you have +100% hull capacity and Huge hulls (required for 500-capacity hulls) and fifth-generation (i.e. max-tech) sensors. Nor do I feel that a sensor range of about 10 is unreasonable for an early-game sensor ship that spends almost all of its 90 hull capacity on sensors. Limit the sensor range multipliers to something reasonable (or get rid of them and make the things that offered such do something else instead) and you're good to go.

This method also makes it so that there's still a significant trade-off between going all-out on sensor capabilities and having additional drive or travel range components, whereas there's a good chance that a system which has a hard limit on the maximum useful number of sensor components will, especially later on in the game, leave ships which have the maximum attainable sensor ranges with plenty of available hull capacity for other components.

I am not asking for a scaling like that. You mention its the same with just waste space and that is NOT the case. Density. You cannot say an insane map which has scaling would feel the same as a tiny map with scaling with 50 races. There would be breathing space there. 

So a hyperdrive on Small moves you 4 hexes, each map size up would feel better if you move +2 hexes per size increase, or +1. the thought here is moving 4 hexes on a tiny map feels faster than moving 4 hexes on an Insane map and that is because of planet/star/race density. You can only cram so much onto a tiny map, where as on Insane I can comfortably put 15 races and have LOTs of room to expand,explore and exploit. 

Perhaps I am not asking for full scaling but rather a compromise which increases the components based on map size to give your game pacing a better feel. 

What Naselus is saying is that if you double the galaxy size but also double the movement speed and sensor range, you just came back to where you started. It's the same game as the half-sized map. all other content being equal.

I'm of the opinion that large maps should present the vastness of space itself as an obstacle. It should take forever to explore and to travel. Having a "fast paced large galaxy" is sort of an oxymoron to me. Pick the Insane map if you want a 3-month campaign. Pick the small map if you want to finish over the weekend.

It is almost laughable how fast research and wealth build up on a  huge or bigger map.

I can actually, since that 'breathing space' is not really there because the ships have been sped up. It's an illusion. The additional empty space mostly might as well not exist once you reach a certain map size. And since once you have anything over about 30 races, even an insane map seems determined to dump races on each other's doorstep, you still end up lumped together anyway.

Think of, say, a WW2 game. Regardless of if you're playing a scenario which covers the whole Eastern front or just the area around Leningrad, you still want the units to move at the same rate. The map is much bigger for the Eastern Front map, but the units are still the same scale compared to the landscape around them.  If I'm playing the Eastern Front, then I don't expect my tanks to suddenly be able to move at 500mph. 

The same applies here. Even the smaller adjustment you're asking for is asking for a T-34 to suddenly be 50% faster than it should.

Or just adjust the effect of the 'game pacing' option rather than the map.

Seriously, there's no good justification for changing pace by scaling speed to map size when you could instead adjust it separately on a game option that is literally named after the thing you want to change. Since the current implementation of game pacing is ineffectual to the point of near-uselessness, this might be a less controversial suggestion that map-based scaling. Some of us are entirely happy with very big maps that play slowly, whereas more or less everyone agrees that the game pacing and research pacing options are basically pointless in their current incarnation (especially the research one, tbh). If you want 500mph tanks (or 10mph tanks, for that matter), then that's the right place to do it.

The cases where scaling based off of the map IS worthwhile (research speed; ideology accumulation; probably cash generation too), the actual hex count is pretty much irrelevant and it's more about the contents (number of planets vs number of races). Just about the only thing which would be better off scaling to the size of the map is the AI itself, which becomes increasingly poor the larger the map is precisely because it still thinks it's playing on Medium for most purposes (production, economic strategy switching, research choices etc).

I for one think the sensor 'fix' was a great one. Sensors now work more like they did in GalCiv 2. I can still make my late game, 40 hex radius scouts, just not first thing in the game.

Agreed. I play only Insane maps and Slow tech, and I find the pacing to be a huge deal in large games. For the record, I think the game pacing works pretty well.