Fix your bug-ridden game Frontier

I corrected your post. The game I originally bought was "fixed" already (except for a minor vsync bug). The updates make it worse, not better. If I bought a car and the dealer came to my house after the fact and used a hammer to beat in a new radio into the dash, breaking the dashboard in the process, well then we'd have an analogy worthy of what Frontier does to this game.
Please don't do that.

Disagree, by all means, but "correcting" my post is just disrespectful.
 
You don't pay for support you pay for the game and cosmetic add-ons. There is no support contract.

What are these "micro-transactions" you keep mentioning? As far as I am aware the only additional payments you can make towards the game are the cosmetic add-ons, and these are not, by definition, "micro-transactions"

Cosmetic add-ons in ED are still micro transactions. How are those not micro transactions in your book? Please don't equate P2W to micro transactions, because that's just incorrect. They still provide a relevant source of income. I know there is no support contract. That doesn't mean that the support they are giving isn't paid for.
 
Please don't do that.
Sure, here's the argument sans post: The game I originally bought was fixed already (except for a minor vsync bug). The updates make it worse, not better. If I bought a car and the dealer came to my house after the fact and used a hammer to beat in a new radio into the dash, breaking the dashboard in the process, then we'd have an analogy worthy of what Frontier does to this game.

Feel better now?
 
Cosmetic add-ons are still micro transactions. How are those not micro transactions in your book? They still provide a relevant source of income. I know there is no support contract. That doesn't mean that the support they are giving isn't paid for.

I'd call that paid for additional content.

Whatever you call it, you are under no obligation to pay anything other than the core price of the game and Horizons DLC (if you want it). Buying paint jobs and ship kits doesn't give you any more rights regarding game support.
 
Sure, here's the argument sans post: The game I originally bought was fixed already (except for a minor vsync bug). The updates make it worse, not better. If I bought a car and the dealer came to my house after the fact and used a hammer to beat in a new radio into the dash, breaking the dashboard in the process, then we'd have an analogy worthy of what Frontier does to this game.

Feel better now?
Please don't be insulting. The "feel better now" was not needed.
 
I'd call that paid for additional content.

Whatever you call it, you are under no obligation to pay anything other than the core price of the game and Horizons DLC (if you want it). Buying paint jobs and ship kits doesn't give you any more rights regarding game support.

If Frontier are trying to attract new users, a buggy game isn't helpful whatever the reasons.
 
If Frontier are trying to attract new users, a buggy game is't helpful whatever the reasons.
That's quite true. And that is the driving force behind getting bugs fixed.

But also making the game more accessible to new users and dispelling the notion that ED is "hard" and full of seal clubbers. That is what this update was about.
 
I'd call that paid for additional content.

Whatever you call it, you are under no obligation to pay anything other than the core price of the game and Horizons DLC (if you want it). Buying paint jobs and ship kits doesn't give you any more rights regarding game support.

I never said anything about micro transactions buying rights to game support. It's part of the financial model what makes it financially sustainable for Frontier.
 

Achilles7

Banned
No, the term is "Software regression" and has nothing to do with the quality of the actual coding. The codebase of any large project (like Elite Dangerous) is worked on by a number of engineers simultaneously, sometimes in the same code module. This is controlled by a source management system (Git, Perforce, TFVC). A typical scenario for reintroducing a previously fixed issue can go something like this:

Engineer 1 is assigned Bug A (a simple bug)
Engineer 2 is assigned Bug B (a difficult bug)

Engineer 1 forks the code repository and fixes Bug A
Engineer 2 forks the code repository and starts working on Bug B

Software released. Bug A fixed, Bug B still present.

Engineer 2 finally finds the cause of Bug B and fixes it. He merges his changes back into the main branch, because his branch still contains Bug A it is reintroduced.

Software released, Bug A is back.

