Understanding New Ore Generation

[TranscendentGeek]

So I am working with the mining files in 1.5 as we are trying to relaunch the Mining Pack project slowly, but surely.

As most modders have figured out I imagine a lot of things have moved around in the source files. However, this table this is new to me. I am not sure if it is exclusive to 1.5 or was present in earlier versions between 1.08 and 1.5

The normal ore tables for the ore type asteroids, such as &tbVolcanicAsteroidOre, are now in the UniversalCompatibility.xml instead of the Mining.xml file.

However, the &tbAsteroidOre; table is in the Mining.xml and this table is very different and I am really not sure of the function.

Code: Select all

	<ItemTable unid="&tbVolcanicAsteroidOre;">
		<LevelTable>
			<Item levelFrequency="vrucc ccccc ccccc ccccc ccccc" count="5-10"	item="&itGoldOre;"/>
			<Item levelFrequency="vrucc ccccc ccccc ccccc ccccc" count="1-35"	item="&itXenotiteOre;"/>
			<Item levelFrequency="--vru uuuuu uuuuu uuuuu uuuuu" count="5-10"	item="&itDuralloyOre;"/>
			<Item levelFrequency="--vru uuuuu uuuuu uuuuu uuuuu" count="1-10"	item="&itPlatinumOre;"/>
			<Item levelFrequency="--vru uuuuu uuuuu uuuuu uuuuu" count="5-25"	item="&itPteracniumOre;"/>
			<Item levelFrequency="---ru ccccc ccccc ccccc ccccc" count="10-45"	item="&itOrthoSteelOre;"/>
			<Item levelFrequency="----v ruuuu uuuuu uuuuu uuuuu" count="1-10"	item="&itIthaliumOre;"/>
			<Item levelFrequency="----- -vvvv vvvvv vvvvv vvvvv" count="10-35"	item="&itIthaliumOre;"/>
			<Item levelFrequency="----- --vrr rrrrr rrrrr rrrrr" count="1-4"	item="&itNeutroniumOre;"/>
			<Item levelFrequency="----- --vrr rrrrr rrrrr rrrrr" count="1-6"	item="&itTetramiteOre;"/>
			<Item levelFrequency="----- ---vr rrrrr rrrrr rrrrr" count="1-2"	item="&itHyperonicOre;"/>
			<Item levelFrequency="----- ---vr rrrrr rrrrr rrrrr" count="1"		item="&itEtheriumOre;"/>
		</LevelTable>
	</ItemTable>

Code: Select all

	<ItemTable unid="&tbAsteroidOre;">
		<LocationCriteriaTable>
			<Group criteria="*metallicComp"
				   levelValue="
				  		100,      160,      250,      500,      1000,
					   2000,     4000,     8000,    16000,     32000,
					  64000,   128000,   256000,   512000,   1000000,
					2000000,  4100000,  8200000, 16400000,	32800000"
					>
				<RandomItem criteria="* +ore; -notStandard; +metallicComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
			</Group>
			<Group criteria="*organicComp"
				   levelValue="
				  		100,      160,      250,      500,      1000,
					   2000,     4000,     8000,    16000,     32000,
					  64000,   128000,   256000,   512000,   1000000,
					2000000,  4100000,  8200000, 16400000,	32800000"
					>
				<RandomItem criteria="* +ore; -notStandard; +organicComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
			</Group>
			<Group criteria="*rockyComp"
				   levelValue="
				  		100,      160,      250,      500,      1000,
					   2000,     4000,     8000,    16000,     32000,
					  64000,   128000,   256000,   512000,   1000000,
					2000000,  4100000,  8200000, 16400000,	32800000"
					>
				<RandomItem criteria="* +ore; -notStandard; +rockyComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
			</Group>
			<Group criteria="*waterComp"
				   levelValue="
				  		100,      160,      250,      500,      1000,
					   2000,     4000,     8000,    16000,     32000,
					  64000,   128000,   256000,   512000,   1000000,
					2000000,  4100000,  8200000, 16400000,	32800000"
					>
				<RandomItem criteria="* +ore; -notStandard; +waterComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
			</Group>
		</LocationCriteriaTable>
	</ItemTable>

