Aurora 4x
VB6 Aurora => Aurora Suggestions => Topic started by: Steve Walmsley on July 20, 2015, 05:57:54 PM
-
I've haven't played for a while due to finding out about X-COM Long War :)
It will take me a while to get back into the Rigellian Chronicles so I'm playing around with a campaign idea at the moment that involves setting up a lot of systems (50-100) and then populating them with a variety of different human colonies (like 2300AD if anyone remembers that). No NPRs - just human empires, plus maybe a major alien race that I would play. Essentially a no AI campaign apart from perhaps spoilers.
As part of that that I just generated 75 systems as a potential start-up universe. It was surprising just how many had a lot of jump points. Due to getting a 2300AD feel, I really want a campaign with fewer JPs per system (with subsequently fewer systems close to Sol) and was considering making it a little harder to get beyond 2-4 JPs per system. I could make it optional but I am interested in opinions as to whether the current JP generation is too much and I should cut down the default numbers (probably by making the cap much more dependent on star mass than currently so large numbers of JPs are much rarer)
Any opinions?
-
It's fun and a nice challenge to deal with an occasional system with a large number of JP's but it is a pain when you have a few systems in your empire with 8+, particularly if they are adjoining systems. To be honest it might be fun if the quantity of JP's had a tie in with the colony cost of the system bodies or maybe overall mineral concentrations. 8 JP's in a system no one cares about is one thing, but in a system with high desirability it makes it worth the additional difficulty to manage.
-
I too think that the current generation goes a bit overboard. In my current game I have discovered maybe somewhat over 50 systems, and quite a few of them turned out to house even 8 jump points. I end up trying to ignore those nodes as dead ends, because making so many links make sense on the galaxy map to maintain oversight becomes really difficult to do. It is also frightening in general to end not on a T-intersection, or a crossroad, but have so many directions open that you have to "work through" before you feel you have really progressed one jump more away from home. There is some style to it if it happens once in a while, so you have some sort of space-hub-anomaly system, but in praxis it seems that every 10th is already that bulky (judging by my this one recent game of mine), and every 4th or so at least exceeds the 4 JP margin.
So I would definitely like to see some curve or so that makes systems over 4 Jps maybe exponentially more unlikely, yet not impossible, - or just something in that direction.
-
I would prefer this to be optional, though I agree with others in that JP amount goes a little overboard now. I want a choice between "too many" and "too few".
-
I agree, the excess of jump points usually drags my games down heavily, an option might be great but perhaps a small tweak might be sufficient , but also maybe an option for seriously limited jump points.
An alternative might be to limit jump points heavily, then have a late-tier technology which allows fallow jump points to be re-explored with perhaps a high chance of connecting to already-explored systems.
-
I will add my agreement to this as well, hitting several systems in a row with 6 or 7 jump points makes managing the map a real pain.
-
I'd definitely prefer fewer jump points per system.
-
It sounds like we have a consensus that the current generation code creates too many JPs. Here is the pseudo-code for what I propose as the new standard.
NumberJP = 1
BaseJPChance = 90
Do While True
JPChance = Int(BaseJPChance + PrimaryMass)
If JPChance > 90 Then JPChance = 90
If RandomNumber(100) > JPChance Then Exit Do
NumberJP = NumberJP + 1
If BaseJPChance = 40 Then BaseJPChance = 30
If BaseJPChance = 60 Then BaseJPChance = 40
If BaseJPChance = 90 Then BaseJPChance = 60
Loop
This will produce the following proportions of systems assuming mass of 0.99 or less
1 JP: 10%
2 JPs: 36%
3 JPs: 32.4%
4 JPs: 15.12%
5 JPs: 4.54%
6 JPs: 1.36%
7 or more: 0.58%
For a star with a mass of 5 the proportion would be:
1 JP: 10%
2 JPs: 31.5%
3 JPs: 26.33%
4 JPs: 17.7%
5 JPs: 9.41%
6 JPs: 3.29%
7 or more: 1.77%
For a star with a mass of 10 the proportion would be:
1 JP: 10%
2 JPs: 27%
3 JPs: 25.2%
4 JPs: 18.9%
5 JPs: 11.34%
6 JPs: 4.54%
7 or more: 3.02%
As you can see, higher mass stars make a significant difference in terms of systems with 5 or more JPs. In fact, an optional rule for more JPs would be to assume a minimum star mass for JP generation only. How does this sound?
BTW the reason for the low (10%) chance of no JPs is because with fewer JPs in general, dead-ends are more of an issue.
-
Here is an example of JP generation using the proposed formula. I have generated systems until I am at least five transits out in all directions. As you can see, there are still a few junctions but much less than before. Chains of system are much more common. This is more like the type of map I had in mind for a 2300 AD campaign. If anything, I would trim the 4+ down a little more but this is a very small sample size.
(http://www.pentarch.org/steve/Screenshots/GenerationTest.PNG)
-
(like 2300AD if anyone remembers that).
Just vaguely :)
-
That's looking pretty good to me, even if it is just a small sample.
Will be interesting to see what that does for player rates of expansion and how much more of a shift into fuel production and management it will require. I suspect that will mean more of a trade off in fuel efficient engines v speed compared to current games.
I also wonder if slightly speeding up JP surveys would be an idea to help balanced the increased transit times for survey ships.
-
This is a second test with a slight change to the generation chances. It moves a little % to 3 JP from 4+ JP. Here is old vs new proportions:
OLD
1 JP: 10%
2 JPs: 36%
3 JPs: 32.4%
4 JPs: 15.12%
5 JPs: 4.54%
6 JPs: 1.36%
7 or more: 0.58%
NEW
1 JP: 10%
2 JPs: 36%
3 JPs: 37.8%
4 JPs: 11.34%
5 JPs: 3.40%
6 JPs: 1.02%
7 or more: 0.44%
So now we have about 1 system in 9 (for stars with 0.99 mass or smaller) with 4 JPs and 1 in 20 with 5 or more JPs. Almost three quarters will be 2 or 3 JPs. Junction systems will actually work out a little higher than that because of the higher mass stars making a significant difference at 4+. This feels better than the first version but again it is quite a small sample size. Here is a map generated under those rules:
(http://www.pentarch.org/steve/Screenshots/GenerationTest2.PNG)
-
That's looking pretty good to me, even if it is just a small sample.
Will be interesting to see what that does for player rates of expansion and how much more of a shift into fuel production and management it will require. I suspect that will mean more of a trade off in fuel efficient engines v speed compared to current games.
I also wonder if slightly speeding up JP surveys would be an idea to help balanced the increased transit times for survey ships.
I think this will make the logistical side of the game more interesting as you will have to mount quite long-range expeditions, both for surveying and combat operations. Tanker support and forward bases will be more useful and fuel will become even more of an issue. More industrial output will probably be needed for the tail vs. the teeth. We'll see how it goes but perhaps more logistical-based techs, or making the existing ones cheaper, could be an option. Maybe also cheaper maintenance facilities as you are likely to need more bases.
-
Or -- you could just make people deal with it since it isn't that problematic to begin with(logistics in general) :).
I've haven't played for a while due to finding out about X-COM Long War :)
A wise man you are. I love Aurora but the only thing stopping me from really getting going on setting up my next campaign has been getting caught up on an interactive Long War dynasty I'm running on another forum.
-
I think this will make the logistical side of the game more interesting as you will have to mount quite long-range expeditions, both for surveying and combat operations. Tanker support and forward bases will be more useful and fuel will become even more of an issue. More industrial output will probably be needed for the tail vs. the teeth. We'll see how it goes but perhaps more logistical-based techs, or making the existing ones cheaper, could be an option. Maybe also cheaper maintenance facilities as you are likely to need more bases.
Even in JP-rich environment I still had designs which could fly for dozens of years. I doubt my logistical needs will get larger than that.
I both like (easier to defend chokepoints, easier to sort the map out) and don't like (it feels like tunnels) this. And I still want a choice between that and old variant if possible.
-
(https://i.imgflip.com/oirv5.jpg)
-
I like the idea of fewer jump points. In my current game, real stars, 177 systems surveyed, 18.6% have one jump point, 25.4% have two jump points, 22.6% have three jump points, 15.2% have four jump points, and 18% have greater than four jump points, (the maximum being 18!).
My only other comment is that if you start with multiple NPR empires on Earth then while you can usually beat them to the first ring out from Sol, the second and third are very difficult to get to first with the current fuel usage rules. But under the existing jump point generation rules they usually leave sufficient unexplored chains for you to go down. Once you reach fuel consumption 0.4 litre per engine power hour you are back to parity. The NPRs should have some restriction on fuel/range with a multiple Earth start.
-
The new distribution is great, and exactly what I had wished it would be like. The newer distribution seems better too, as I feel 3 JP chances should still slightly outweigh 2 JP ones. Then I especially like the interesting influence that mass has in the whole deal. Seems black holes have some chance of becoming big galactic terminals now each time? 8)
-
This is a second test with a slight change to the generation chances. It moves a little % to 3 JP from 4+ JP. Here is old vs new proportions:
OLD
1 JP: 10%
2 JPs: 36%
3 JPs: 32.4%
4 JPs: 15.12%
5 JPs: 4.54%
6 JPs: 1.36%
7 or more: 0.58%
NEW
1 JP: 10%
2 JPs: 36%
3 JPs: 37.8%
4 JPs: 11.34%
5 JPs: 3.40%
6 JPs: 1.02%
7 or more: 0.44%
So now we have about 1 system in 9 (for stars with 0.99 mass or smaller) with 4 JPs and 1 in 20 with 5 or more JPs. Almost three quarters will be 2 or 3 JPs. Junction systems will actually work out a little higher than that because of the higher mass stars making a significant difference at 4+. This feels better than the first version but again it is quite a small sample size. Here is a map generated under those rules:
What was the maximum number of systems in your test galaxy? I ask because I tried to setup a similar scenario via SM mode exploration in a galaxy with 250 systems and I found that after around ~120 systems were explored, jump points would frequently link to an already explored system. These "dormant" links will increase the number of jump points in a system and I don't think that they are accounted for in your probability table.
-
This change is for initial JPs, not including dormant ones. The main change here is a curbing of massive JP amounts per star.
And that you get a lot of link back to explored systems is a given with a maximum of 250 systems. That's simply how the assignment algorithm works. (Which is basically just a random roll for the system ID, with a chance that the target ID is close to the ID of the orginal system.) So you get a lot of links to known systems because you already know half of the total galaxy.
-
Steve, did you ever see this one?
(https://i.imgur.com/EZmBcYg.png)
https://www.reddit.com/r/aurora/comments/3byjmq/87_systems_and_i_havent_reached_4_jumps_from_sol/
-
What was the maximum number of systems in your test galaxy? I ask because I tried to setup a similar scenario via SM mode exploration in a galaxy with 250 systems and I found that after around ~120 systems were explored, jump points would frequently link to an already explored system. These "dormant" links will increase the number of jump points in a system and I don't think that they are accounted for in your probability table.
It was real stars so there was no universe size.
I agree about dormant JPs changing the distribution. In real stars, there is a 5% chance that a JP will link to an existing system. However, if the system being connected to has unlinked JPs, one of those will be used rather than creating a new one, so the actual variation due to dormant JPs will vary from game to game.
-
Steve, did you ever see this one?
(https://i.imgur.com/EZmBcYg.png)
https://www.reddit.com/r/aurora/comments/3byjmq/87_systems_and_i_havent_reached_4_jumps_from_sol/
Technically, a couple of those systems are 4 jumps from Sol.
Technically correct. The best kind of correct. :D
-
The full title is "4 jumps from Sol in all branches."
And I think there was one 5 jump-out explored somewhere in there too.
I ended up saving it and restarting, because managing the map was becoming a bit difficult...
-
I had 1 game where i set sol to have 4 (good average number) 1j in 3 directions netted me systems with 1,5,6,6 and from 1 of them in the 5, i found an 8
So making it a little more tame might be nice, especially on bloat. 3-4 per system is a lot less by the 3rd jump than 5-6 per.
Though I am curious, i dunno code or even psuedo code. But is that a limit on the max? Could you possibly jump into a system with 15 jps?
-
I had 1 game where i set sol to have 4 (good average number) 1j in 3 directions netted me systems with 1,5,6,6 and from 1 of them in the 5, i found an 8
So making it a little more tame might be nice, especially on bloat. 3-4 per system is a lot less by the 3rd jump than 5-6 per.
Though I am curious, i dunno code or even psuedo code. But is that a limit on the max? Could you possibly jump into a system with 15 jps?
Yes - it is very unlikely though. Rather than having set % for the number of JPs the code adds them one at a time, with a chance for each subsequent JPs. So (under new rules) 100% for first, 90% for second, 60% for 3rd and then 30% each for any additional JP. So the chance of getting 2+ JPs is 90%, the chance of 3+ is 54% (90% x 60%), the chance of 4+ is 16.2% (90% x 60% x 30%), etc.. The chance of getting a specific number of jump points, such as 3, is equal to the chance of getting that far minus the chance of getting further. For 3 that would be 54% - 16.2% = 37.8%.
-
Technically correct. The best kind of correct. :D
The ONLY kind of correct.
FTFY!!
;D
Actually Steve what about (carrying the 2300 theme a little further) setting a maximum distance a JP can connect to, so you could implement the 7.7 ly range that 2300 uses
-
The ONLY kind of correct.
FTFY!!
;D
Actually Steve what about (carrying the 2300 theme a little further) setting a maximum distance a JP can connect to, so you could implement the 7.7 ly range that 2300 uses
That is actually possible with real stars because Aurora has 3D coordinates for each system in real space (converting right ascension and declination into 3D coordinates was fun :) ). Currently the JP link code creates a list of other systems in ascending order of distance then checks each one in turn with a 20% chance to select that system. I guess I could limit the list to those within 7.7 LY and then loop back to the start :)
-
That is actually possible with real stars because Aurora has 3D coordinates for each system in real space (converting right ascension and declination into 3D coordinates was fun :) ). Currently the JP link code creates a list of other systems in ascending order of distance then checks each one in turn with a 20% chance to select that system. I guess I could limit the list to those within 7.7 LY and then loop back to the start :)
Any chance that # could be configured at creation?
-
This is looking very good to me. There is just one small thing I'd like to add: with this and the significant increase in useless systems (due to your inclusion of massive amounts of brown dwarfs few patches back) you may want to rethink civilian shipping distances. Currently, if my memory serves, a civilian vessel will look for a destination only four jumps away, which is a little short at the moment, at least in my opinion. But that's just a small issue.
-
I would be interested in an option to force a star system, maybe only the starting star system, to have a larger number of JPs. Specifically to accommodate multi-faction starts in a single star system.
-
I would be interested in an option to force a star system, maybe only the starting star system, to have a larger number of JPs. Specifically to accommodate multi-faction starts in a single star system.
You can set the number of JPs in Sol during game creation. You can also use Add JP in SM Mode to create additional JPs in any system.
-
This is looking very good to me. There is just one small thing I'd like to add: with this and the significant increase in useless systems (due to your inclusion of massive amounts of brown dwarfs few patches back) you may want to rethink civilian shipping distances. Currently, if my memory serves, a civilian vessel will look for a destination only four jumps away, which is a little short at the moment, at least in my opinion. But that's just a small issue.
Since the limit is due to algorithmic complexity, this could partially be solved by considering all the systems along a warp chain of systems with only 2 WP each to be the "same" system for purposes of route planning. Or this might come naturally out of the algorithm.
This has the downside that if another jump point appears in a chain (e.g. from a closed jump point), then your civie "trade route" can disappear.
One way to avoid this: allow players to specify multi-system warp chain "trade routes" (as a list of systems) that Aurora would use as "1-hop connections" when calculating routes. Then such a 2-jump chain could be specified as a trade route and even if it were broken the civies wouldn't get confused.
John
-
Another mechanical consequence for trimming down jump points is the value of Sector Commands. They aren't cheap, and extending their influence to further and further systems requires exponentially higher numbers of them. If the average number of jump points is reduced, so is the return on investment for SecComs. I don't necessarily object to this revaluation, but it bears mentioning.
-
Deviation from the original topic a little bit, but I guess in the same vein. Longer and longer chains of systems with higher quantities of them now being barren dwarf systems is going to make civilian shipping a bit less productive. The idea of designating shipping lanes for civilians to use (that are capped due to propulsion range and not the number of jumps) would be amazing.
-
Deviation from the original topic a little bit, but I guess in the same vein. Longer and longer chains of systems with higher quantities of them now being barren dwarf systems is going to make civilian shipping a bit less productive. The idea of designating shipping lanes for civilians to use (that are capped due to propulsion range and not the number of jumps) would be amazing.
Doesn't SM mode already allow you to add new JP's in systems with a choice on where they lead? Rather than complex coding you can simply add in a bypass that offers a short cut and call it a civillian highway etc.
-
another option would be the creation of civilian transshipment stations, with the capability of organically acting as a trade waypoint by virtue of stockpiling excess goods.
-
Doesn't SM mode already allow you to add new JP's in systems with a choice on where they lead? Rather than complex coding you can simply add in a bypass that offers a short cut and call it a civillian highway etc.
In theory that would function but it is an awfully ugly solution and would produce lots of unintended side effects. One of them being computer controlled craft using that same JP. By using that method to work around the 4 jump limit to make a civilian highway between an outlying colony and your home system you have also just created an open backdoor for a hostile craft to jump right into your home system.
Making some sort of civilian way-point or designating two points as being a defined trade route would be a much smoother solution and allow for substantially spread out empires to still be functional. With the current system generation setup and a new less-jp generation rate I can envision universes being generated where I might need to make more jumps than civilians can navigate before finding suitable colonizing real estate. This wouldn't be a huge problem but there is a lack of support for deep space stations that civilians can interact with. If there was a functioning mechanic where I could build a station 2 jumps out and have it be a place that could grow enough to found it's own shipping lines out of that station it could work.
-
The civilian shipping is a whole other issue, but I'd like to see it less productive as I think it's way too productive as it is. I realize that this is really a matter of taste concept.
-
The issues surrounding shipping line wealth generation are complex, but the really out of control wealth generation mostly revolves around extremely short turn-around runs like Earth-Luna or Earth-Mars. I don't believe long range trade routes to be a particular issue in that regard.
-
The issues surrounding shipping line wealth generation are complex, but the really out of control wealth generation mostly revolves around extremely short turn-around runs like Earth-Luna or Earth-Mars. I don't believe long range trade routes to be a particular issue in that regard.
Yes, I agree. I might reduce the benefit of in-system runs. Need to look at it in more detail.
-
I thought about that there could be some sort of timer to a civil ship (or just a note that specifies when it was loaded). With this it could be introduced that a ship's contents are worth more the longer it stayed underway, thus naturally creating fairness between long and short distance trade. It also makes sense from the realistic perspective, as goods from distant worlds should be more rare exactly because of the more costly shipment, thus increasing in value. Faster ships would reduce the prices later on, just as it goes when logistic becomes easier, more competitive and wares more readily available.(bananas were exotic once too)
An alternative (or upgrade) could be to just start counting the fuel that a ship would have lost by transporting the goods, if that is even in the realm of possibilities for civilians. The result of that would however be even more logical to be a base of pricing, and would only drop prices with fuel efficiency tech or larger engines(/ships) of course. ...It would also be more calculation I presume. The first method would only make a time stamp on loading, and then do the 1 calculation on unload to determine final value of goods by comparing to the time passed 'now vs. time stamp'.
However, a system like this would just make the returns more fair, but solving how civilians even decide on trade routes is another and surely more complicated issue.
-
Yes, I agree. I might reduce the benefit of in-system runs. Need to look at it in more detail.
The root cause is a constant reward regardless of distance. IMO the only way to fix it properly is to scale traderoute income with distance * cargo.
The reason you want to use distance rather then time is because this gives an advantage to fast new designs. In reality a shorter traveltime would rather cost an extra premium, not the other way around.
-
The root cause is a constant reward regardless of distance. IMO the only way to fix it properly is to scale traderoute income with distance * cargo.
The reason you want to use distance rather then time is because this gives an advantage to fast new designs. In reality a shorter traveltime would rather cost an extra premium, not the other way around.
And the revenue (or score) should probably prefer longer trips, i.e be faster than "proportional to". In "reality" this would show up in load/unload time, i.e. revenue = rate*distance - fixed_cost_per_trip_due_load_unload. In practice (game mechanics) it would probably be easier to scale with a soft exponent, e.g. revenue - rate*distance^(1.1). The former would severely impact the current revenue from the earth/mars run; the latter would simply prefer longer routes.
John
-
The root cause is a constant reward regardless of distance. IMO the only way to fix it properly is to scale traderoute income with distance * cargo.
The reason you want to use distance rather then time is because this gives an advantage to fast new designs. In reality a shorter traveltime would rather cost an extra premium, not the other way around.
I thought about distance instead of time or fuel as well, but aside from being surely more difficult to determine in a system where civils already are the calculation hog nr.1 already, I dismissed the idea because distance is an illusionary since relative price factor.
I see it like this: 200 years ago, shipping some nice clothes or sweets that you wanted from US to Europe would have cost a lot, and they would still arrive slowly. Shipping technology advanced beyond the sail eventually, and transportation cost went down.(of course as secondary factor also due to tighter logistic networks) However, we can of course still get a fast delivery for more money (like airmail), but is that really because of technology advance? No, not really, still more or less same fossil ovens, yet it costs more because of the less efficient transportation (fuel/energy expense per weight unit) or having to act outside of established supply lines.(personal taxi at 10 is more expensive than 9 O'clock train)
If technology were to advance to give us say personal around-the-world jet/vtol drone delivery with a cheap as hell He3 fusion motor, transportation cost would not go up, but instead shrink even further. In an eventual extreme, a star trek transporter system would probably cost you a stamp mark worth of electricity in the end.(..and this is true even if we had it between planets and stars)
So the point is that, yes, within the realm of your current technology level faster transportation will cost extra, as a faster "ship" or whatever will use less efficient engines, or you need to charter(or build in aurora) a special clipper for an outside of routine job.
Space and distance are relative though, and if your means to get around become more efficient (and at the same time sometimes faster), the expenses of shipping fall down as well, so as long as there is competition on the market, that will push providers to attract with lower prices eventually, if not immediately.( as a "sell-point" of the new technology for example. the flyPhone! faster than your old hauler and microwave oven combined, and can be located via galactic-positioning-system at all times!)
Faster transportation technology virtually 'shrinks' the world around you, and with that all kind of things happen:
1 - highest possible delay of ware supply decreasing (mitigating the "readiness" price component of rare wares)
2 - better reaction time ensures that business can make more secure deals (reducing the "risk" price component. Risk is not really pirates, but actually more inherent long term investment danger since long delays between request and delivery might mean you will be beaten to it. What you do is usually you factor in some sort of self insurance each time, - otherwise you are just gambling on your luck.)
3 - if it is also more fuel efficient, you might actually save on energy, which is probably the base factor to the whole transport cost equation
? - ...possibly more things I can't think of right now
So in some cases the 3rd point's price increase (less efficient engine) might override the advantage of the two speed advantages, which creates these fast "taxis" that might be situationally useful at some point, but wont evolutionary survive on the mainstream market.
An advance in technology is therefore made if that doesn't happen, so if you get at least a price of d1+d2+d3<0, you have found a cheaper way to do it despite being faster.
...Which means the economic returns of transportation tax go down as technology advances. :P
...Consequently also meaning that time and fuel are the actual influencing factors, as distance is only a influence, but what really counts is how fast+cheap you can cross it.
-
//Double Post, sorry
I wrote so much, but here is a far easier to understand disproof of distance as the governing pricing factor:
If time or fuel don't matter and you get a fixed reward whenever you finish a freighting trip, then the fastest ship will be the best, because 'more finished trips per [time]'.
-> Hence, a hauler with fighter engines would be the most optimal choice, because it is definitely the fastest, even though it burns through millions of liters of fuel on the way.
Of course this is not how the real market could work.
-
//Double Post, sorry
I wrote so much, but here is a far easier to understand disproof of distance as the governing pricing factor:
If time or fuel don't matter and you get a fixed reward whenever you finish a freighting trip, then the fastest ship will be the best, because 'more finished trips per [time]'.
-> Hence, a hauler with fighter engines would be the most optimal choice, because it is definitely the fastest, even though it burns through millions of liters of fuel on the way.
Of course this is not how the real market could work.
Sounds like a good argument for distance and against time.
Because if in the future fuel costs are added distance works perfectly but time dont. You dont pay 10 times more for a shipping that takes 10 times longer to do the same work. It's common sense.
It's also desirable for higher tech designs to earn more even in the current model without fuelcosts because the high tech designs is a much higher investment that will be harder to pay off with constant earnings (locked to time).
Even a same tech design with higher speed will cost more investment.
But the best argument is probably that it is more similar to how the game currently works. Right now faster ships will make more traderuns and earn more in the same time if they stick to the same route, so lets not remove this nice and realistic feature, ok?
-
I'm no economist, but I thought supply and demand determined prices, not the cost to bring the product to market. If so, then the way to get civvies to deliver commodities to colonies beyond the Earth-Luna milk run is to allow prices to fluctuate locally.
If a colony in Alpha Centauri has pent up demand for consumer electronics, the price of consumer electronics there will go up. Somebody is going to see that as an opportunity to break away from the pack and ship some iPads to the outer colonies.
If I understand the reason for the four jump limit correctly, it's to keep the shipping lines from calculating an excessive number of buy-here/sell-there permutations, and thus bogging down the game. But if there was an up to date list of trade runs, sorted by profitability, the shipping lines just need to pick from the top of the list.
Now, I'm not sure if this is computationally simpler than the current model, or simple enough to justify dropping the 4-jump limit, but some approximation of market economics would provide a self-regulating mechanism for ignored outsystem colonies, regardless of the jump point density.
-
Yes, price would be the natural method of bringing local vs distance runs under control. There could also be price for colonists, determined by employment levels. Colonies with overemployment would be willing to pay a premium for more passengers. *shrug*. A price system might get pretty complicated though, it has to be reasonably comprehensive to get real benefit from it comparing to just fudging it.
I also think loading times for goods should go up. Right now there really isn't a lot of point for commercial spaceports except for extremely short runs. The loading times right now make it pretty important to fit in cargo handling on troopships or dropships, even with their sometimes-tight tonnage requirements... but for cargo ships they are total gimmes and there's not even much point to teching them up. Longer basic loading times would add a higher minimum time overhead for commercial runs, disadvantaging short runs.
-
I'm no economist, but I thought supply and demand determined prices, not the cost to bring the product to market. [...]
Of course. This is already in those consideration though. You could interpret it in a way like this: "High distance between colonies makes ship contact more rare, so the supply and demand levels experience greater disparity, making the trips more worthwhile."
Now, if fuel only costs 10 cent per AE, then that would be all we need to account for, but in reality (and likely much more dominant as factor in lengthy age-of-the-sail like space trips), the increased gains from high demand need to override the increased shipping/fuel costs that come with greater distance to make such a trip really worth more. (+risk and some other factors, but those are details..)
This is what that equation above was about too. d("demand")+d("risk")+d("fuel/shipping cost")<0 means you get a more worthwhile shipping once the advantage of the first two outpace the greater investment of the third.
..Counts for a mere choice consideration between differently distant locations, just as much as for how pricing develops when technology becomes better.(..or you strap on wasteful engines)
@alex_brunius
Because if in the future fuel costs are added distance works perfectly but time dont. You dont pay 10 times more for a shipping that takes 10 times longer to do the same work. It's common sense.
That is only true in the realm of the same technology where faster is indeed more expensive. If you are slower and have more traveling expenses (mostly fuel) because of your technology being inferior though, you indeed end up paying more for less speed. So at a tech jump you see the opposite effect, and distance measurement can not emulate that.
It's also desirable for higher tech designs to earn more even in the current model without fuelcosts because the high tech designs is a much higher investment that will be harder to pay off with constant earnings (locked to time).
That the initial technology (/build-cost) investment works to offset this behavior is a valid point, but it is a one time investment at first (making it fade in relevance over time), and then secondly likely not the dominant expense. (shipping is after all cheaper today than it used to be before, despite of expensive container ships)
The reason why I thought that time would work out as a measurement in Aurora though, is that in Aurora the engines for civils are fixed as always being the 0.5 power factor 25 HS design with a fixed percentage of engine allocation in a freighter too. So the whole "design fast wasteful taxi" thing is factored out in standard Aurora, meaning we never would actually have to face this effect were a fuel wasting 'fighter-engine' freighter would make cheaper trips despite blasting the fuel. What stays then is instead that only overall tech progression can make a freighter faster, and then we see this cheapening effect where it actually also makes sense.(partly because of the reaction time and reduced risk, but mostly because of the also saved fuel)
Fuel would probably be the best measurement of pricing, but it may be difficult or impossible to track for civils in Aurora. So then you have to decide between the other two options of either measuring time or distance.
- Measure distance: Freighting returns (per freighter) increase as technology goes up.
- Measure time: Freighting returns go down as technology progresses.
The second effect makes realistically more sense for the various reasons of the former answer, so I chose to mention that one instead.
Only way to tilt the effect is the technology investment cost you mentioned, but those would have to be quite big in comparison, and it would also be impossible to track them as they depends on how long designs stay in flight (/a tech era lasts), which is different from game to game. Too much consideration in the end, as the effect would be unnoticeable to players anyway. Even the time measurement would just be a make-shift approximation to a realistic answer, as you will probably research fuel efficiency (the realistically most saving factor) at different points to a total engine upgrade (which increase speed and thus would cause the actual saving to appear ingame). First priority should always be to hold the calculation simple before realistic, and this could come close enough.
Now we are discussing so much about a thing that may likely not even be in the game...
-
Now we are discussing so much about a thing that may likely not even be in the game...
True, but this is the Suggestions subforum. It seems like the place for it. :P
The simplest change might be to readjust the limit from 4 to something greater. Take the current average number of jump points, raise that number to the fourth power, and that gives you the average number of systems that the civvies search through looking for contracts. Take the average number of systems in the upcoming version, raise it to the power of x, and set that equal to the previous result. Solve for x and the result is the civvy search radius.
So for example, if the average system now has 6 JPs, and the new system has an average of 3:
6^4 = 3^x
x = 6.5 jumps (give or take; round in whichever direction you feel is most appropriate)
Would that be simple enough and satisfactory?
-
Yes, the above is along the lines I was thinking. There are now fewer systems within a given radius, so increasing the radius of civs should be OK. It's years since I looked at that code so I'll see if I can do anything to improve it as well.
-
I've haven't played for a while due to finding out about X-COM Long War :)
Long War is the Devil!! It is MUCH more like the original Xcom, punishing! :D
(like 2300AD if anyone remembers that)
Love that game. One of the best Sci Fi RPGs from GDW, played the hell out of that and Renegade Legion.
The cool thing about 2300 is that it hit quite a bit of the hard science, and the aliens WERE alien. The Kafers were a cool concept for bad guys.
-
Not sure yet if this is a good idea :) but I have completely rewritten the civilian code and everything else that relies on path-finding, such as refuel at nearest colony. Instead of a four jump limit, there is no longer any limit at all.
I am setting up a very complex campaign at the moment with fourteen (!!) player races so if the new code can handle that, it should be fine. If not, I will have to place some type of restriction but I will make it configurable by the player.
-
Sounds like a big step forward regardless of how it turns out Steve.
*Moment of silence for the pathfinding code observed*
-
Not sure yet if this is a good idea :) but I have completely rewritten the civilian code and everything else that relies on path-finding, such as refuel at nearest colony. Instead of a four jump limit, there is no longer any limit at all.
I am setting up a very complex campaign at the moment with fourteen (!!) player races so if the new code can handle that, it should be fine. If not, I will have to place some type of restriction but I will make it configurable by the player.
Look on the bright side - at the very least you got rid of the existing bugs :)
John