Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
I have a conspiracy theory that the dev team has been infiltrated by PETA or Greenpeace. And they are purposely adding bad code to ruining the game because it’s a hunting game.
No way would PETA [people eating tasty animals] care about hunting. Kidding aside they [PETA] would rather virtual hunting verses real hunting. The deep problem the Dev's mentioned is likely their pockets as in they don't want to reach down and pull some profit out to fix things.
You've got your AAA teams, your indie teams, then you have teams that are in between... like these Avalanche Group teams such as EW. They are small teams that are trying to get to that AAA level. AAA teams have the advantage of huge numbers and knock out bugs extremely quickly as long as they focus on them. The project can fail, but it really cannot be at the fault of the coders because the company has divided the workload so much that you can only blame the project leaders or their own choice of game to develop.
Indie devs do not need to follow 8-5, 40 hrs per week schedules, so tiny teams (or in some cases, individuals) passionate about their project can freely crunch 12-16 hrs per day for weeks to get through problems if needed... and they do so without concern of their wages, if they even get wages, because it's more about the art. Everybody in the indie team has their hands in every part of the code and that is ok because it isn't too many people where it's hard to track changes. The project can fail and the only ones they have to answer to are themselves.
For these in between companies, things get complicated. They are trying to divide the workload which on one hand increases code production, but on the other hand limits the number of people who can solve a problem in any one area. Most people are hired, so the passion involved is going to be extremely varied by person. Some will lose their passion because they are forced to work in only one area of the code. Those who are truly passionate about their work on the assigned project won't really be able to express their passion through working harder. More often than not, it will be policy, if not law, to adhere to a schedule... and schedules are very difficult for coders. Fridays in particular are the worst. You are at your peak moment where everything during the week is coming together and you know you can get something to be complete and amazing if only you had another 6 to 8 hours to work on it... but then weekend comes. Come Monday, you've forgotten half of what you were in the middle of and now it takes you half of the week to get back into the groove. Now think about vacations, holidays off, or just being interrupted do to Covid-related things.
On top of that, since your code depends on the code of person B's system, and person C depends on your code for theirs, and since all people involved have these same constraints affecting them, things can get out of hand. The only way to reduce the time lost in the confusion is to document every single detail. For AAA companies, no big deal, they have the time and resources. Indie teams don't have to bother. In between teams... well, they lose a lot of time trying to save time but more importantly it gets done just for some peace of mind - and peace of mind they need, because if the project fails in a smaller company, it is much easier to blame the coders.
All speculation, of course. Really, no matter how you look at it, and no matter what the circumstances might be, this game is not in alpha/early access and should perform appropriately, but it is on the borderline. The company needs to direct its focus on the issues.
It's a meme. There are some bugs which are 4-5 years old. I remember playing the game at launch with a friend and we used a self-made mod to fix the loud footsteps in Hirschfelden. It's still the same 5 years later. Currently giving them a pass until they release the next "big" update. if majority of the big bugs remain, I will change my review back to negative.
It's not just simply a matter of changing one line of code and brushing the dust off your hands. There are a lot of steps and factors that need to be considered when you are bug hunting in code that is as large and complex for things like an in depth simulation game.
I don't have time to go more in depth on this, but incompetence is rarely the issue.
Whine all you want the fault is that of the people that continue to make it profitable.
Perhaps, it will be said, with some justification, I just haven't played enough to find them. I'll be working on that, since the Mississippi map seems fun.
I think this is part of the complication. Some players are legitimately running into bugs, and others are not. Probably because it's a complex game, and the way someone else has always hunted leads to them finding something really annoying to them, and the way you hunt means that same thing never happens to you. So how does the qa/dev team reproduce that to even identify what is causing the bug?
The other part of the complication is that when any developer fixes a bug, there's a chance that the fix breaks something else, and it may not appear to players to be even vaguely related to the fix. Without a huge qa team and a very long testing period, you're not going to be able to test every possible combination in a game like this. That's also true when developing new features.
The complication for the devs is they appear to have inherited code they don't really understand. Using the community for QA makes a cheaper alternative for them.
Now I'm not an expert on this, but the flow charts you are describing I'd consider to be on the scripting level. The engine was/is developed by the parent/sibling company Avalanche Studios, but obviously needed/needs to be adapted by Expansive Worlds, at least based on what I know, which requires "actual" programming.
Bugs can be introduced during any of these three stages.
Ideally, the code is nicely compartmentalized, well documented and non-redundant (but then at the same time necessarily interconnected), and in many aspects it probably is, but as I'd infer from bugs affecting certain reserves and not others, many things are simply copied and problems fixed on the fly on an individual basis and "downstream" and perhaps need to be fixed each time another engine update comes along.
Some bugs can be hardware specific (probably the smallest part).
Some bugs will be save game specific (which is why they'd need large public betas, which would probably collide with their release schedule of pushing out new content regularly, an obvious decision for profit and against quality, as it would become even more obvious that they are pushing out new releases despite known bugs).
Many bugs are there for everyone (whether they encounter them or not).
Without having any actual insight, I'd guess that cleaning up/consolidating/rewriting all the code could be a task that takes years and ideally you could stick to one version of the parent engine.
Would that be possible? Probably.
Would that be feasible? Probably not, especially not financially.
Could they do a lot better? Probably, especially if they'd be willing to temporally forgo some short term profit. I doubt they could fix all underlying issues, but they definitely could make sure to offer less bug-ridden releases.
So I'd agree with BJWyler, even if he kept it short.
In general, I will say that more often than not, bugs are seemingly simple but are not simple to fix. The simplest example I can think of is let's say you isolate the source of a bug down to a single line of code. That line of code calls a function and something in that function is causing the return of unexpected values. Sure, you can fix that function so it works correctly for this case, but that function could be called from hundreds of other places, so by changing that code, you open up the possibility of bugs in hundreds of other areas. Let's say you decide that it needs to be done, but it's going to require passing another parameter to that function. Now, on top of the potential bugs, you have to locate all the places that call that function and change the parameters... and likely there will be callers of that function in code that you personally don't deal with. You might have to involve a dozen other people who handle some specific area of the overall code... and each of those people are going to similar problems trying to work in the changes just for your simple little bug. Each will have to debug their own systems, resolve their own issues, document it, update their branch, and of course in doing so, they could end up in the same boat you were in initially... and the cycle continues over and over again until everything is finally stabilized.
Unless you pry one of the devs away from fixing stuff, you're never going to get the kind of insider knowledge that would answer your questions. Everyone else is just guessing. But that appears to be what the OP was asking for: informed guesses.
Different game, different engine, but some interesting info on bug hunting here:
https://www.kotaku.com.au/2019/12/outer-worlds-developer-finds-bug-that-caused-companions-to-climb-infinite-ladders-until-they-died/