Further exploration shows two new ore related functions...
(sysAddRandomOreByValue ...)
(sysGetRandomOreType ...)

Code: Select all

			(setq sysAddRandomOreByValue (lambda (destObj value)
				(block (
					(loops 20)
					(valuePerLoop (divide value loops))
					)
					
					(for i 1 loops
						(objAddItemByValue destObj (itmCreate (sysGetRandomOreType) 1) valuePerLoop 'credit)
						)
					)
				))

Code: Select all

			(setq sysGetRandomOreType (lambda ()
			
			; Returns a random ore type appropriate to the system. This function
			; computes the probability of any one ore type appearing in the
			; system based on the distribution of ore items in asteroids.
			; ------------------------------------------------------------------
			
				(block (oreTable)
					; Generate a probability table from the ore-bearing 
					; asteroids in the system. The probability table is a list
					; of entries. Each entry is a probability followed by an
					; ore type. The first entry has Nil followed by the total
					; probability count.
					
					(setq oreTable (sysGetData "08040003_oreTable"))
					(if (not oreTable)
						(block (tempTable totalProb)
							(setq tempTable {})
							
							; Generate a symbol table keyed by ore type storing
							; the amount of ore found for each ore type.
							
							(enum (sysFindObject Nil "t +asteroid") theObj 
								(enum (objGetItems theObj "t +Ore;") theOre
									(block (currentAmount)
										(setq currentAmount (item tempTable (itmGetType theOre)))
										(if (not currentAmount)
											(setq currentAmount (itmGetCount theOre))
											(setq currentAmount (add currentAmount (itmGetCount theOre)))
											)
										(setItem tempTable (itmGetType theOre) currentAmount)
										)
									)
								)
								
							; If the probability table is empty, then it means 
							; that there is no ore in the system. Instead we
							; enumerate all types and generate probabilities
							; based on the frequency of the ore at this level.
							
							(if (eq (count tempTable) 0)
								(enum (itmGetTypes "t +Ore;") theOreType
									(block (freq)
										(setq freq (itmGetFrequency theOreType (sysGetLevel)))
										(if (gr freq 0)
											(setItem tempTable theOreType (itmGetFrequency theOreType (sysGetLevel)))
											)
										)
									)
								)
							
							; Add the total probability
							
							(setq totalProb 0)
							(enum tempTable theEntry
								(setq totalProb (add totalProb (item theEntry 1)))
								)
								
							; Generate a probability table
								
							(setq oreTable 
								(append 
									(list (list totalProb Nil))
									(map tempTable theEntry
										(list (item theEntry 1) (int (item theEntry 0)))
										)
									)
								)
								
							(sysSetData "08040003_oreTable" oreTable)
							)
						)
						
					(mathProbTableLookup oreTable)
					)
				))

[george moromisato]

Tl;dr:

• &tbVolcanicAsteroidOre; (and &tbStoneAsteroidOre; etc.) are deprecated. We don't use these anymore in 1.5+
• Asteroids use the &tbAsteroidOre; table to figure out what kind of ore they have. The table chooses ore according to, A: the system level (higher system levels have more ore [by value] and higher level ore also), and B: the type of asteroid zone (e.g., metallic ores in metallic zones).
• (sysAddRandomOreByValue) and (sysGetRandomOreType) are used in special cases to spawn appropriate ore for a system. For example, if you come across some outlaw miners, we might use these functions to figure out the kind of ore they carry. These functions look at the ore available in asteroids and generate a probability table to match.

Long Answer

STARS AND ZONES
Every star definition has a maxLightRadius parameter indicating the maximum radius (in light-seconds) at which the star's light is bright enough to matter. For example, inside this radius, you will see the space color brighten and you will be able to take advantage of (e.g.) solar powered armor.

Code: Select all

<StationType UNID="&stStarClassG2;"
   name=			"(G2 class star)"
   scale=			"star"
   ...
   maxLightRadius=	"620"
   >

When a star system is created, we use the maxLightRadius value to define three concentric zones around the star:



The innerSystem is defined as the area inside 60% of the star's maxLightRadius. For a G2 star with maxLightRadius=620, the innerSystem zone ends at 374 light-seconds (60% of 620). The lifeZone starts at the end of the innerSystem and ends at maxLightRadius. Everything beyond maxLightRadius is defined as the outerSystem.

When the system is created, each of these three zones is randomly assigned one of four compositions:

metallicComp: The zone has a lot of metals.
organicComp: The zone has a lot of organic materials (carbon, etc.)
rockyComp: The zone is mostly rocky (silicates, etc.)
waterComp: The zone has a lot of water.

The probability of each composition is determined by the system type. For example, volcanic systems (<VolcanicSystem>) have a high chance of having metallic and rocky compositions (and lower chance of organic and water compositions). In contrast, primordial systems (<PrimordialSystem>) have a higher chance of organic compositions.

When the system is created, we use these zone definitions to figure out what kind of asteroids to create. For example, innerSystem + metallicComp has a high chance of volcanic asteroids.

ORE TYPES
The core game defines the following ore types:

Code: Select all

LEVEL       FREQ    ORE                 COMPOSITION
1           C       titanium ore        metallicComp
1           R       uranium ore         rockyComp
2           UC      plasteel ore        metallicComp
2           R       helium regolith     rockyComp
3           C       palladium ore       waterComp
3           R       cobalt-thorium ore  rockyComp
4           UC      cerallox ore        organicComp
4           UC      gold ore            rockyComp
4           R       xenotite ore        waterComp
5           UC      duranium ore        metallicComp
5           UC      platinum ore        rockyComp
5           R       pteracnium ore      rockyComp
6           UC      orthosteel ore      metallicComp
7           UC      ithalium ore        metallicComp
8           C       neutronium ore      metallicComp
9           C       tetramite ore       rockyComp
9           R       hadron archeolith   rockyComp
10          UC      hyperonic ore       organicComp
10          R       etherium ore        waterComp

The ore definition includes one of the four composition attributes defined above. As you can see from the table, most ore is found in metallic or rocky zones.

ASTEROID ORE TABLE
Now we're ready to look at how ore gets added to an asteroid. Take a look at the definition for an asteroid:

Code: Select all

<StationType UNID="&stVolcanicAsteroidSizeA;"
   name=				"(volcanic asteroid)"
   ...
   >
   ...
   <Items>
      <Table>
         <Null chance="85"/>
         <Lookup chance="15" table="&tbAsteroidOre;"/>
      </Table>
   </Items>
   ...
</StationType>

This volcanic asteroid has a 15% chance of having some kind of ore. All asteroids have a similar definition. Though the exact percentage varies, all refer to tbAsteroidOre:

Code: Select all

   <ItemTable unid="&tbAsteroidOre;">
      <LocationCriteriaTable>
         <Group criteria="*metallicComp"
               levelValue="
                    100,      160,      250,      500,      1000,
                  2000,     4000,     8000,    16000,     32000,
                 64000,   128000,   256000,   512000,   1000000,
               2000000,  4100000,  8200000, 16400000,   32800000"
               >
            <RandomItem criteria="* +ore; -notStandard; +metallicComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
         </Group>
         <Group criteria="*organicComp"
               levelValue="
                    100,      160,      250,      500,      1000,
                  2000,     4000,     8000,    16000,     32000,
                 64000,   128000,   256000,   512000,   1000000,
               2000000,  4100000,  8200000, 16400000,   32800000"
               >
            <RandomItem criteria="* +ore; -notStandard; +organicComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
         </Group>
         <Group criteria="*rockyComp"
               levelValue="
                    100,      160,      250,      500,      1000,
                  2000,     4000,     8000,    16000,     32000,
                 64000,   128000,   256000,   512000,   1000000,
               2000000,  4100000,  8200000, 16400000,   32800000"
               >
            <RandomItem criteria="* +ore; -notStandard; +rockyComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
         </Group>
         <Group criteria="*waterComp"
               levelValue="
                    100,      160,      250,      500,      1000,
                  2000,     4000,     8000,    16000,     32000,
                 64000,   128000,   256000,   512000,   1000000,
               2000000,  4100000,  8200000, 16400000,   32800000"
               >
            <RandomItem criteria="* +ore; -notStandard; +waterComp;" levelFrequency="systemLevel:vruuc|c|cuurv" />
         </Group>
      </LocationCriteriaTable>
   </ItemTable>

Notice once again that we're referring to the composition type. This table uses the <LocationCriteriaTable> directive, which works based on the location of the asteroid. To create ore, we iterate through all the children of <LocationCriteriaTable> (the <Group> elements) and check the criteria value. If the position of our asteroid matches the criteria value, then we execute that part of the table.

Imagine that we're creating a volcanic asteroid in a rockyComp zone. We go through the table above and find the group that says criteria="*rockyComp", which matches our location.

This brings up to a <RandomItem> directive. The criteria reads, "* +ore; -notStandard; +rockyComp;" which means that we're looking for any item that has the ore attribute AND the rockyComp attribute (and doesn't have the "notStandard" attribute). Referring to the ore table above, that includes uranium ore, helium regolith, etc.

