Station placement

Post ideas & suggestions you have pertaining to the game here.
Post Reply
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

I'm looking for ideas to solve this problem: https://ministry.kronosaur.com/record.hexm?id=59451

The core issue is this: we would like a way to determine how common a given station type is (e.g., a Sung Fortress) in a particular region of the galaxy (e.g., in the Outer Realm). The challenge is that (a) station types don't necessarily know about all regions and (b) regions don't necessarily know about all station types.

Let's stick with the example of a Sung Fortress. We could add placement definitions in the Sung Fortress XML to say that they are rare in the New Beyond, common in the Ungoverned Territories, and uncommon in the Outer Realm.

Unfortunately, this won't work if we add new map regions. For example, when TSB adds the Frontier, how do we figure out how common Sung Fortresses are there?

Of course, we could define placement rules in map definitions. The XML definition for the Frontier could include the commonality of all station types. But then, what if an extension adds a new station type (or sovereign) that is not covered?

I can think of a few ways to deal with this, but none is fully satisfactory:

HIERARCHICAL RULES
We could add spawning rules in different places. For example, both station types, maps, and extensions could define placement rules. We would different a strict order for deciding which takes precedence. For example, we could follow these rules:

1. First check any extensions to see if they have placement rules for a given combination of station and system.
2. If not found, check the adventure/libraries.
3. If not found, check the map.
4. If not found, check the station type.
6. If not found, check the sovereign.
7. If still not found, then the station type does not appear in that system.

SPHERE OF INFLUENCE RULES
Another possibility is to model the underlying reasons why stations are in specific places. For example, we could define the sphere of influence of a given sovereign and derive station placement from that. For example, we define a sphere of influence as follows:

Code: Select all

