COBRA v2

I wish you read the whole thing.
I did read that and many other articles. Source went through four iterations as well before they went with Source 2.

You have a house and you modify it four times. You add a second floor, you add a bay window, you add a bedroom, you make the kitchen an open floor plan...

Or you build a new house that is laid out exactly how you need it.
 
What kind of features are we talking about here OP, are we sure we mean engine limitations and not code structure limitations? Are you referring to when they say a change is "non trivial"?
 
I'm pretty sure the 2017 version of the Cobra engine doesn't have any 6502 assembler in it :p

See the Ship of Theseus paradox: "The ship of Theseus, also known as Theseus's paradox, is a thought experiment that raises the question of whether an object that has had all of its components replaced remains fundamentally the same object."

It is quite possible that the current engine shares some fundamental design aspects with the old 1980s one, meriting keeping the name, or it could just be that David Braben likes the name... the EA of these days, that specializes in cookie cutter games and is often compared to a sweatshop, is definitely no longer the Electronic Arts of the 1980s that made cutting edge games and put their devs on advertisements like they were rock stars.
 
Last edited:
The next step is dropping the 32 bit clients which should happen around end of Q2 this year, if what the Brabs said last year holds true.

Not correct, They never issued the *Official* warning about that yet, which Mr Braben said would have been issued AT LEAST six months before IF they finally decided to go on with that.

So we don't know when they'll drop 32 bit, but it's certainly, at today, not before fall.
Probably later since it'll probably tied to season 3
 
Not correct, They never issued the *Official* warning about that yet, which Mr Braben said would have been issued AT LEAST six months before IF they finally decided to go on with that.

So we don't know when they'll drop 32 bit, but it's certainly, at today, not before fall.
Probably later since it'll probably tied to season 3

Yep, that announcement sounded to me like they were seriously considering making 64 bit a requirement for season 3 (just as a certain class of GPU is a requirement for Horizons). If enough of us had complained, that might have affected their season 3 development plans.
 
What kind of features are we talking about here OP, are we sure we mean engine limitations and not code structure limitations? Are you referring to when they say a change is "non trivial"?
I'll give you the best examples I can recall. During a livestream a lot of suggestions were made concerning new mission types, commodity storage, CQC bots, etc. The response from Mark Allen (I believe that was his name) and Sandro was that they were all excellent ideas, but it was very difficult to code them. Yes, 'non-trivial' was used a remarkable number of times. This is when they announced materials would no longer be needed for engineer upgrades until they could sort out commodity storage.

I got the impression that doing these things wasn't hard, but the existing engine was like a five stack house of cards where the changes needed to be made in the middle row. We keep seeing new bugs appearing in established areas of the code every time they change things and that indicates to me (my opinion only) that COBRA does not support a modular code base. If I change a line of code in the FSD boot up sequence, the GalMap shouldn't develop an issue, sort of thing.

The code is reliant on the engine. Adding a new feature like commodity storage should be relatively easy in a modular code system. New database table, background game code to support it, add UI elements, done. We have AI in the game, but we're told CQC bots are a hard thing to realize. However, if the engine has limitations then adding new features can become quite tricky. This is what it looks like to me, so I'm just asking the question. Is the bottleneck the COBRA engine?

Again, I have no inside knowledge, these are assumptions based on my observations, comments from the devs and previous experience working in the games industry.
 