Next, we look at the levelFrequency= parameter, which prefers ore of a certain level. The particular syntax here refers to the system level as the center position:

Code: Select all

vruuc|c|cuurv
      ^
      |
frequency for
items equal to the
system level

Imagine that we're in a level 5 system. The levelFrequency parameter tells us that level 5 ore is common (c). Level 6 ore (1 level above system level) is also common, but level 7 ore (2 levels above) is uncommon. And so on.

Using these values, combined with the intrinsic rarity of particular ores, we generate a probability table for each ore type.

But how much ore should we create? The levelValue= parameter indicates the target value to create. Again, this is indexed by system level. The first number is for level 1, the second number for level 2, etc. For a level 5 system, this tells us to create 1,000 credits worth of ore.

Thus the engine will proceed to roll on the probability table we created until we've got 1,000 credits worth of ore.

[TranscendentGeek]

@george thank you so much! That was a much more detailed response than I expected and VERY informative. Though the reduction of ore in the early systems seems a bit drastic. However, with this information I should be able to move ahead with the next generation Mining Pack.

[george moromisato]

...Though the reduction of ore in the early systems seems a bit drastic...

Yeah, it's certainly possible that I overshot in scaling the ore. It would be pretty easy to override the tbAsteroidOre table and try out different values. If we converge on a good set of values, I would certainly take the changes back.