<SphereOfInfluence sovereign="&svCommonwealth;" centerNode="SK" criteria="-nearStars" radiusFrequency="ccuurr"/>
The above defines a sphere of influence for the Commonwealth. The influence starts at the centerNode (St. Katharine's Star) and includes all system nodes that match the criteria (in this case, everything except the Near Stars). The radiusFrequency is defines the influence as a function of the distance from the center. For example, at the center node, Commonwealth stations are common. 2 nodes away (two stargates distance), stations are uncommon, etc.

We would allow multiple spheres of influence and combine them appropriately. For example, we might decide that some Commownealth stations should appear in the Near Stars. This we would create a new entry:

Code: Select all

<SphereOfInfluence sovereign="&svCommonwealth;" centerNode="Sol" criteria="+nearStars" radiusFrequency="rruucc"/>
The above defines the placement probability of Commonwealth stations in the Near Stars as a function of distance from Sol. The further away, the more common they are.

Different levels (extensions, maps, etc.) could define spheres of influence. If a given system falls under two or more sphere of influence definitions, then we would take the average (or something).

DYNAMIC SIMULATION RULES
A more complicated version of the above is to set up a simulation of sovereign expansion and use that to determine placement probabilities. For example, we might define the rules for Commonwealth expansion as follows:

1. Starts at St. Katharine's Star 200 years ago.
2. Expands at 1 system per 10 years (average).
3. It prefers sun-like stars and avoids red dwarfs.

In contrast, the rules for Sung Slaver expansion would be:

4. Starts at Jiang's Star 150 years ago.
5. Expands at 1 system per 5 years (average).
6. It prefers red giant and desert systems.

When the two sovereigns come into conflict, we decide whether one displaces the other or whether they coexist. We use military power, neighboring systems, and distance from capital to make the decision.

We let the simulation run for many years and see what we end up with. We then use the result to compute the probability that a station would be in a particular system.

I'd love to hear thoughts and other ideas.
User avatar
Xephyr
Militia Captain
Militia Captain
Posts: 857
Joined: Fri Dec 14, 2007 1:52 am
Location: Orion Arm, Milky Way
Contact:

I like the sphere of influence idea, but it might need to be able to work linearly as well.

For instance, consider a faction based at node B. I want it to have many stations toward node A, but very few approaching node C. This is already sort of doable by defining distance to a node SystemCriteria but we would only have a smooth level frequency in adventures that are set up with a linear level progression.

So, how about a "negative" sphere of influence, which can overlap with other spheres to reduce the station frequency?
Project Renegade (Beta) : "The Poor Man's Corporate Command!"
Real programmers count from 0. And sometimes I do, too.
JohnBWatson
Fleet Officer
Fleet Officer
Posts: 1452
Joined: Tue Aug 19, 2014 10:17 pm

Love the third idea. Makes for much better, more realistic station placement, and small, random changes to the 'seed' of a faction could create games with far more meaningful differences than what we see now. It would also add a layer of depth to the game that would make different enemy factions feel more separate from each other despite the player interacting with them in effectively identical ways.

It would be deeply interesting, though likely more difficult, to integrate this with the proposal discussed several months back, in which systems simulate their evolution over time, such that factions that reach a system first have more space control(and earlier access to the most valuable ore deposits) than those that reach it later, and factions that behave as parasites tend to build their stations on the fringes of the territory of their victims.
Last edited by JohnBWatson on Tue Oct 04, 2016 12:57 am, edited 1 time in total.
User avatar
Song
Fleet Admiral
Fleet Admiral
Posts: 2801
Joined: Mon Aug 17, 2009 4:27 am

This looks reasonable. Might also work well with a tagging system potentially to add/remove presence systems within the sphere (eg: Heliotropes might avoid systems tagged as being brown dwarfs, small enclaves of outlaw miners might have made their way into hostile space if the payout is high enough)

I would suggest, however, that you make spheres of influence their own entities with a new prefix. This makes them easier to modify for less-advanced modders.
Mischievous local moderator. She/Her pronouns.
User avatar
Aury
Fleet Admiral
Fleet Admiral
Posts: 5421
Joined: Tue Feb 05, 2008 1:10 am
Location: Somewhere in the Frontier on a Hycrotan station, working on new ships.

I think these are some really interesting ideas

I like the sphere of influence idea, as its the most flexible, and having negative spheres helps control things

A fully 'off' sphere could use the "-" for not random, signaling that nothing should spawn there, or maybe have a 'invert weights' parameter to subject its weight or something instead

The third idea sounds really cool, but seems more like something that would be done as a proof of concept, more than anything else
(shpOrder gPlayership 'barrelRoll)
(plySetGenome gPlayer (list 'Varalyn 'nonBinary))
Homelab Servers: Xeon Silver 4110, 16GB | Via Quadcore C4650, 16GB | Athlon 200GE, 8GB | i7 7800X, 32GB | Threadripper 1950X, 32GB | Atom x5 8350, 4GB | Opteron 8174, 16GB | Xeon E5 2620 v3, 8GB | 2x Xeon Silver 4116, 96GB, 2x 1080ti | i7 8700, 32GB, 6500XT
Workstations & Render machines: Threadripper 3990X, 128GB, 6900XT | Threadripper 2990WX, 32GB, 1080ti | Xeon Platinum 8173M, 48GB, 1070ti | R9 3900X, 16GB, Vega64 | 2x E5 2430L v2, 24GB, 970 | R7 3700X, 32GB, A6000
Gaming Systems: R9 5950X, 32GB, 6700XT
Office Systems: Xeon 5318Y, 256GB, A4000
Misc Systems: R5 3500U, 20GB | R5 2400G, 16GB | i5 7640X, 16GB, Vega56 | E5 2620, 8GB, R5 260 | P4 1.8ghz, 0.75GB, Voodoo 5 5500 | Athlon 64 x2 4400+, 1.5GB, FX 5800 Ultra | Pentium D 3.2ghz, 4GB, 7600gt | Celeron g460, 8GB, 730gt | 2x Athlon FX 74, 8GB, 8800gts 512 | FX 9590, 16GB, R9 295x2 | E350, 8GB | Phenom X4 2.6ghz, 16GB, 8800gt | random core2 duo/atom/i5/i7 laptops
Post Reply