What are some things you would like to see be implemented into this engine that have not yet been covered?
I’ll start by adding natural MUDSLIDES, VOLCANOES, EARTHQUAKES, VORTEXES for constant changing of the landscape. This is a next generation engine and company who should take this into consideration. What are your thoughts and would you like to see?
Hmm. Landscape deformation was always one of those things that we were told was not really supported by procedural generation techniques. We have yet to hear any different from @INovaeFlavien or @INovaeKeith.
I’m going to cut through it all and ask if you’ve heard of this? Miner Wars 2081.
I haven’t played it personally, but from all the stuff you’ve been saying on these forums, it sounds like it might have the tunnelling, destructible landscape you seem to be looking for.
Procedural landscape deformation to simulate geologic events wouldn’t be that hard, just another layer of Perlin Noise to add or subtract a few meters of ground level every few thousand years, on seismically active planets. The hardest part would be to find a place where such a change had occurred, if it happened in realistic geologic time. Even the Siberian Traps flood basalt event is believed to have occurred over something like a million years, iirc, and that “only” changed ground height by a few km at most. Not much at all, seen from space.
What can’t be done in a smart way is player-controlled landscape deformation; you can’t predict human action with a high enough level of accuracy (#blamerandomquantumeffects), and you can’t simply save the new heightmap as you would in a smaller/less detailed game (it might literally require more data than can currently be stored by all of human technology).
Most of this was covered on the old forums (though whether it’ll be in-game is as of yet unknown, except that Battlescape will likely be light on anything “previous”).
A habitable moon is actually the setting of many recent pictures and videos, or at least it’s got what looks like liquid water, a bluish atmosphere, and appears to be orbiting a much larger planet.
No reason why the engine wouldn’t generate habitable moons, but in the case of the gas giant in the screenshots and videos, I think one of the devs said it was staged/the planets had been moved closer together for aesthetic effect.
I may be wrong though.
None that the devs haven’t already thought of. They already have their work cut out.
If we’re just shooting the breeze: Dynamic atmospheric weather (obviously no point even thinking about this until clouds are in and AFAIK they’re still proving problematic), Comets, Kuiper belts and Oort clouds.
well I’m sure the developers haven’t thought of everything so pretty much your saying we might as well just give up discussion in this engine??? That doesn’t seem that progressive at all. I don’t like to be a downer it just makes others react that way back, however I do like ideas and Dynamic atmospheric weather sounds like a good idea.
I’m not saying don’t discuss the engine. I’m just saying the devs don’t need people telling them what they should ‘take into consideration’.
I can tell you for sure they’d love to implement dynamic weather, comets, terrain deformation, etc., etc., and they have already thought of them and prioritised/declared out of scope/infeasible. I can also be pretty sure that anything that they haven’t thought of isn’t going to be a priority or even in scope.
I do take a rather pragmatic approach - It’s not my intention to shoot you down. Sorry if that’s how it comes across!
I thought the suggestion part of this forum was for that exact purpose, to suggest! I don’t see how you shot me down by the way but okay? I had another idea for the engine wait for it… let someone else develop it the rest of the way to keep the ball rolling speedy and steadily just my thought. I am eager to use the SDK to see if the engine can be modified any further from just a terrain generator with ships
I would love to see Oort clouds, but given the as-most-recently-announced size restrictions on star systems (1 Platonic cubic light-year), we should, assuming a simple scaling relation, only be able to fit them inside a system’s bounding box for stars of masses less than 25% MSun, and, while that is still going to account for the vast majority of stars in the galaxy, it makes for some very notable omissions.
Well, ye know what they say: You never know if you can make an engine capable of seamless interplanetary travel until you try. What this topic needs isn’t feasibility but originality.
So with that in mind, space whale brothels!
inb4 someone quotes 5 other topics with that exact idea in 'em…
Iirc that number was calculated by the community based on an assumption that when IA talked about 1mm precision and 64 bits he probably meant 64-bit integers. Turns out modern CPUs have a lot more pipelines for working on 64 bit/double precision floating point values.
Well, that would be welcome news, but as IA himself was describing systems as being cubes with sides one light-year in length, I’m not going to hold my breath until he or Keith actually update us on the numbers.
Using doubles rather than bigints actually reduce the size of a system requiring a threshold level of precision by a factor of 2^11, however, doubles are a hell of a lot easier to work with, may actually offer improved performance depending on the hardware you’re running on, and you still get 1mm precision at the orbit of Neptune.
At a distance of half a lightyear from the system origin, however, precision would be reduced to something like +/- 1 meter which, I would expect, would be insufficient for dogfighting to feel good. There are programming tricks that could be used to make dogfighting feel good again (set up a “local system”), but really, why not just design the game in a way that wont give players a reason, or ability, to go much further from a system’s primary than the orbit of the outermost planets generated by the engine?
I mean, personally, I’d quite like to have the option of visiting the Oort cloud, or even the iirc much nearer Pluto, even if I don’t ever get around to actually doing so… but it might not be the best use of INovae’s very finite programming resources to set it up to be possible?
EDIT: So the point I’m trying to make here is that I’m almost positive IA never said anything about the 1ly-cube, that it was actually invented by a community with a much weaker grasp of how programming works (including myself), and that really it’s a moot point as neither of our recollections of what occurred on the old forums would allow Oort clouds to be implemented for all stars if I understood that part of your post correctly.