"Elite Dangerous is dying"

Status
Thread Closed: Not open for further replies.
Why?
If you dont understand the code, what is documentation gonna do?
Again I direct you to my previous post where I cover developers not having the time to familiarize themselves with spaghetti code.

There's a reason it's called spaghetti code, it's complex, often counter intuitive, implements the same logic multiple times and especially, poorly structured, devoid of useful commenting, when left to an intermediate developer, over-engineered, because intermediate developers like to look clever. To understand that code is not something that happens overnight, it can take months to reach a point where you know where (almost) everything fits in and how it all holds together (or not).

Personally, I prefer well written and commented code to documentation. But with spaghetti code, you won't get useful commenting in code, and instead most of the comments in a code base will simply be of dead code that got deprecated along the way but never deleted. Of course, you can go through the process of familirizing yourself with the code, but until then development and bug fixing will be slowed, which is where documentation, however limited, can literally shave weeks from this process. Suggesting that you'll magically understand the often contradictory logic of a million lines of code, is dangerously naive.

Because ultimately if you're not going to be in the company that long, if your average lifespan as a developer there is six months or a year, then you're going to lose that familiarity and start over from scratch with every new hire.
 
God, that's cynical.
True...
What's new? Businesses are the most cynical of all - had you not noticed in however many years you have spent living and learning?

A publicly traded business is unlikely to throw potential profit away supporting a loss-making product (I have to use 'unlikely' as there is certainly an exception which one of our helpful forumites would insist on sharing) and are inclined to look for the method of remaindering the product that would have the least impact on their investors and public image.

Why would Frontier behave any differently?
 
Why?
If you dont understand the code, what is documentation gonna do?

Its like a bus driver driving a bus while reading how to drive a bus.
I'm going to take it you're not a developer by profession?

To try and put this into simple terms:
To dive into legacy code that is in a spegitified state is exactly like entering a giant maze and being told you need to fix an issue on the north eastern side. You understand directions (code) but unless you have a map (documentation) you won't know where to go to find that part of the maze or how to address the issue. Or you will find it after many hours of searching and debugging.

Code is usually modular for reusability, sometimes centeralized and sometimes not. various modules come together to make a feature work. Even when it's clean code it takes a little bit of time to see the full picture. Otherwise it's like entering a giant maze and simply told, fix the north eastern side of the wall and thats it.

Worth mentioning as well: Spageti code is usually a biproduct of developers needing to cut corners to meet deadlines. Given the choice developers (usually) like to take the time to standarize the codebase they work on. Innovative developers focus more on the end result than the code, trying to get both types of developers working in the same codebase is a challange in itself.
 
Last edited:
Again I direct you to my previous post where I cover developers not having the time to familiarize themselves with spaghetti code.

There's a reason it's called spaghetti code, it's complex, often counter intuitive, implements the same logic multiple times and especially, poorly structured, devoid of useful commenting, when left to an intermediate developer, over-engineered, because intermediate developers like to look clever. To understand that code is not something that happens overnight, it can take months to reach a point where you know where (almost) everything fits in and how it all holds together (or not).

Personally, I prefer well written and commented code to documentation. But with spaghetti code, you won't get useful commenting in code, and instead most of the comments in a code base will simply be of dead code that got deprecated along the way but never deleted. Of course, you can go through the process of familirizing yourself with the code, but until then development and bug fixing will be slowed, which is where documentation, however limited, can literally shave weeks from this process. Suggesting that you'll magically understand the often contradictory logic of a million lines of code, is dangerously naive.

Because ultimately if you're not going to be in the company that long, if your average lifespan as a developer there is six months or a year, then you're going to lose that familiarity and start over from scratch with every new hire.
In the past 30 years, the value judgements like 'spaghetti' and the likes I've given (and heard from others) are usually based on ignorance. What I find important is what it functionally needs to do, and stay away from value judgements until I do.

Luckily, nowadays functional descriptions and changes are linked to pieces of code needed to implement said changes together with the test plans. If code needs to be documented then normally it isn't or it is done poorly. After stepping on too many landmines with "on par documentation" it is usually the first thing I toss into the bin.

If you technically setup project management well, you don't need to document, regardless of the quality of the code. Code reviews, help with that.
 
Ding ding ding.

If i had a penny everytime someone trotted out the old "It's a great foundation. Lots of potential" gubbins, i'd be as rich as Braben. At some point it's either put up or shut up.
Yep, me (as a KS backer) included. FD have had ample time and feedback and after two years / alpha testing knocked this out the park.

Instead the oven door was opened too early.
 
In the past 30 years, the value judgements like 'spaghetti' and the likes I've given (and heard from others) are usually based on ignorance. What I find important is what it functionally needs to do, and stay away from value judgements until I do.
In the past 30 years, I've found that those who don't believe in the existence of spaghetti code havn't written a line of code in years, if ever.
Luckily, nowadays functional descriptions and changes are linked to pieces of code needed to implement said changes together with the test plans. If code needs to be documented then normally it isn't or it is done poorly. After stepping on too many landmines with "on par documentation" it is usually the first thing I toss into the bin. After stepping on too many landmines with "on par documentation" it is usually the first thing I toss into the bin.
No doubt this would be true if they implemented test plans and code was written and structured appropriately. The point of what I postulated is what if that has not happened, you can pontificate all you want about doing things the right way, but if you're put in front of a steaming product of years of multiple developers each with their own quirks, limitations and ideas, and none conforming to your vision of how code should be written, where does that leave you?
 