Normally source control / version management systems are intelligent enough to compare all changes between the main branch and the branch being merged, realise that some of the code in the main branch is newer than that of the merging code and not overwrite that section. Sometimes it can't work out the change boundaries and requests that the engineer does a manual merge. This is where mistakes are made. It's sad, but true, than many engineers, when faced with the complexity of a manual merge merely just chose "use my code" and overwrite the main branch (including Bug A) with their own code. This is particularly true when said engineer has a manager pounding on their desk demanding "haven't you got that fixed yet?" a week from release.

Of course, the regression should be picked up in testing, but often isn't due to timescales. Or is picked up but it's too late to do anything about it before release and delaying release is not an option.
Not my problem! 'Just like the oft-used analogy of the restaurant, I don't care what has happened in the kitchen or the chef's personal problems, just provide me with the food for which I've paid...& make it edible...& in a reasonable timeframe, please!

Given my past criticism, I'm just glad Frontier are not able to interfere with my code the way they could with my chosen dish if they ran a restaurant! Although I suspect that particular career path would have played out a bit like 'The Health Inspector' episode of Fawlty Towers.
 
Reading some replies to my previous post I assume that I have to take new, reoccurring and longterm bugs for granted because I don't know how to make a game myself?
That because the game costs only 40€ I shouldn't expect quality because it's not a 10.000€ car?
No I don't know how to develop a game, I do know how to develop a sofisticated encryption application though since that used to be my work before I retired.
If we delivered broken software to our clients and didn't properly fix it then we would be in serious trouble.
That's the problem in the game development industry, developers can get away with everything without any serious concequences except loosing players.
Once you bought a game there's nothing you can do but hope that everything is okay, the devs carry no responsibility or obligation wether to uphold the games quality or not.

No I don't know how to develop a game but don't tell me I shouldn't expect some quality because of that.
Fdev's QA is a farce sometimes the pricetag of the game or my disability to develop a game doesn't change that imho.
 
Not my problem! 'Just like the oft-used analogy of the restaurant, I don't care what has happened in the kitchen or the chef's personal problems, just provide me with the food for which I've paid...& make it edible...& in a reasonable timeframe, please!

Given my past criticism, I'm just glad Frontier are not able to interfere with my code the way they could with my chosen dish if they ran a restaurant! Although I suspect that particular career path would have played out a bit like 'The Health Inspector' episode of Fawlty Towers.
Not my problem either. If you don't like the way Frontier go about development of Elite Dangerous you are not obliged to play it.
 
No, the term is "Software regression" and has nothing to do with the quality of the actual coding. The codebase of any large project (like Elite Dangerous) is worked on by a number of engineers simultaneously, sometimes in the same code module. This is controlled by a source management system (Git, Perforce, TFVC). A typical scenario for reintroducing a previously fixed issue can go something like this:

Engineer 1 is assigned Bug A (a simple bug)
Engineer 2 is assigned Bug B (a difficult bug)

Engineer 1 forks the code repository and fixes Bug A
Engineer 2 forks the code repository and starts working on Bug B

Software released. Bug A fixed, Bug B still present.

Engineer 2 finally finds the cause of Bug B and fixes it. He merges his changes back into the main branch, because his branch still contains Bug A it is reintroduced.

Software released, Bug A is back.

Normally source control / version management systems are intelligent enough to compare all changes between the main branch and the branch being merged, realise that some of the code in the main branch is newer than that of the merging code and not overwrite that section. Sometimes it can't work out the change boundaries and requests that the engineer does a manual merge. This is where mistakes are made. It's sad, but true, than many engineers, when faced with the complexity of a manual merge merely just chose "use my code" and overwrite the main branch (including Bug A) with their own code. This is particularly true when said engineer has a manager pounding on their desk demanding "haven't you got that fixed yet?" a week from release.

Of course, the regression should be picked up in testing, but often isn't due to timescales. Or is picked up but it's too late to do anything about it before release and delaying release is not an option.
While I gave you some rep, I do want to say that this was a very insightful post. I have wondered over the years how stuff like this happens. Like bugs that have been fixed being reintroduced with updates. Your post shows exactly how that can happen and while I know very little about coding, programming, or even what a "module" is or what it means to "fork a code repository" (insert austinpowersohbehave.gif), I have a better grasp of how this could happen. So thanks for that.

