TLDR > A lot of the repetitiveness isn’t a problem of “Lack of disk space”, it’s just a matter of not making good use of procedural generation. Seeing “the same building blocks in a different configuration” is better than seeing “the same thing”.
the space that they would need on your hard drive to make the game really non-repetitive visually would be out of this world
Not necessarily. You can procedurally generate textures, sounds and geometry, but that becomes a huge CPU hog in a game that already blows CPU usage. But most of the repetitiveness can be “fixed” (read: reduced) without adding more than ~20MB of new textures and geometry.
One of the problems is that there’s no variation within a planet. Every grassy planet is the same mechanically. Sure, one might have bubbles in the air, another might have yellow grass instead of red, but they’re mechanically identical. It’s the only planet type to find starbulbs and minerals with parafinum. No grassy planet has an ice cap, or a desert patch, or a volcano. If you ever need to find cactus and pyrite, you have to go to a desert planet. If you need uranium and gamma weed, radioactive planet. Then you have the caves, which are completely identical in every planet.
Some planets may have bio luminescent plants, which are gorgeous to look at, but because there’s no variation within a planet, you see them everywhere. There’s never a point where you think “This is the spot on this planet”. Because everywhere is “the spot”, so it’s just “the planet”, which can also be found on the next star system.
Save for airless planets, if I’m not mistaken, every planet has the same 3 “trap” plants (man eater, whip, spores in a cave). There’s not even a color change depending on the planet. Same damn plant, same damn damage, same oxygen amount on death, whether on ice or on a volcano.
Another thing that compounds on the lack of planetary variation is the same sin that Starfield did, of every point of interest being the same everywhere. Every market is the same, every small settlement is the same, every infested facility is the same. This one is easy to give more variation, just create some building blocks and chain them together, like how rooms are generated in ARPG games like Diablo or Torchlight. You know how each star system has a different market rating? Use that to calculate the maximum size any one POI can reach, or as a weight to the POI that can appear (small settlements become more common in 1 star system, markets more common in 3 star, etc).
They do the above in a limited capacity with derelict freighters, so it’s not like there’s “no way” to do it or “they don’t know how”.
Yet another thing that breaks the immersion and “want” of exploration: the vast majority of the galaxy is “settled”. Star systems without any alien presence are the exception. What the hell are you even exploring if there’s already someone there with a working teleporter in space, plus several POI dotting every planet?
You can procedurally generate textures, sounds and geometry
Does any game do that today? I’m not aware of any. ??
Another thing that compounds on the lack of planetary variation
That’s the same problem again, you need hard drive space for all that 3D variation.
As far as I know all the 3D stuff is what takes up the most space on the hard drive, and that stuff is never procedurally created. /shrug Maybe someday with AI??
.kkrieger did that. Not a “real game”, it’s a demo (of a demoscene), a “proof of concept” or a “proof of skill”. Nostalgia Nerd has a very interesting video about it on youtube.
3D models tend to occupy less disk space than textures, as these usually come in at least 2 files: one for the actual colors, one or two more for light mapping (bump map, emission, normals, etc). I don’t know which format NMS uses, but a .obj 3D model with 62k triangles will take around 4.5MB of disk space.
For comparison, this Damaged Helmet in gltf format (which you can see on your browser here) has 15k triangles, a .bin file (the actual 3D geometry) of 545kb and roughly 3MB of textures - The Default_albedo.jpg is the “actual color” and it alone is larger than the .bin + .gltf, at 914kb.
That’s the same problem again, you need hard drive space for all that 3D variation.
Not really. Again, they just need to be smart with what they have. Grassy planet where one third is green grass, another is red grass, another is yellow. No need for any extra stuff to be made, they already have the building blocks. Better yet, mostly grassy planet with patches of radioactive terrain surrounded by desert.
For buildings, just think about player made bases. You can make effectively “infinite” interiors and exteriors with all the stuff players can use to make a base. Write coordinates of “premade” rooms, write some extra lines of code to join specific rooms together and bam, all you needed was less than 10kb of extra text to increase variety.
You can procedurally generate textures, sounds and geometry
Does any game do that today? I’m not aware of any. ??
Today? No, I don’t think any game does it.
Well, my comment that you replied to was about a specific game that is already out, today. Hence, my point still stands.
Let’s hope that future hardware and games are aligned more with what you described, but today’s games do have limitations, based on the day and age they’re created in.
The limitation is coder skill, not hardware. That .kkrieger example is 20 years old. It could make a Pentium 3 “generate an entire FPS game” from less than 100kb of coding instructions alone.
The question is "why don’t other people do it, then?" and the answer is “because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
“because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
None of that matters, because you can load them in the background/parallel wise, as needed, which is what the game already does today.
But all of that takes space on the hard drive, which brings me back to the point I keep making.
My original comment…
You’re not wrong, but also the space that they would need on your hard drive to make the game really non-repetitive visually would be out of this world (pardon the pun)
, and what I keep replying back to comment on, is specifically about visuals, and variety in the planets, the areas of the planets, and the star systems, and the aliens. 3D models and meshes.
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
So, can you describe for me how the hard drive space for 3D models and meshes would be?
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
My brother in christ, what the fuck do you think i’ve been describing then? I even linked an example of how the 3d model itself, the geometry, the mesh, occupies less disk space than the actual textures
For comparison, this Damaged Helmet in gltf format (which you can see on your browser here) has 15k triangles, a .bin file (the actual 3D geometry) of 545kb and roughly 3MB of textures - The Default_albedo.jpg is the “actual color” and it alone is larger than the .bin + .gltf, at 914kb.
What I see is that you don’t understand how procedural generation works. As is today, how do you think planetary terrain is generated? That it is all saved as a file that is read from your computer/PC? That you could load up a “planetXYZ.file” externally to edit it? That the terrain mesh is this huge file with all sorts of hills and plains that you could import/export and load in Blender?
My brother in christ, what the fuck do you think i’ve been describing then?
Algorithms that use the models/meshes/etc., and not the models/meshes data themselves. Algorithms take up allot less space on the hard drive.
What I see is that you don’t understand how procedural generation works.
I’m a computer programmer. I’ve written that kind of code before (gotta love some Perlin noise). /sigh
Also, you’re not quoting me on that part, but someone else. I didn’t make any mention about a ‘Damaged Helmet in gitf format’ (or anything else in that text you quoted).
As is today, how do you think planetary terrain is generated?
It mixes/matches models (that have meshes, etc.) like Lego pieces to assemble the landscapes/things. If you want more new/varied worlds, you need more models/meshes. The algorithms are not going to create them, its going to just assemble the ones that already exist as files on the hard drive.
Edit: Funny enough, I’m currently downloading the update, all 7.48GB of it. The whole game takes up 14.69GB on my hard disk. I’m going to bet most of the update is the new stations look/variety, and not the logic code for mix-and-matching ship parts.
TLDR > A lot of the repetitiveness isn’t a problem of “Lack of disk space”, it’s just a matter of not making good use of procedural generation. Seeing “the same building blocks in a different configuration” is better than seeing “the same thing”.
Not necessarily. You can procedurally generate textures, sounds and geometry, but that becomes a huge CPU hog in a game that already blows CPU usage. But most of the repetitiveness can be “fixed” (read: reduced) without adding more than ~20MB of new textures and geometry.
One of the problems is that there’s no variation within a planet. Every grassy planet is the same mechanically. Sure, one might have bubbles in the air, another might have yellow grass instead of red, but they’re mechanically identical. It’s the only planet type to find starbulbs and minerals with parafinum. No grassy planet has an ice cap, or a desert patch, or a volcano. If you ever need to find cactus and pyrite, you have to go to a desert planet. If you need uranium and gamma weed, radioactive planet. Then you have the caves, which are completely identical in every planet.
Some planets may have bio luminescent plants, which are gorgeous to look at, but because there’s no variation within a planet, you see them everywhere. There’s never a point where you think “This is the spot on this planet”. Because everywhere is “the spot”, so it’s just “the planet”, which can also be found on the next star system.
Save for airless planets, if I’m not mistaken, every planet has the same 3 “trap” plants (man eater, whip, spores in a cave). There’s not even a color change depending on the planet. Same damn plant, same damn damage, same oxygen amount on death, whether on ice or on a volcano.
Another thing that compounds on the lack of planetary variation is the same sin that Starfield did, of every point of interest being the same everywhere. Every market is the same, every small settlement is the same, every infested facility is the same. This one is easy to give more variation, just create some building blocks and chain them together, like how rooms are generated in ARPG games like Diablo or Torchlight. You know how each star system has a different market rating? Use that to calculate the maximum size any one POI can reach, or as a weight to the POI that can appear (small settlements become more common in 1 star system, markets more common in 3 star, etc).
They do the above in a limited capacity with derelict freighters, so it’s not like there’s “no way” to do it or “they don’t know how”.
Yet another thing that breaks the immersion and “want” of exploration: the vast majority of the galaxy is “settled”. Star systems without any alien presence are the exception. What the hell are you even exploring if there’s already someone there with a working teleporter in space, plus several POI dotting every planet?
Does any game do that today? I’m not aware of any. ??
That’s the same problem again, you need hard drive space for all that 3D variation.
As far as I know all the 3D stuff is what takes up the most space on the hard drive, and that stuff is never procedurally created. /shrug Maybe someday with AI??
Today? No, I don’t think any game does it.
.kkrieger did that. Not a “real game”, it’s a demo (of a demoscene), a “proof of concept” or a “proof of skill”. Nostalgia Nerd has a very interesting video about it on youtube.
3D models tend to occupy less disk space than textures, as these usually come in at least 2 files: one for the actual colors, one or two more for light mapping (bump map, emission, normals, etc). I don’t know which format NMS uses, but a .obj 3D model with 62k triangles will take around 4.5MB of disk space.
For comparison, this Damaged Helmet in gltf format (which you can see on your browser here) has 15k triangles, a .bin file (the actual 3D geometry) of 545kb and roughly 3MB of textures - The
Default_albedo.jpgis the “actual color” and it alone is larger than the .bin + .gltf, at 914kb.Not really. Again, they just need to be smart with what they have. Grassy planet where one third is green grass, another is red grass, another is yellow. No need for any extra stuff to be made, they already have the building blocks. Better yet, mostly grassy planet with patches of radioactive terrain surrounded by desert.
For buildings, just think about player made bases. You can make effectively “infinite” interiors and exteriors with all the stuff players can use to make a base. Write coordinates of “premade” rooms, write some extra lines of code to join specific rooms together and bam, all you needed was less than 10kb of extra text to increase variety.
Well, my comment that you replied to was about a specific game that is already out, today. Hence, my point still stands.
Let’s hope that future hardware and games are aligned more with what you described, but today’s games do have limitations, based on the day and age they’re created in.
The limitation is coder skill, not hardware. That .kkrieger example is 20 years old. It could make a Pentium 3 “generate an entire FPS game” from less than 100kb of coding instructions alone.
The question is "why don’t other people do it, then?" and the answer is “because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
deleted by creator
None of that matters, because you can load them in the background/parallel wise, as needed, which is what the game already does today.
But all of that takes space on the hard drive, which brings me back to the point I keep making.
My original comment…
, and what I keep replying back to comment on, is specifically about visuals, and variety in the planets, the areas of the planets, and the star systems, and the aliens. 3D models and meshes.
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
So, can you describe for me how the hard drive space for 3D models and meshes would be?
My brother in christ, what the fuck do you think i’ve been describing then? I even linked an example of how the 3d model itself, the geometry, the mesh, occupies less disk space than the actual textures
What I see is that you don’t understand how procedural generation works. As is today, how do you think planetary terrain is generated? That it is all saved as a file that is read from your computer/PC? That you could load up a “planetXYZ.file” externally to edit it? That the terrain mesh is this huge file with all sorts of hills and plains that you could import/export and load in Blender?
Algorithms that use the models/meshes/etc., and not the models/meshes data themselves. Algorithms take up allot less space on the hard drive.
I’m a computer programmer. I’ve written that kind of code before (gotta love some Perlin noise). /sigh
Also, you’re not quoting me on that part, but someone else. I didn’t make any mention about a ‘Damaged Helmet in gitf format’ (or anything else in that text you quoted).
It mixes/matches models (that have meshes, etc.) like Lego pieces to assemble the landscapes/things. If you want more new/varied worlds, you need more models/meshes. The algorithms are not going to create them, its going to just assemble the ones that already exist as files on the hard drive.
Edit: Funny enough, I’m currently downloading the update, all 7.48GB of it. The whole game takes up 14.69GB on my hard disk. I’m going to bet most of the update is the new stations look/variety, and not the logic code for mix-and-matching ship parts.