They're autogenerated, which tends more to the unpopulated side. It will improve as time goes on, both via adjustments to the system generator and inclusion of custom systems to support scenarios or storyline we want.

I made this video just after the 3d galaxy hit the repository. Its had a couple of very minor tweaks since then but the fundamentals remain the same.

thanks Robn! That vid is a massive help

is there a discussion thread regarding populating the galaxy?

thanks Robn! That vid is a massive help

is there a discussion thread regarding populating the galaxy?

There is now! 😀

I personally think that this should tie into the factions ideas, since we might want the populated volumes to match the factions.

However, there's probably no good reason to stop us/you from manually populating a few of the real star systems with reasonable sounding populations, space stations and ports. The worst that will happen is that we'll have to give some feedback that might alter them. Definitely avoiding anything that was expressly in Frontier/FFE for example. That doesn't mean that Tau Ceti can't be a inhabited with interesting planets, just that they shouldn't be copied from those games!

Longer term one way of affecting system population might be to define volumes which belong to a faction, perhaps with a drop-off rate.

EDIT: (worth nothing that I don't mean you'd _see_ these ingame, just that they'd be there in the data controlling population/faction distributions)

Then when it's generating the system populations it would evaluate the contribution of these volumes and assign a mixture of the factions where they overlap.

Hmm, start of an idea in there I think 💡

I'm thinking that would be good for building sets too. If, for example, we have Federation, Empire and Alliance building styles, cities near the center of the volume would be exclusively of that faction's style, but as one moves near the periphery of the volume the styles of the buildings would become increasingly mixed.

Yeah the factions sounds good. I always used to start out in Lave and save up $$$ till I could afford to get into the Imperial systems.. then save up even more to make it all the way into Sol.

Was satisfying feeling when you finally got to make that jump and see Sol pop up...

The suggestion I have would be to spawn pockets of civilisation... ie if a Star System spawns/generates/itereates as a high population centre - (multiple cities on a planet, more than just one space station - you know something like Phekda or Alioth in that there's a bit going on that you can fly around) then x number of systems around this major population centre would also be populated thinning from the high population centre

this would in turn create the Alioths and Phekdas of this galaxy perhaps??

Yes! High population civilized areas thinning out to lawless no man's lands in between them. That's what I'm hoping for.

I quite like this idea, not sure entirely how to define these volumes yet. It might be possible to add a feature to the galaxy viewer itself so that interested people can go in and edit within the game engine. Possibly only do this using a command line flag for "developer mode" ... anyway that's an aside.

What do other dev's think about defining simple volumes to control the population and development, and later factional alignment, of a system?

Is there some kind of faction document/page with actual implementation discussion around?

Are there any objections to this approach?

Andy

Another option is to keep it completely procedural.

Although how to define this so that it allows for factional centres of power etc does seem a bit trickier.

a) use your 3d engine to do the work for you. Define volumes as a mesh.

advantages: -You should already have most of the code for it.

- even complex, irregular volumes can be easily defned by creating a mesh in a 3d-programm

disadvantages: -very static

b) Go procedural. Write a course algorithm that takes a starting point and expands from there, using a (very simplified) model of resource allocation, a short tech tree and a bit of politics to determine expansion speed. Where volumes start to overlap you get a much slower expansion rate, an occasional war and smuggling galore.

advantages: -provides you with a course, but consistant history you can build on.

-completely dynamic: History could even continue while you play, you could play in different time periods, and if things get boring you can change the history seed and get slightly alternative histories.

disadvantages: -Unpredictable, especially when modding. When someone adds a new major faction via a mod, it will change the whole course of history

-a pretty piece of work

-longer loading time at game start (depending on how course the algorithm is. I think it should be possible to make something that can run through a thousand years of history in under 5 seconds, but that would be very course. The more detail you want out of it, the longer the algorithm has to run).

C) A combination of the above, combining some of the advantages and disadvantages: Make a procedural algorithm that generates you the volume and the history, and then freeze it and load it at startup instead of generating the whole thing. Has shorter loading times, is more easily modable and offers you full control over the result, but it is again absolutely static, and it's a lot of work.

Well I started to look around the source code last night to figure out how it determines the current star system data.

It looks like it just takes the distance from 0,0,0 :- i.e. Earth/Sol. As it's main determinant for a planets population.

That would be the obvious place for me to hook in assessing the local volumes etc.

@UncleBob

My current plan is just to do some hacking on my own PC/branch to work out how I'd do manual volumes and then work from the understanding I develop doing that to create a procedural algorithm that is time based. I _really_ like the idea of places changing over time 😀 populations, number of stations (it would be insanely awesome I you could see them being built... but no), goods on offer, everything really.