As to the cultural exchange and the mention of cigarettes, this happened to me when I was wee lad...round about the age of 14 or 15. Our next door neighbor was in the habit of having a new exchange student every year. It was like living next to the UN. One year from Africa, another year from Germany, China, you name it. Well this year in question, they had a ruddy little Irish chap. He was cool and edgy. Smoked cigarettes and wore big leather braclets and heavy metal t-shirts. We vanilla suburban Yanks thought he was the coolest thing ever....anyhow....flash forward to one afternoon we were playing basketball in my neighbor's driveway and we get done playing and he's a little winded and looks at the rest of us and asks "got any (plural UKcigarettenames)?" Being good and pure young American children, that word meant only one thing and we were really confused as to why he thought we might have some. I asked for clarification and he said that he could really go for a (single UKcigarettename) right now. He'd given up on (plural UKcigarettenames) and hadn't had a (single UKcigarettename) in his mouth for three weeks but blimey, wouldn't he enjoy a good long pull on a (single UKcigarettename) right now. We were slackjawed.

In retrospect it was hilarious...and when he realized there was a language barrier and we explained why we were so confused, he was a bit blushed himself. Anyhow...thought I'd share. Cheerio!
 
Last edited:
That's the problem in the game development industry, developers can get away with everything without any serious concequences except loosing players.

In my view the games industry is insane. Take a look at something like Fortnite and reports of all the people putting in 70-100 hour work weeks all the time. Then you got crunch time for all the other major studios and all the abuse employees suffer at the hands of not just their employers but their customers as well.

It doesn't seem to me like Frontier engages in that stuff and if the game we have is the result of that then fine by me!
 
Friday 19 April 2019.
Frontier Developments stream the "April Update - Content Reveal" on Twitch: https://www.twitch.tv/videos/412944473
At the 20:25 mark, Executive Producer Adam Wood warns viewers "This is a Hot Build".

Just 4 days later ...

Tuesday 23 April 2019.
Frontier Developments release the "April Update" live.
The advertised release date takes priority over Quality Assurance testing and bug fixes to the "Hot Build".
The "Issues Tracker" is flooded with bug reports.

The exact same sequence of events occurred with the previous "Beyond - Chapter 4" update. Frontier Developments satisfied to advertise and offer for sale a faulty software product "not up to merchantable standard", a practice which has now become widespread among Gaming Software developers and highly likely contravenes Consumer Law in numerous countries worldwide.

Surely developers can recognise that proper QA testing needs to take precedence over a scheduled release date, and that their company reputation as a "AAA" standard game developer will be significantly enhanced as a result?
 
Friday 19 April 2019.
Frontier Developments stream the "April Update - Content Reveal" on Twitch: https://www.twitch.tv/videos/412944473
At the 20:25 mark, Executive Producer Adam Wood warns viewers "This is a Hot Build".

Just 4 days later ...

Tuesday 23 April 2019.
Frontier Developments release the "April Update" live.
The advertised release date takes priority over Quality Assurance testing and bug fixes to the "Hot Build".
The "Issues Tracker" is flooded with bug reports.

The exact same sequence of events occurred with the previous "Beyond - Chapter 4" update. Frontier Developments satisfied to advertise and offer for sale a faulty software product "not up to merchantable standard", a practice which has now become widespread among Gaming Software developers and highly likely contravenes Consumer Law in numerous countries worldwide.

Surely developers can recognise that proper QA testing needs to take precedence over a scheduled release date, and that their company reputation as a "AAA" standard game developer will be significantly enhanced as a result?

Better call Saul.
 
Engineer 2 finally finds the cause of Bug B and fixes it. He merges his changes back into the main branch, because his branch still contains Bug A it is reintroduced.

actually, no. regression bugs may occur for several reasons, but this one should be extremely rare. if they do occur because some coders have an habit or even the possibility of trampling over other's commits then regression bugs are probably the least of a concern, get out of there, freaking anything can happen.
 
Back
Top Bottom