Very interesting to learn about your own workflow, thanks!
First of all I want to insist on the fact that I don't think, and didn't mean, that game development is more complex or even tougher than other types of software. To me, they share a lot of engineering bases but they also differ on many other aspects.
I actually think that they share a lot in the way they are programmed / engineered, but it's on the testing aspect that they differ the most. Like I said in my previous post, games have an exponential number of "user scenarios" while traditional soft are very clearly scoped. One other big issue is that you cannot do Automated Testing on the biggest part of a game, whereas traditional software use it extensively.
One other point I'm not totally agree with is on the commercial / business / end customer level. I also think that it's where games differ a lot from other apps. Games are not productivity app. They sell pretty cheap compared to professional software (the ones above 100$). So if they break you cannot expect the same customer service. And compared to free apps, their business models is also totally different, therefore their bug mitigation.
And finally :
"Before deploying, play it for a day or two (depending on time/staffing/budget/interest). Try different activities and see what happens. To me, this just makes sense."
I totally agree on this one. I bet that FDev already does that. But I don't work there.
Ryox, I will admit, enjoying the conversation.
My workflow is based on modular units that combine to create a whole. While Manufacturing Software is more linear, breaking it into smaller pieces seems to be the trick, at least in my instance and I should not assume that others do the same though Frontier HAS people assigned to specific tasks so in a small way, I am similar.
Each small team is assigned one unit and works on it until completion. For testing, we all usually take part (Friday is Test day, makes the day also nice and light) in the testing of each completed unit and try and break it. Once again, not stating this is the best methodology but simply how my workflow proceeds and has driven good results therein. The major difference is that it is all hands on board for testing. While things do slip past as nothing is perfect we set high standards for success rate.
Games are multi-headed monsters. I agree 100% that not all scenarios can be tackled due to the infinite amount of PC setups and configurations which may cause unexpected results but a shining example of an easily (I use that term loosely, once again, I am not a game developer/designer) caught issue was the Update 9 reverse contrail and popping station.
Had someone play tested simply by jumping to another system and attempting docking (something that you cannot avoid in the game), this would have been discovered. That was the eye opener for myself in regards how things are tested, or how they are not. X amount of people working on Elite Dangerous Odyssey and all of them missed this?
Not buying it. No one tested and/or played.
While games are light years cheaper (saw what I did there?) and different than Productivity Software, the few base concepts remain the same, test and fix. Value should be based on content not price. I have seen some high end software packages that are absolute garbage and less valued ones that are indispensable. Price does not determine content, which a lot of people assume.
Test for those bugs by playing the game or modules that were updated. My example above regarding the reverse contrail and station popping says it all. Whom would release something like that? Are they in a rush? If you fix something in settlements, do settlement missions. Point is, test what you fix and give the game a small run through before deploying. I feel this is not being done.
Fix those bugs that are causing concern. If I were to state to my Client, you need to run the old version to retain the functionality, I would be in serious trouble. While I do practice in small degree the 80/20 methodology I have set higher standards by 90/10. Having the 10% "less serious" bugs that will not inhibit workflow (from our perspective, the end user may think differently).
From my observations, it seems they are more interested in adding features than fixing many broken aspects of the game. The more you add the fixability becomes exponentially more complex. Use Patch 9.2 a breaker switch. Commit to fix outstanding problems (some for years) before throwing more our way.
New content is worthless if there are too many issues.
Problems, and perceived intensity can also be more personal such as the example below, which I find rather game breaking.
My major irritation is the High Grade Raw Materials "go to Horizons" solution. This is not a solution. This is a problem. Which needs to be addressed along with many others.
ALL Ship based engineers require Raw Materials. Why then, has this not been fixed? Has no one voted on it? Seems that if you can garner enough people to vote on a certain issue, this becomes FDevs focus and all other glaring problems are pushed aside (once again, basing my response on observation not actual practice by FDev).
Bugs should be fixed on priority not a voting ballot. Can you imagine having your car in the shop for weeks/months/years simply because most others are voting on other things they want repaired first? Does not seem to make sense when you apply this to the real world.
Next few patches simply to fix ongoing issues would restore a lot of faith in the game and also the userbase in FDev.
That is a Win/Win.