[Atarlost]

I think it would make sense for richness to be at least partially decoupled from level. Sol is not level 1, but should probably be one of the most depleted systems in human space. Systems with lots of active mines should be rich and systems no one is bothering to mine should be poor even if the latter are higher level than the former. Mineral wealth should be identifiable just by looking at what stations a system contains.

[JohnBWatson]

I think it would make sense for richness to be at least partially decoupled from level. Sol is not level 1, but should probably be one of the most depleted systems in human space. Systems with lots of active mines should be rich and systems no one is bothering to mine should be poor even if the latter are higher level than the former. Mineral wealth should be identifiable just by looking at what stations a system contains.

Alternatively, systems could have a chance of spawning mining stations in their largest concentrations of ore which decrease the level of ore in nearby asteroids when added to the system. This would also serve to make mining less broken, as the large, profitable concentrations of ore that break the early game economy would be partially nerfed, but players could still find good ore in limited quantities, and would be able to purchase it from the stations for use at tinkers.

[pixelfck]

I think it would make sense for richness to be at least partially decoupled from level. Sol is not level 1, but should probably be one of the most depleted systems in human space. Systems with lots of active mines should be rich and systems no one is bothering to mine should be poor even if the latter are higher level than the former. Mineral wealth should be identifiable just by looking at what stations a system contains.

