System topology

Freeform discussion about anything related to modding Transcendence.
Post Reply
george moromisato
Developer
Developer
Posts: 2997
Joined: Thu Jul 24, 2003 9:53 pm
Contact:

Here's a quick update on my work on system topologies:

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:

Galactic Map
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.

Reusable Fragments
Suppose you want your topology to look like this:

Code: Select all

A1--B1--B2
|    |   |
|   B3--B4
|
A2--B5--B6
     |   |
    B7--B8
Notice that the B1-B4 cluster is the same as the B5-B8 cluster. It would be a shame if you had to specify the same topology twice.

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
Now you can have the nodes A1 and A2 randomly lead to either the B1 fragment or the C1 fragment. Of course, as you increase the number of kinds of fragments (or have fragments lead to fragments) you can increase the randomness of the network.

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.
User avatar
Periculi
Fleet Officer
Fleet Officer
Posts: 1282
Joined: Sat Oct 13, 2007 7:48 pm
Location: Necroposting in a forum near you

That's a really interesting update, especially the 2 pass processing to allow some additions after the nodes are initially placed.

I am excited to see it in action, George. :D
User avatar
alterecco
Fleet Officer
Fleet Officer
Posts: 1658
Joined: Wed Jan 14, 2009 3:08 am
Location: Previously enslaved by the Iocrym

Thank you George for that very nice explanation. There were several things inside my head that went *click* regarding the current way topology works. Suddely things i thought we could not do seem possible.

I look very much forward to the next parts ;)
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.

...
....
......
.........
...............
..........................
.......................................................
ERR: Overflow exception - Value for uint16Happiness cannot exceed 65535
Have some cute puppy videos while we reprogram wolfy.
http://www.youtube.com/watch?v=uQrWZVA_ ... re=related
http://www.youtube.com/watch?v=yd5A1n9NC6A

Anyways - this is simply AWESOME. :3
What version can we expect this to begin showing up in? (This would greatly help in building TSB's topology)


How big were you expecting the Part II galaxy to be?
(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
Jeoshua
Militia Lieutenant
Militia Lieutenant
Posts: 163
Joined: Sat Sep 06, 2008 3:48 pm

Mmmm, very intriguing, especially concerning my dastardly plans (that I have yet to be able to begin to pull off due to various limitations in the engine).
User avatar
ThePrivateer
Militia Captain
Militia Captain
Posts: 943
Joined: Tue Oct 12, 2010 5:12 am
Location: Starton Australia

Code: Select all

ThePrivateer.brainlog.output
Error, line 2911 : Brain has exploded
Rebooting in 3...2...1...
...
.....
Booted successfully, no sector damage.
End.output()
Yeah baby! A Galactic map! Finally!

This will be AWESOME! A massive galaxy in Part II, a galactic map!!!!
:D :D :D :D :D

Wow! I guess it makes sense though...previously the player was confined to the QZ, but now the whole Galaxy is opened up for us to explore!

*Waits on edge of seat for Part II!*
User avatar
digdug
Fleet Admiral
Fleet Admiral
Posts: 2620
Joined: Mon Oct 29, 2007 9:23 pm
Location: Decoding hieroglyphics on Tan-Ru-Dorem

awesome news ! :D

I have a couple of questions:
storywise, is the Human system topology linear because it's an ending branch of the stargate system of the Ancient races ?
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.]
I'm not sure about this, I believe that one-way stargates could be interesting additions for special stargates. Unless, George, you are planning to add a reverse attribute, like [NoWayBack] :P so that we can make them, and still having them default as 2-way.
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 human system topology is linear because its just an illusion of how george designed the game - in reality it is not; it just so happens that only a straight path was established here.
(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
User avatar
ThePrivateer
Militia Captain
Militia Captain
Posts: 943
Joined: Tue Oct 12, 2010 5:12 am
Location: Starton Australia

Wolfy wrote:I think human system topology is linear because its just an illusion of how george designed the game - in reality it is not; it just so happens that only a straight path was established here.
I have read some early notes by George on Trans' website and he says his main inspiration was Nethack.

Nethack is individual levels that get progressively harder, with one Entrance and one Exit (the inbound and outbound stargates).

So it does seem to be more of a design aspect rather than any kind of canonical reasoning (unless of course, the canon was simply built around the game design anyway)
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.

Yes, it was grounded in gameplay considerations, not based on canon. Canon dictates that there is indeed a path to sol, and that for example, sol is a system with only a single gate (known anyways)
(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
User avatar
ThePrivateer
Militia Captain
Militia Captain
Posts: 943
Joined: Tue Oct 12, 2010 5:12 am
Location: Starton Australia

Wolfy wrote:Yes, it was grounded in gameplay considerations, not based on canon. Canon dictates that there is indeed a path to sol, and that for example, sol is a system with only a single gate (known anyways)
Has anyone modded that yet?

I would think it should be easy enough. I'd do it, but I don't seem to have alot of time lately; I've neglected Hell's Trinity, but I should have spare time through December.

In any case, all you'd need is one yellow sun, eight (or is it nine?) planets and the kuiper belt. That makes Sol. Shove one outbound gate in the belt (just like Starton Eridani's one-way system) and you're done.

Basically, it would be like SE -> St'Kt's except you'd be going from Sol to St K'ts.

I reckon it would make a cool Adventure - it would really just change the initial part of the game; from that point on, the player could still be a pilgrim, but you just happend to start from Earth not Eridani.
Post Reply