CIG use proc gen to create static assets. Those assets then need to be loaded into memory all the time as people move around. Where are they stored? On disk or from the server. Some other games use proc gen to generate stuff on the fly from the seed. So the same stuff is always in the same place, but it takes a bit more CPU overhead as opposed to disk/network/memory overhead.
Game Discussions Star Citizen Discussion Thread v12
- Thread starter Yaffle
- Start date
-
- Tags
- star citizen
CIG use proc gen to create static assets. Those assets then need to be loaded into memory all the time as people move around. Where are they stored? On disk or from the server. Some other games use proc gen to generate stuff on the fly from the seed. So the same stuff is always in the same place, but it takes a bit more CPU overhead as opposed to disk/network/memory overhead.
Viajero
Volunteer Moderator
Ah, good old CIG using tried and tested stuff, and passing it as innovation to help us rationalize our sunk cost? Tell us it ain’t so!
![[VR] Merkir](https://forums-cdn.zaonce.net/data/avatars/m/141/141091.jpg?1553527154){kind=avatar}
Regarding the recent procedural generation comments, this is a rare occasion when I think LittleAnt is more correct. Procedural Object Placement is most definitely a subset of Procedural Generation, and I have little doubt that LittleAnt's comments are generally correct, eg. that not every "mountain, rock and tree is placed manually". And despite recent comments to the contrary, I see no indication that he doesn't understand procgen.
Nor, for that matter, do I see any indication that CIG doesn't understand procgen. What I DO see here is that perhaps some people don't understand that procgen can be used as a pre-step to produce vast quantities of pre-generated content (or placement of objects), which can later be used and/or adjusted manually and stored as static assets. Their procgen buildings mentioned recently is one such example.
Nor, for that matter, do I see any indication that CIG doesn't understand procgen. What I DO see here is that perhaps some people don't understand that procgen can be used as a pre-step to produce vast quantities of pre-generated content (or placement of objects), which can later be used and/or adjusted manually and stored as static assets. Their procgen buildings mentioned recently is one such example.
Yeah. Like using Perlin's noise to generate a heightmap and other stuff ? Or playing with the map generator algorithm in Minecraft? It's enough experience for you for someone to understand what procedural generation is ?
I'm not sure you have seen all CIG's videos about planet's generation.
Good news. FDEV will be able to use this third party tool to give some diversity to all its million identical concourses in stations so !
None of that is procedural generation.
Huh? The first two things he mentions are examples of procgen.
And that's also not procedural generation. Procedural generation is good at producing many things that are very similar, such as planets where the differences planet to planet are quite small (although sometimes look large to us little people). Using procedural generation works for a certain class of object, even CIG said it themselves where they might generate some city scape components but then would have to go in and do work on those components for them to make sense to people using them.
You might be using a mix of procedural and manual creation, but the moment you start manually editing you have lost the entire point of using procedural generation, and that is creating infinite and varied landscapes with no human intervention.
You creating a heightmap using perlin noise isn't procedural generation in the game because you are the one doing it by manually inputting the data to create the heightmap, the procedural generation is not part of the game.
Oh yes I can see your point here, you can indeed use procgen to create assets then manually adjust them and store the assets later, but that brings up the issue of the point of procgen if you have to go in and adjust the assets later because adjusting the assets when you have 200,000 of them as bases scattered around the bubble isn't practical, what you do is create a single asset and adjust it so it works then use that asset around the galaxy, so we would indeed have exactly what we have.
What we don't have the way you are putting it is procedural generation in the game, which is the only thing that makes a galaxy with 400b stars and trillions of planets possible. Using procedural generation to generate assets to store and and use later and using procedural generation in a game to actually create the assets on the fly is two different entirely things.
I think it's a matter of how it's being used rather than what it is!
Just to clarify, I do agree, I am probably confusing myself more and I said it incorrectly and was wrong, what I meant and didn't say clearly was that's not an example of a game using procedural generation. If someone sells me a game and says it used procedural generation I don't expect the procedural generation to take place outside the game using tools to generate assets that are then edited and loaded into the game, if that's what happens that's what they should say. I expect the procedural generation to happen in game as part of the game, as in Elite Dangerous.
So yes having thought about it, I was wrong in what I said and apologise to LittleAnt for that.
Trying to be constructive, I want to use this to try to dispel some misconceptions about procgen...
Perhaps many look at procgen in the FDev / ED context and have this same thinking. Fair enough, but since procgen uses algorithms designed by a developer, these algorithms can be used to produce incredibly varied objects (or events, encounters, narratives, etc.), and certainly doesn't need to work only for a certain class of object.
Example, how about a location-based "random" encounter algorithm (not random at all, ofc):
- Seed PRNG for location and return RandomEncounter = random(5)
- if RandomEncounter == 1:
GenerateMonster( num = random(6), 'Goblins' )
- if RandomEncounter == 2:
GenerateVillage( size = random(6), type = random(12) )
- if RandomEncounter == 3:
GeneratePOI( type = random(17) ) # statue, pond, sign, dead animal, etc.
This is classic procgen, but certainly nothing like the procgen we might generally see.
This is quite a blinkered view. As LittleAnt said, the CIG devs are fully justified in using procgen to produce the vast majority of specific content, for example planets, and then manually change some of that content where needed, for example to re-landscape areas for settlements, cities, and other POIs. Since they will only have around 100 systems, this is an entirely appropriate use of procgen to do the heavy lifting, followed by hand crafting. In this regard I have to disagree with your comment that they have "lost the entire point of using procedural generation." In CIG's use case I think it's quite a smart, and indeed necessary use of procgen.
You're moving the goal posts here by saying procgen has to be in-game. LittleAnt (and CIG) have been saying they're using procgen as a "tool" (process might be a better word) towards content creation. I don't think they're marketing their game highlighting "procedural generation", are they? (really don't know)
As above. ED and CIG both use procgen. Their different scopes and "fidelity" mean they use procgen in different ways.
Yes, and I think CIG are using it quite appropriately, mainly as a pre-processing tool / procedure. In fact it's hard to imagine them being able to produce hundreds of planets and structures without it.
Perhaps many look at procgen in the FDev / ED context and have this same thinking. Fair enough, but since procgen uses algorithms designed by a developer, these algorithms can be used to produce incredibly varied objects (or events, encounters, narratives, etc.), and certainly doesn't need to work only for a certain class of object.
Example, how about a location-based "random" encounter algorithm (not random at all, ofc):
- Seed PRNG for location and return RandomEncounter = random(5)
- if RandomEncounter == 1:
GenerateMonster( num = random(6), 'Goblins' )
- if RandomEncounter == 2:
GenerateVillage( size = random(6), type = random(12) )
- if RandomEncounter == 3:
GeneratePOI( type = random(17) ) # statue, pond, sign, dead animal, etc.
This is classic procgen, but certainly nothing like the procgen we might generally see.
This is quite a blinkered view. As LittleAnt said, the CIG devs are fully justified in using procgen to produce the vast majority of specific content, for example planets, and then manually change some of that content where needed, for example to re-landscape areas for settlements, cities, and other POIs. Since they will only have around 100 systems, this is an entirely appropriate use of procgen to do the heavy lifting, followed by hand crafting. In this regard I have to disagree with your comment that they have "lost the entire point of using procedural generation." In CIG's use case I think it's quite a smart, and indeed necessary use of procgen.
You're moving the goal posts here by saying procgen has to be in-game. LittleAnt (and CIG) have been saying they're using procgen as a "tool" (process might be a better word) towards content creation. I don't think they're marketing their game highlighting "procedural generation", are they? (really don't know)
As above. ED and CIG both use procgen. Their different scopes and "fidelity" mean they use procgen in different ways.
Yes, and I think CIG are using it quite appropriately, mainly as a pre-processing tool / procedure. In fact it's hard to imagine them being able to produce hundreds of planets and structures without it.
That's nice to know...
My VAT returns are on version 9.75.3...which is about as relevant to any meaningful SC discussion as your version number
That's nice to know...
My VAT returns are on version 9.75.3...which is about as relevant to any meaningful SC discussion as your version number
Version numbers are indeed a terrible comparison.
Which was funny when CIG seemed intent on keeping SC's version numbers on par with ED's version numbers for years. It might have been unintentional, pure coincidence, but the pattern was disturbingly close.
SC is at 0.0.3.17, amirite?
Grab your popcorn, and if you're a monthly-pay-to-tester or $1k+ backer put on your Big Boy Testing Pants, because this 3.17 PTU Wave 1 is gonna be spicy! 
robertsspaceindustries.com
Spectrum - v7.52.0
RSI’s Spectrum is our integrated community and player interaction service, including chat, forums, game integration, and Player Organization facilities. Player Organizations (“Org”...
robertsspaceindustries.com
Premature PTU Release said:
Source: https://www.reddit.com/r/starcitizen/comments/tsqcxs/alpha_317_wave_1_testing_update/i2tabva/
Source: https://www.reddit.com/r/starcitizen/comments/tsqcxs/alpha_317_wave_1_testing_update/i2t3cdn/
Source: https://www.reddit.com/r/starcitizen/comments/tsqcxs/alpha_317_wave_1_testing_update/i2sx010/
Source: https://www.reddit.com/r/starcitizen/comments/tsqcxs/alpha_317_wave_1_testing_update/i2t3cdn/
Source: https://www.reddit.com/r/starcitizen/comments/tsqcxs/alpha_317_wave_1_testing_update/i2sx010/
Star Citizen Alpha 3.17.0 PTU.8016740 Patch Notes - Star Citizen Spectrum
Star Citizen Patch 3.17.0 Alpha Patch 3.17.0 has been released to the PTU, and is now available to test! Patch should now show: VERSION 3.17.0-PTU.8016740. It is strongly recommended that players...
robertsspaceindustries.com
For sure. Their uses seem fine, to my amateur eyes. (The proc gen layouts fo RnRs etc seem a sensible use, the use of proc gen art tools to 'paint' the planetary surfaces create good results, etc)
I think the more interesting questions at this point still centre on their approaches to planets though. IE are there costs to the techniques which make them a poor fit for scaling to 100+ star systems etc? And would those costs have been avoided by the 'no brainer' use of classic proc gen surface generation instead?
IE stuff like:
- Is 300MB of memory use for terrain fine and manageable? (I dunno ¯\(ツ)/¯ )
- Is having to generate physics collision geometry on the fly a repercussion of the tech?
- Does this stuff play into the memory limits they've hit when expanding Staunton?
- Does it play into the concerns they have about players spreading out within a 'static' server node and having 'streamed in all of its locations'
Possibly the last two points are due to the asset & NPC heavy city locations primarily. But it does seem that the planetary tech may be playing a role too ¯\(ツ)/¯
I guess ultimately it just wouldn't be surprising if Chris has pushed the team towards the prettiest-looking option, and then told them to just 'fix' any extra technical challenges involved in deploying them at scale
Last edited:
They showed off their super fast content creation software and skills 6 years ago. Since then, even going by those "old" techniques, they should have had all systems already going. So, why haven't they?
1. It doesn't matter how much content they have, if it breaks the game to have above a certain number of items, that wont change till their engine can handle it i.e. they cant even run 2 systems at the same time, let alone 101.
2. They dont need to provide you any more content, since the less they do give, the more money you give. Every new ship thats bought is more time to sit around and do nothing.
3. All that content creation software doesn't do what they want and essentially is horsecrap and wow, noone else even bothers to make/use similar software for games.
Thanks.
So where's the Quanta, Ant?
1 - server meshing is not here. The actual server architecture can't handle more than Stanton+50 players.
2 - tools showed during the years were (for some still are) not mature enough to be used in an industrialization process with non technical employee.
3 - planetary tech was heavily worked till 2020 and at each iterations transformed the geographical structure of planets, forcing the manual relocation of most of the manually placed structures. Mass producing planets while knowing you'll have to redone all the manual placement of asset on each them at each iteration of the planet tech is a no go.