This sounds like a great universe-depth supporting idea. The simple version could make this happen by simply assigning a 'development' score to a solar system. The more automated one could maybe derive such a score from the number and/or types of stations spawned in the system.

In other words, the richness of the asteroid belts should be based on the stations present? This would at least make sure that the same algorithm can be used for both pre-set solar systems (St.Kaths, Sol) and procedural ones.

~Pixelfck

[PM]

Stations (or lack of) need not always affect ore generation. After all, you could have systems left mostly unexplored or untouched by humans (e.g., frontier), or in the middle of a war zone where mining or other stations would be smashed by the enemy.

Ore generation not dictated solely by level is a good idea.

I noticed Elysium has no ore at all. It used to have some.

[Atarlost]

Let's see what we can work out.

Primordial Ore Value(P): the amount of asteroid ore that was there when the planets finished forming. This depends mostly on star type.

Ancient Mining Multiplier (0<=A<1): A system that was exploited by the ancient races should have less ore. This may be constant since everything is on the gate network, but may be higher for systems only on the Magellan network or lower for systems that contain both gate types. If Elysium has no ore this is the number that should be zero.

Human Occupation Multiplier (0<O<1): This is inversely proportional to the time a system has been inhabited and humans. This loosely drops with distance from Sol with local minima at ark destinations, but should be high along borders.

Human Conflict Adjustment (0<=C<O): This is inversely proportional to the time a system has not been mined due to warfare. This is probably set by region with specific exceptions. The Near Stars and New Beyond are peaceful except Charon. The Ungoverned Territories have had lots of warfare. The Outer Realm may be in between. Where they exist longstanding core systems like Ares Prime would have C=0 even if the zone they're in has lots of conflict, but apart from apart from fixed systems conflict by zone is probably acceptable.

Industry Multiplier (0<I): This gives systems with lots of current industry more ore and systems with lots of abandoned industry less ore. It's mostly based on stations present "Boom Town" stations like outlaw mines mean more ore. "Gentrification" stations like Hotels and Eternity Port and the Maximus Arena mean most of the ore has already been extracted.

The final ore value would be PA(O-C)I. Possibly the Industry Multiplier is not needed if stations and P naturally correlate strongly because of the way system generation works.

[JohnBWatson]

Let's see what we can work out.

Primordial Ore Value(P): the amount of asteroid ore that was there when the planets finished forming. This depends mostly on star type.

Ancient Mining Multiplier (0<=A<1): A system that was exploited by the ancient races should have less ore. This may be constant since everything is on the gate network, but may be higher for systems only on the Magellan network or lower for systems that contain both gate types. If Elysium has no ore this is the number that should be zero.

Human Occupation Multiplier (0<O<1): This is inversely proportional to the time a system has been inhabited and humans. This loosely drops with distance from Sol with local minima at ark destinations, but should be high along borders.

Human Conflict Adjustment (0<=C<O): This is inversely proportional to the time a system has not been mined due to warfare. This is probably set by region with specific exceptions. The Near Stars and New Beyond are peaceful except Charon. The Ungoverned Territories have had lots of warfare. The Outer Realm may be in between. Where they exist longstanding core systems like Ares Prime would have C=0 even if the zone they're in has lots of conflict, but apart from apart from fixed systems conflict by zone is probably acceptable.