Still Doomed?

Well, why shouldn't I pretend to know everything as well, so here goes: At this point, it's a toss-up between money and rep. The money bit is easy enough to figure out, as has already been done. If it doesn't make money, it gets cut. Nobody likes burning money. The rep bit is a bit more nebulous, but it IS important.

Sure, you COULD just cut a less-than-profitable product line like it was nothing and it would make sense, but how much of your company prestige that comes from that product line is important, sometimes quite a bit more important than taking it on the chin, money-wise, for a bit while you turn things around.

Nobody wants to be known as the next 3D Realms. Who?, you say. Exactly.

There's no doubt that ED is a big part of FD's rep. It's what made them what they are today and, for all of the hullabaloo about EDO, until then it was still viewed as THE way to experience VR to its fullest. Alyx may be taking over there, but that doesn't change how much of a rep FD built upon it, and deservedly so.

And now they're a publisher too. Just how interesting would a publisher be to a studio if said publisher were known as the ones that sunk and left to die one of the most talked about franchises ever? Investors?

Yes, viability matters, but that's far from all that a company survives on.

Now, as to the bottom line, how's this all going to shake out? I have no idea, and neither does anybody else who is not in the leadership of FD, but it's not always as simple as profit margins.
 
They can't turn the servers off without giving players a stand alone mode because of all the skins that were bought. Theft otherwise.
They actually could.
well, at the time of the offline mode drop, they did promise that they would have released an offline mode if they ever shut down the servers, but... you know... (and i think that the code grew beyond the ability to actually do that)
 
Last edited:
Sorry, OP is as misguided as the 'Steamcharts! Doom!" threaders. Games don't live or die based upon how much people want them to - they live or die based on economics. Once a company can't make money from a game they won't keep it going. The only influence the players have is in what they spend / don't spend.

Which is why all the negativity is bad - if it reduced the income from a game it will be closed. Doesn't matter how much people want or need (or hate or dislike) the game.

A simple observation, if what you say is correct (And I think you are) Elite is on the way out... There's no more money to be made from it. Who is going to pay cash for anything from Frontier after the lies and deciet and aftyer reading so many negative reviews?

For Elite to come back from this would take a huge effort and amount of time. By no means do I think it'll die tomorrow or even this year. I do think the focus is elsewhere and they'll do the usual MVP fixes and move on.
 
In the past 30 years, I've found that those who don't believe in the existence of spaghetti code havn't written a line of code in years, if ever.
Who doesn't believe in the existence of spaghetti code? I don't see the need for documenting spaghetti. I reacted to your statement bad documentation was better than no documentation, and I still disagree with that.
No doubt this would be true if they implemented test plans and code was written and structured appropriately. The point of what I postulated is what if that has not happened, you can pontificate all you want about doing things the right way, but if you're put in front of a steaming product of years of multiple developers each with their own quirks, limitations and ideas, and none conforming to your vision of how code should be written, where does that leave you?
Finding another job? There is enough where I live.
What would you do, start documenting?
 
Elite is starting to remind me of Loki. Even if it does die for reals, it will still find a way to cheat death.

tumblr_lw6je3xvAr1r1oploo2_r1_500.gif
 
Who doesn't believe in the existence of spaghetti code? I don't see the need for documenting spaghetti. I reacted to your statement bad documentation was better than no documentation, and I still disagree with that.
Yes, and you made your case why and I've found that lacking.
Finding another job? There is enough where I live.
Doesn't help ED, which I thought was the point of the discussion.
What would you do, start documenting?
Clearly you missed the point.
 
In the past 30 years, the value judgements like 'spaghetti' and the likes I've given (and heard from others) are usually based on ignorance. What I find important is what it functionally needs to do, and stay away from value judgements until I do.

Luckily, nowadays functional descriptions and changes are linked to pieces of code needed to implement said changes together with the test plans. If code needs to be documented then normally it isn't or it is done poorly. After stepping on too many landmines with "on par documentation" it is usually the first thing I toss into the bin.

If you technically setup project management well, you don't need to document, regardless of the quality of the code. Code reviews, help with that.

Partly true :) In the 80s, 90s, 20s, code management was a timely affair, documentation took last place to everything else. Now in the 2020s we PMD built into IDEs which help greatly in the management and documentation of code. Alas, I highly doubt there is and PMD in Cobra.
 
I personally truly hope they turn it around, listen to the community, focus on what matters to the concensus and recapture the playerbase. Obviously not the only one thinking and hoping that.

But what concerns me is how FDev have left so many features filled with great potential to rot. Instead of finishing them, rather implemented something new and (initially) flashy for that new thing to again fail to be properly realised and become another "could have been great" aspect of the game. EDO's FPS gameplay is for me the worst move they could have made along these lines.

They clearly did it to draw in new players. So they can market it and "expand" their player base.

All this ultimately points to is where their priorities lie, which backs up the point several people have made on this thread. It's about the money. It's not even about players or rep or a dream or a past promise or whatever else. It's just money making decisions.

So, will it die? Depends how adept they continue to be at convincing people pay and play.

How are they doing with that do you all think?
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom