As you know, I've been working on Part II, which is going to require a more sophisticated way of generating a system topology. I want to create something more random, instead of the linear topology of Part I.
But in order to understand the changes that are coming, it will help to know exactly how system topologies work today. Here is a primer:
At the beginning of the game, we generate the entire system topology as follows:
1. Gather together all <SystemTopology> elements. Transcendence.xml has one (the main topology). Huari.xml has another (for Huaramarca). And any extension can add their own. [There is currently no way to override a <SystemTopology> element from an extension.]
2. Each <SystemTopology> element has one or more "root nodes" (a node marked with the rootNode="true" attribute.
3. We start with the first root node that we find and create it. [Note: at this stage in the game all we are doing is creating topology nodes. We do not create the actual star system until the player actually enters the system.]
4. Next we look at the list of stargates leading out of the node. [The stargate list can be a random table, in which case we pick random stargates.]
5. For each stargate we look at what node it leads to. If it leads to a node that we've already created, then we connect the gate and continue. But if it leads to a new node, then we recurse: we create the new node and then look at its stargate table (and so on).
6. Note that the stargate element sometimes points to a node called "[Prev]". This just means that the stargate connects back to whatever node we were processing to reach this node. [This is needed for stargates to be two-way--and in fact, in future versions this will not be necessary: stargates will be two-way by default.]
7. After all root nodes are processed, we call <OnGlobalTopologyCreated> for all types. At this point (and only at this point) code can manipulate the topology (generally by adding new stargates, as in the case of Huaramarca).
From the above algorithm you can see a few implications:
i. Only root nodes are guaranteed to be created. If a node doesn't (ultimately) connect to some root node, it will not be created. [For example, you notice that there are no nodes that lead to Huaramarca--we randomly connect to Huaramarca later in code (using sysAddStargateTopology). But if Huaramarca were not a root node, it would never have been created in the first place, and sysAddStargateTopology would fail.]
ii. The above also means that nodes that are randomly skipped are never created. You cannot reach them in the game, even through code. For example, node C4A is sometimes (50%) skipped.
iii. The topology is more or less set after <OnGlobalTopologyCreated>. There is no way to change the topology after that (nor am I planning any way--we can always enable/disable stargates later).
Given all that, it is now a little easier to talk about the changes and enhancements that are coming:
While no UI is implemented yet, I'm preparing for a Galactic Map that shows the position of every star system on a map. Thus every node will now have an X,Y coordinate. As you are designing your topologies, make sure that you take that into account.
Suppose you want your topology to look like this:
Code: Select all
A1--B1--B2 | | | | B3--B4 | A2--B5--B6 | | B7--B8
The <Fragment> element lets you define a named sub-topology that is reusable. When a stargate leads to a fragment, we generate all the nodes for in the fragment (even if the fragment has been used before).
Normally, nodes specify an absolute x,y position for where they show up on the map. But for fragments, the x,y position is relative to whatever node leads to them.
With fragments you can create a modular topology. For example, suppose you had two fragments that looked different:
Code: Select all
--B1--B2 | | B3--B4 and --C1--C2--C3--C4
Two-Pass System Assignment
Today, each of the nodes specifies the system type that it will have. Each node can have a random table of system types, which is how sometimes a system is a nebula system while other times it is an asteroid system.
But the system selection happens at the time that the node is created (before the whole topology is created). This makes it difficult to place a special system at a specific part of the topology.
Future versions will add a second pass which allows you to alter the system types in specific nodes.
A topology can have one or more <TopologyProcessor> elements, which will let you select a set of nodes (by some kind of criteria) and assign systems types to them.
For example, you could use a <TopologyProcessor> to pick a random node that has at least three stargates and make it a special system type. Or you could pick 20 random nodes in the topology and make them nebula systems (or binary systems, or whatever).
You can also use the <TopologyProcessor> elements to apply attributes to specific nodes (attributes that you can later query when the player enters a system).
Part II Galaxy
My plans for Part II are to use the above features to create semi-random topology that spreads across the whole galaxy. [Of which the current Human Space topology will be a small part.]
Using the two phases above, creating the galaxy will involve:
1. Generating a stargate topology. The topology will generally follow around two major spiral arms, but each arm will have various random fragments sticking out. [This is all TBD--until I playtest it I won't know how well it will work.]
2. Assigning system types randomly to each node. With the <TopologyProcessor> elements I can carve out the galaxy into random regions. Each region will have a particular environment (nebula, metal-rich, water-poor, etc.) Different environments will have different system types, and the encounters, sovereigns, etc. can then be adjusted based on the particular environment.
Hope this primer helps to see where we're going, both in terms of Part II and the modding features that are coming.
Reusable fragments and the two-pass system assignment should be done in time for 1.04.