...
In the end they went for the second option...
...So they're not repositioning themselves as a pure theme park management game creation company...
So... First - just in case, and for the record: The: "repositioning" thing I wrote was an attempt at a joke. :7
Did they really go for the second option, though? I see nothing to that effect, and the blurb about Cobra, that you linked (...that
you linked ...and then chastised; Both it, and the person you linked it to, for their referring right back to it), is the exact sort of thing I recall reading numerous times along the way, ever since the Elite: Dangerous kickstarter. (No, I am not going to go trawl the wayback machine for evidence.)
From your rethoric, I presume you espouse a monolithic kernel type of "philosophy", rather than a microkernel one... :7
Any engine build for any revision of a game based on it, would include whatever modules and custom code it requires, sometimes omitting bits it does not need . These can individually evolve over time, or be swapped out wholesale.
I could pretty easily be convinced we have a situation of the sort where little individual bits of the family heirloom axe have been replaced as they rust or rot, over generations (EDIT2: I am sure there is going to be at least one reader who'll spot that particular reference pertaining to the allegory
). Less so a complete rewrite.
Looking at a few randomly picked up things:
- We have, by the looks of things, a whole gut replacement in the realm of shaders, for better and for worse (possibly making everything PBR - no idea how much was before, but even stuff one might think already was, looks differently in Odyssey) -- I am sure the artists can balance their materials, given time... Shaders is something you can add, modify, or remove, like any asset.
- I suspect there are things (planets and asteroids), that previously were rendered separately, in a forward rendering pipeline, which have now been migrated over to the deferred one that was already doing all the "hard objects". One might think such a unification would constitute a simplification, but I guess we are yet to see any fruits of anything of that sort - performance is... not a source of joy... (On a side note: Even with deferred rendering, the pools of light around lamp posts (EDIT: ...when flying over the place - not when landed) at new ground locations look to me more like lightmap decals, than actual dynamic lighting, but I don't know). Some time back, somebody on a dev talk made a shoutout to Ben Parry, who had long since left the company, thanking him for the deferred pipeline, which makes me think Cobra did not have one before Elite: Dangerous. Has that had a complete refactoring now, or is it just that more job has been transferred over to it, as I have been guessing? -Aahdunno...
- We've got new biped action in the game... Here we get into the delineation between what is engine, and what is custom game code. For that matter: What is game engine, and what is graphics engine... Let's say we have a first person doing-stuff-including-shooting-amongst-other-things module; That could be a game engine plugin, or it could be something just for Elite...
- The reworked planet terrain generation subset of the Stellar Forge. Again: Is this really something parcelled with the engine, as such, or something custom for Elite: Dangerous, regardless of whether code is shared with another project or not?
- Aand we have a whole "sibling" of the mission generation system, just for on-foot missions, as well as something that procedurally populates bases, all with their own UIs and mission boards. I have no idea whether things that are similar between Ship gameplay and on-foot gameplay share function libraries - it would make sense to my mind, or have a completely separate and specialised "copy" of the code. Is this engine content? -Custom for the title? -Plug-in modules for the game engine?
- (EDIT3: Heh... It just struck me that I had a quite similar argument with somebody just the other day, about the "loop" type of solar prominences. -He was convinced their being 3D meshes was an entirely new feature, with them having been sprites in Horizons, whereas I was all: "Uuh... No, they have always had the appearence of 3D strips with incrementing UV map offsets". Heck, you can see where texels take a sharp turn between triangles. )
You know I think I would pay for a second planet zoo copy (one was for my wife who quickly got frustrated by the clunky mechanics) if I could hang out with the animals in VR. So I think VR would be perfect fit for theme park "tabletop" type of games. Same for JWE which I don't have. They probably didn't include it because it would expose all the shortcuts they made, rotating sprites etc.
...
When it comes to Planet Coaster (less so JWE, which I presume has less in the way of customisation), I have assumed it is mainly down to the: "editor" focus of the game.
-When the player can almost unrestricted throw insane amounts of stuff anyhwere, and at any time, it becomes impossible to guarantee nominal frame rates, and the very concept of level optimisation does not even exist in such a scenario - some culling can be automated, but automation can not do what a deliberate designer's hand can.
I'm thinking there the developers have basically
started out with having given up: "We're a CAD application - not a game, and we're for bird's eye view; Frame rates will go where they will, and don't matter much".
...one might still think they could none the less have thrown a VR "visitor" mode in there, for use with creations from more restrained builders, if nothing else...
And it's not only related to VR. In @Bigmaec video about on-foot vs ship balance you can clearly see that the effects were thought only to be seen from the ground (explosions are flat and rotating), and not from ship. Spheres of combat my arx
The engine is clearly not ready, project is heavily underdelivered, and the roadmap for the foreseable future is "actually releasing the thing through MAny FIxes And improvements (MaFiA)"
So... It has indeed been a hot needle stuck into my eye, through the existence of ED, that explosions are pre-animated sprites, rather than particle systems - preferrably with some complexity to them.
I am not against sprites as such, though.
Everybody still use them to this day, and they are used in particle systems to produce some rater convincing, and sometimes stunning, fire and smoke effects, even with stereo vision.
The illusion just breaks immediately in Elite, though, because their camera tracking behaviour (...and possibly their parenting and/or designated tracking target) is... a little too officious; They
really shouldn't match rotation on the roll axis - only the two others.
...and even when it comes to those others, I am pretty sure (...could be wrong) that when I have been amidst a group of geysers, the observed yaw of the particle sprites that make up the plumes, has not been such that each sprite faces toward the camera's observer point, as you would expect, but they have all matched the absolute space yaw of the camera, so that they are all parallel with the viewplane, meaning any plume that is not straight in front of you, does not face you, but effectively some imaginary person standing next to you.
What little hobby "level editing" I have done - long ago now I guess, was on a game that ran on an engine contemporary with Source2, and there, back then, I had a selection of different ways for the sprite to behave, flags to enable rotation for each axis, and could use any object as tracking target.
If I wanted to make a glowy beam, I would simply make one long rectangle with two additively blending texture layers scrolling at different speeds, and set it to only rotate around its lengthwise axis - simple as hell to set up.
I have a hard time imagining Cobra has a more basic sprite "engine", than that old game.
Incidently, there is a whole commentary node in Half Life: Alyx, about having a bit of lag to the camera rotation matching of smoke cloud particle sprites, in order to make them less immediately noticeable.