Industry Multiplier (0<I): This gives systems with lots of current industry more ore and systems with lots of abandoned industry less ore. It's mostly based on stations present "Boom Town" stations like outlaw mines mean more ore. "Gentrification" stations like Hotels and Eternity Port and the Maximus Arena mean most of the ore has already been extracted.

The final ore value would be PA(O-C)I. Possibly the Industry Multiplier is not needed if stations and P naturally correlate strongly because of the way system generation works.

Excellent idea. The location of ore should also be a factor - asteroids closer to mining stations should be more affected by human mining, and those near stations hostile to the factions that perform the local mining operations should be more ore - rich. For example, asteroids surrounding a Kobol or Rogue Fleet station should be less affected by the current industry multiplier, while those near a Ranx outpost would partially ignore the industry multiplier generated by CW stations during system generation, but receive the full effect of Ranx generated stations.

[Atarlost]

Excellent idea. The location of ore should also be a factor - asteroids closer to mining stations should be more affected by human mining, and those near stations hostile to the factions that perform the local mining operations should be more ore - rich. For example, asteroids surrounding a Kobol or Rogue Fleet station should be less affected by the current industry multiplier, while those near a Ranx outpost would partially ignore the industry multiplier generated by CW stations during system generation, but receive the full effect of Ranx generated stations.

Local station based effects related to the system scale mechanics will make the real ore capacity of a system vary from what the formula gives. You can use them to allocate ore within a system, but it should be isolated from the system ore level components for easier debugging.

I'm not entirely sold on localized depletion either. The stations will be where the ore is or was, and if the area around the station has been depleted enough relative to other areas the station would already have been abandoned and replaced. There will also be lots of zones we don't have stations associated with where there used to be a station before they were mined out. Whoever implements this will need to decide on some way to telegraph which belts are worth mining, but I think calculating on a per belt instead of a per asteroid basis has less risk of messing up the system numbers.

[JohnBWatson]

Local station based effects related to the system scale mechanics will make the real ore capacity of a system vary from what the formula gives. You can use them to allocate ore within a system, but it should be isolated from the system ore level components for easier debugging.

I'm not entirely sold on localized depletion either. The stations will be where the ore is or was, and if the area around the station has been depleted enough relative to other areas the station would already have been abandoned and replaced. There will also be lots of zones we don't have stations associated with where there used to be a station before they were mined out. Whoever implements this will need to decide on some way to telegraph which belts are worth mining, but I think calculating on a per belt instead of a per asteroid basis has less risk of messing up the system numbers.

A good point. Is there any canon on how permanent stations are in Transcendence? No abandoned ones appear in game. There's also the question of how much time mining operations are canonically supposed to take, given that a single playership can strip - mine a system in a handful of in - game days.

My current understanding of Commonwealth mining stations is that they are set up on large, ore rich asteroids, which are mined by the on - station equipment while Borers, maintained and refueled by the station, mine smaller asteroids elsewhere in the system. Due to simple fuel efficiency, as well as safety from raiders, Borers will mine nearby asteroids when possible, but can mine more distant asteroid belts when nearer ones are depleted or the ore in the distant belts is more lucrative, increasing the duration of time in which it is profitable to keep the station maintained and operational.

Outlaw mining stations operate on a similar system, but are less well defended in early systems, and lack the military force required to reliably hold ore - rich areas. It is possible that they take over mining stations abandoned by other groups due to unprofitability or conflict. Evidence for this is their tendency to deploy escorted groups of Borers to the outer areas of systems, and the aesthetic similarity of their stations to those of the Commonwealth and UAS. As outlaw stations use less advanced defenses, they are generally less expensive to maintain, and due to their more neutral standing with some of the powerful enemy factions, they may be less inconvenienced by war, crime, and instability.

Translated into system generation, my theory would look something like this:

1. System is created. Planets, asteroids, and nebulae are formed. Initial levels of ore are determined.

2. Check whether Ancient Races mined the system. If so, decrease ore levels accordingly.

3. Give each preset station a creation date. This is the year the station went into operation, and thus the year the station's effects on ore patterns began taking place. This date should be some time after humans first discovered the system.

4. Run through each year since they system's discovery, altering ore levels based on the stations present. Mining stations will decrease ore levels in asteroids depending on their proximity. Other stations will decrease the effect of mining stations belonging to factions hostile to them on nearby asteroids. If a mining station becomes unprofitable(the amount of ore it removes from the system multiplied by the value of said ore is less than the cost to maintain the station's operational capacity), it will be abandoned, and either removed from the system or replaced with an Outlaw Miner station. If a large collection of ore is present in a system with a large degree of human presence and conflict is low, a mining station should be built there by one of the system's dominant factions.

---

Code: Select all

Preset stations are a Charon Stronghold, which goes into operation year 5, a Commonwealth station, which goes into operation year 2, and an Abbasid Outpost, which goes into operation year 3. The year in which the game takes place is year 7.

Year 0: Asteroids are spawned, ancient race multipliers are put into effect.

Year 1: Humans first discover the system. Level of activity increases.

Year 2: The Commonwealth Station is constructed, increasing the level of activity as well as the yearly amount by which level of activity increases.

Year 3: An Abbasid Outpost is constructed. A CW mining station is built in a large concentration of ore. Ore level in every asteroid in the system is decreased by a slightly randomized number obtained by multiplying the "potency" of the mining station by the asteroid's proximity to it, and then subtracting the "potency" of every hostile station in the system(in this case, only the Abbasid Outpost) multiplied by the asteroid's proximity to that station. This occurs every year from this point forward.

Year 4: Another mining station is built in another, relatively untapped, group of asteroids.

Year 5: The Charon Stronghold is built, and the system begins taking it into consideration when determining the rate at which asteroids are mined. Due to a combination of the depletion of nearby asteroids and the increased hostile presence in the system, the first mining station is no longer profitable to run, and it is replaced with an outlaw mining station after a check is run to determine whether that station would be profitable.

Year 6: The outlaw mining station goes into effect. Though it is on neutral terms with the Charon Stronghold, and thus able to mine the asteroids near it without penalty, it is hindered in mining the asteroids near the Commonwealth station, CW mining station, and Abbasid Outpost.

Year 7: The player is spawned. There is a CW mining station surrounded by moderately mined asteroids, a Commonwealth station surrounded by lightly mined asteroids, an Outlaw Miner station surrounded by heavily mined asteroids, a Charon Stronghold surrounded by very lightly mined asteroids, and an Abbasid outpost surrounded by asteroids that are almost untouched.

[Atarlost]

That's a lot of effort into something that the player won't even notice.

[JohnBWatson]

That's a lot of effort into something that the player won't even notice.

You could say the same with Dwarf Fortress's world generation system. While every minute detail programmed in won't be directly visible to every player, the nature of procedural generation means that they will contribute to things that are.

For example, while a player won't see the history of a system being written out(Ore generation isn't the only thing this could be applied to), they will see a realistic setup of stations, and more balanced systems. Wouldn't it be nice to have the existence of each station in a system be justifiable? For example, Commonwealth population centers and luxury hotels wouldn't be constructed in the middle of raider - infested nowhere, Charon wouldn't set up weapon caches in places far too out of the way to be of any use, hives upon hives of Ferians wouldn't be set up to mine two titanium asteroids, and Ares outposts, Communes, and Shipyards would all be located in tactically viable areas.

[bzm3r]

That's a lot of effort into something that the player won't even notice.

How can you be so sure the player won't notice it? We could also have "world histories" accessible to the player.

That's a lot of effort into something that the player won't even notice.

You could say the same with Dwarf Fortress's world generation system. While every minute detail programmed in won't be directly visible to every player, the nature of procedural generation means that they will contribute to things that are.

Very well said.