Somewhere in the dark recesses of the SC thread (don't go there if you like your sanity) Ben Parry, an ex FD graphics dude commented that Frontier was fanatical about documenting everything, which while tedious beyond belief is incredibly helpful for them.

The above, if true and I have no reason to doubt it, give's me untold confidence in Frontier. Development staff turnover can be high and without full documentation, replacement staff can take an age to get up to speed. Developers are not always happy about this approach but once it becomes routine and they have to go back to re-visit old features then it becomes invaluable.
 
We have NPC's who can fly fighters and even fly our ships, so I'm not entirely sure just how hard implementing CQC bots really is - outside of of the above, that this likely a 3rd floor change. And this very likely has a whole lot to do with the way COBRA is constructed, and less a matter of how it actually functions.

But even with highly modular engines, like Gamebryo, expanding core features is not a simple process - new DLL's have to be developed, tested, integrated, retested and if everything is correct, the new functions will not break existing functions.
 
I've not heard them once state that any limitation is due to the COBRA engine.

Exactly. I think it's more a limitation with how Elite: Dangerous has been designed.

Take multi-crew and SRV deployment for example. It is a non-trivial task to allow a crew member to deploy an SRV and I think this has something to do with how the 'ships' are tied directly to our presence in the game; we are our ships. If the SRV has been designed as part of the ship's presence in the game, i.e. your presence, then unlike the SLFs which were designed from the outset to be used by other players, it would be difficult to allow another 'ship' to control it.
 
Last edited:
Exactly. I think it's more a limitation with how Elite: Dangerous has been designed.

Take multi-crew and SRV deployment for example. It is a non-trivial task to allow a crew member to deploy an SRV and I think this has something to do with how the 'ships' are tied directly to our presence in the game; we are our ships. If the SRV has been designed as part of the ship's presence in the game, i.e. your presence, then unlike the SLFs which we designed from the outset to be used by other players, it would be difficult to allow another 'ship' to control it.

Maybe also why they can't make SRV NPC drive around, I'm sure MoM could write the AI code but getting it into the engine is probably like squeezing a banana between rocks :D
 
Maybe also why they can't make SRV NPC drive around, I'm sure MoM could write the AI code but getting it into the engine is probably like squeezing a banana between rocks :D

I think it may be down to the difficult of navigating obstacles in a procedurally generated environment, which is why they opted for skimmers as they can easily fly over the terrain.
 
OK, so COBRA is all singing and dancing in your opinion. Fine. If it isn't limitations in the game engine, what is the bottleneck to all these changes?

Even if some limitations may be related to inherent architecture of the game's engine, I'm really not sure rebuilding the engine from scratch and replacing it in an already released game is a wise move, especially if you also want to maintain your first engine to sell it to other companies.
 
I am rather happy that we have such a well established Engine. Coding an Engine that supports multiple Platforms and utilizes all modern Technologies throughout them is an incredibly Labor intensive Task. COBRA has been Build around Elite and there's a Reason for that - there is no other Engine that fits the Bill. Also having to rely on not entirely self-maintained Code makes it alot harder to track Bugs.

Also there is a Difference between the Game Engine and the Gamecode itself. ED is designed as Singleplayer where Instance Data is Shared to relevant Clients, all driven from the same Backend Databases. Synchronizing this makes things difficult to code.

As an Example, due to some Mission there's a Pirate spawned from your CPU/Instance which when another Player gets in Range has to share / replicate the NPC Data belonging to your Client. While your Client for Example disconnects then, the next Client that has this Data will gain Control over said NPC ( Lets say you ve been in a Wing ) and has to repllicate that again upon reconnect or when another Player comes along. Its an incredibly efficient Design which COBRA handles well threaded in the Background.

In Terms of CQC NPC again. For thoose short Sessions one or multiple Clients would have to control the AI's that are Opponents regarding teh Connection Speed and Ressource Limits. Running them all from one Machine would simplyfy that but most likely due that Machines limits would possibly impose Rubberbanding Lag for everyone, which would make that whole thing useless. In Multiplayer Games that use AI's controlled over your own PC this becomes a pretty difficult task as theres many many variables to consider. Having a central Server which manages NPC in this GINORMOUS Scope would also require rethinking and tracking of Gamestates on the Server, also increasing latency and most likely would make the Game unplayable on High Load times. As David stated the Methology of p2p has been introduced to make close to realtime Dogfights with Physics as they are possible. Having to calculate that on a Server the Server would have to know not only the Values but also the incredibly Polyrich Geometry ED uses which becomes a labour in Calculation for Physics where you may want 1000s of Cores.

Seeing what COBRA can do in PlanetCoaster in a different Settings gives me as Gamedev high Hopes for Planetairy Stuff. Sure its true that ED develops slowly, but id rather have a solid Foundation in Technology that is well documented than the Mess that is SC now.

Cheers!
 
Back
Top Bottom