Good suggestions!

Oh and I just remembered, whilst doing this investigating I stuck breakpoints in the various parts of system population.

During the creation of a new game the star system generation gets called a HUGE amount. I haven't looked into why but it all seemed to be from Lua.

I'm wondering if there might be something in a script that could be partly responsible for the very long new game start times.

I'll try to take a look at this...

I think I really need a to do list! 😀

Oh and last night I profiled our Simplex noise implementation against a SIMD port of a glsl version using the GL Mathematics library and another open source library.

By iterating over the noise function itself 10,000,000 times for each function, and even by forward generating the parameters for them to eliminate that as a potential overhead, I've found that our current noise function is at least 2 times faster than the one I found via this thread http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293473 ( http://webstaff.itn.liu.se/~stegu/aqsis/DSOs/DSOnoises.html ) or https://github.com/ashima/webgl-noise/wiki which I used GLM to test using C++.

I.e: it's pretty quick already, there might be specific ways we're using it for Pioneer which we can optimise it for but otherwise it's not going to get that much faster without some really careful understanding.

First for generating the visible systems, second for generating all the systems for missions, I would guess.

StarSystem.GetNearbySystems. We know a better mechanism is required, and we know the system cache behaviour is suboptimal. Just needs someone to get in there and think about it.

Ugh yes I see what you mean.

Ah well. Another one for the issues list 🙂

The discovery of the ToDouble() method on fixed datatypes is speeding up development 😀

The biggest problem right now appears to be the paucity of potentially habitable stars. I can setup, well hack in this case, a list of points in the sector view that function as the centres of population exodus. Just like Sol does.

However most of the worlds generated are frigid, gas giants, or otherwise unsuitable for the habitation algorithm to put life on them. I think it needs to be a bit more flexible as we'd surely terraform a lot of the worlds, build space stations and star ports of dead worlds etc.

Still I think the idea is coming along. Not a clue how to turn it into an algorithm yet, but a manual system using Lua scripts seems plausible right now 🙂

Andy

Oooh actually I just had an idea.

Back at Uni' I wrote a system for generating dirt textures using a process I can almost remember the name of... it'll be on my HDD somewhere. Anyway it's slow and a bit oddball. Ah ha! Diffusion limited aggregation that was it. I could probably also implement something using a simple directed tree I suppose. Then branches could "grow" over time too(?) meaning the number of inhabitants etc.

Not sure but there could be something good in either of these approaches.

I might have gone mad with the power of Lua! 😆

Just scripted up some system generation to populate a vast swathe of space, centred roughly on the coordinates of Achenar from Frontier for obvious reasons, with hundreds and hundreds of stars so that I could test the rough population heuristic I've got.

Ah damn that's awesome

Damn imperials! 😛

We'll still need multiple factions and factional reputation that gets displayed somewhere in the character screen, so something will probably have to be hard coded. Still, if the system is open enough to add custom faction by LUA, all the better. I bet Pioneer will get used for gazillions of total conversions if it is easily modable (hmmm... Perry Rhodan Mod, anyone? 😛 Way too early to think about stuff like that. Bad Bob!)

Hey, the answer I believe is in Starsystem.cpp around line 1450 where there is a large list of ifs and if/else statements where colonisation is abandoned due to certain condistions. You'll just need a check above all of those for: (psuedo code)

if (human_proximity > 0.25) {

do life stuff...;

}

I think thats the bit anyway that deals with colonisation.

This is one section from that part, where colonisation is abandoned if the resources of a planet are crappy:

While you're in StarSystem.cpp, would you mind checking/fixing all the math and cleaning up the code? Its one of the giant things to do and nobody wants to touch it 🙂

That's because there's so much math! 😆

Is there a list of specific issues for StarSystem or does everyone just look at it and run away?

Not sure if this is specific or general. It is just off the top of my head though 🙂

[*:so5yao2w]The math needs checking to make sure it actually implements the correct algorithms/theory of system generation

[*:so5yao2w]The fixed-point stuff needs checking for overflows, underflows, precision problems, etc. There are many, and some have just been fudged around. I know there are edge cases where zero-mass bodies can be generated, bodies generated inside other bodies, impossible orbits, etc.

[*:so5yao2w]It needs a decent class structure.

#699, terrain refactor is an example of some code of similar complexity being broken out into a managable structure. I'm not suggesting it be copied, but it might be useful.

[*:so5yao2w]Stricter checks on data access required (eg hide member variables etc)

[*:so5yao2w]Looser coupling between StarSystem and SBody

[*:so5yao2w]Looser coupling with CustomSystem/CustomSBody (overlaps with some other work/thinking that's going on around custom systems)

That's just a start 🙂