I'm sure there's a video suggesting otherwise? There's no way all of the data for 400 billion star systems wouldn't be cloud based.
New Era in Unreal Engine or Cobra Engine?
- Thread starter VR SenseiMatty
- Start date
- Status
I'm sure there's a video suggesting otherwise? There's no way all of the data for 400 billion star systems wouldn't be cloud based.
Robert Maynard
Volunteer Moderator
Yeah, that's what I mean.
When people say 'game engine', I'm not including Stellar Forge in that or any other cloud-based resources. I'm thinking more of graphic commands to an array of different GPU hardware in consoles/PCs.
Why would you think switching game engines would result in atmospheric planets next year?
The Unreal-based video previously discussed on here (and on QA's Youtube channel) has been proved as a fake.
Okay if you are talking of storage of data then that is a database and would be sitting on an AWS server. However the logic that makes the requests, serves that data and builds the systems is going to be coded within Cobra.
Yep, absolutely, all network calls would be dealt with in Cobra. Either way, swiching engines now would be counter-productive.
That's not how it works though. Stellar Forge runs on your local machine while the servers mostly store data like first discovered tags and BGS information.
PS
At least that's what I believe...
It's mainly based on current limitations and speculations born in this Forum that explain why Cobra Engine would not be able to support Atmospheric Planets and it could also be the reason why they've not been developed yet:
- Cobra engine does not support multiple stars as light source (that's what we have in the game right now - Collection of Wonders is a clear example).
- Because of the above, the cobra engine would not be able to generate good atmospheric planets. Imagine a planet in a binary system where only one star makes day/night cycles and you have dark night when the other star is up above in the sky.
- The star class based color schemes introduced in Beyond are bugged: you see the color filter also inside the stations and the sky box is tinted as well. Speculations say they couldn't fixed it because of the Cobra Engine limitations.
- Because of the above the Cobra Engine would not be able to generate correct sky colors on atmospheric planets: imagine a binary system with a white A class star and a Red dwarf star). The sky color would be different depending on which star of the two is creating day light (considering that point 1 and 2 are developed).
- Stars flares, night vision, ship smoke and a lot of other "volumetric" effect in the game behave like sprites. In VR this is very clear because when you turn your head the smoke turns around like a 2D texture.
- Because of the above it could be very difficult to have good quality procedural generated clouds in gas giants and atmospheric planets.
- Cobra engine has just introduced water volumetric fx in Planet Zoo, but the quality seems very far from being able to populate a water world.
In that case FD should NOT switch game engines, unless you want to wait even longer.
Rendering and graphics libraries, in other words.
A facelift, not total organ replacement. It really depends how FDev has their engine set up whether it could be done or not.
As an example, I used to code games in Powerbasic and wrote my own graphics code. Eventually I figured out that I could use OpenGl or DirectX for more options, better graphics performance, time saving, etc. I could sometimes go in after the fact and rework just the graphics code. Not always though, depending.
There are benefits to this, namely the performance benefit. Often companies like Bethesda or FDev build their own engines and tools, but that's not really their specialty and you get clunky games that have lots of bugs or use way more system resources than they should for what they are doing.
Swapping to a proven, streamlined graphics engine could have a huge positive impact on the game. FDev simply may not be interested in doing this though.
Half-Life 2. Now THAT was a game with a super optimized graphics engine. My second-hand computer could run it at full detail, and it ran smooth as butter. Complete physics engine and everything. Source engine. Man, Valve attained the holy grail with that one.
Last edited:
Most of these speculations are nonsense and come from people who have very little understanding about games development. By the way, due to the current limitations of the Unreal Engine it wouldn't be able to run Elite. It would probably make more sense to spend development time to overcome the limitations of the Cobra Engine (which is what they are constantly doing since many years) than spending development time to overcome the limitations of a different, unsuited Engine.
The initial release version wasn't capable of planetary landings and procedurally generated terrain. That's why they developed it. That's their job.
In truth, the galaxy is just storage. The engine only has to render a small part of a single star system at a time.
Could the Unreal engine even handle systems on the scale of Elite? I've never programmed game engines, so I have no idea.
There are also licensing costs to consider, as well as training people to use a new engine.
At the end of the day though, I hardly think Frontier would decide on what engine to use based on player feedback.
There are also licensing costs to consider, as well as training people to use a new engine.
At the end of the day though, I hardly think Frontier would decide on what engine to use based on player feedback.
That depends on how you define engine.
The only real difference between atmospheric and non-atmospheric planets is that there is a natural expectation that atmospheric planets will have flora and fauna of some sort as well as planet side cities like we are used to seeing.
Given the likes of Planet Coaster, Jurrasic World, and Planet Zoo the engine itself is more than capable of this BUT these are single player games and there in lies the rub. It is natural that if you have a number of players in the same interactive environment that their experience should be the same or at least comparable and the added detail regarding behaviours of animals in reaction to player actions means that there will be additional client synchronisation issues to consider - it is not unsolvable but I do not blame FD for making other things a priority.
As a developer myself and having played ED in both VR and on a monitor, I would not say there is any major issues that would prevent atmospheric planets being implemented using the existing engine. The level of effort to do the job properly is likely to be huge (at least an order of magnitude greater) when compared with non-atmospheric planets and even possibly space legs. Switching game engines would not change that simple fact.
Regardless of what engine is used, there are always going to be limits as to what can be implemented and developers on the whole need to cut their cloth to suit the circumstances. It is certainly nice to have certain details done in specific ways but it is not always viable on all hardware, switching game engines would not change that either.
To take a case in point, there is a fantastically detailed rendering engine that I have seen used on a particular project but they were unable to fully capitalise on all the features due to hardware limitations and deployment conditions. As a result, most of the more impressive features had to be turned off and the end result was essentially the net gain in visual fidelity was no where near as what was expected when they originally selected the engine.
TL;DR - My point being FD are more likely to get atmospheric planets out with-in the next 5-10 years by sticking with the Cobra engine than they are by switching to another engine. Switching engines is likely to add more problems than it solves.
Yes, that's why I guessed that the cost of the DLC could be 5%-10% higher
There are a lot of developer already trained in the use of the Unreal engine, while the Cobra Engine is only used by Frontier so they have to train new people anyway.
This is the key.
Space-based games need to deal with a range of scales that no other game does. If you're on a landable planet in Elite Dangerous, the engine needs to render correctly:
- the HUD of your SRV a metre in front of your face
- the planet surface you're on and the mineral fragments 10m away.
- your ship departing 2km away
- the distant planet surface 50km away
- the cobinary planet rising over the horizon 3Mm away
- the gas giant you're both orbiting 2Ls (600Mm away)
- the system's star 1000Ls (300,000 Mm away)
Unlike a conventional game, it can't just render all the background stuff to a static skybox, since planetary rotations and orbits will be constantly repositioning it, at a perceptible rate (especially on Mitterand Hollow, or the World of Death, or similar edge cases with very high orbital speeds)
That's a rendering spread of twelve orders of magnitude, when a typical game might have five, and even that's a lot (100km render distance combined with FPS-level near detail). Unless you're specifically intending an engine to be used for space games with seamless planetary landing ... there's no point in trying to support twelve since it massively complicates rendering for no point whatsoever ...and that's just rendering, never mind all the other issues that sort of scale range introduces.
No-one sensible would make a commodity game engine capable of doing Elite-style space games ... no-one sensible would try to make a space game with a commodity general purpose engine.
- Status