SP - General Why Taleworlds still care about crashing?

[Sukuna Tempest]

Why they still care about crashing? If they make the implements in the game faster I'm sure a lot of people agree with lose their saves. We already have 2 versions, if they make the beta incompatible with the main version don't looks like a problem to me. If someone don't want to lose the save, stay in the current version!

 

[Tryvenyal]

I disagree.

Craches needs to prio one but I am still wondering why very basic exceptions happen so often, why TW does not seem to do even multi/several-scenario unittests to cover top 10-20 potential issues with what they do and catches exceptions they can easely handle another way. Spending more time on the code makes them spending far less time on that same code in the future.

Bringing a save backwards in gameversion probably breaks it/make it lose alot content. Bringing a save forward should work unless TW changes the format of the save and just add/insert sections for new content. if the format of the savefile is changed, I´m fine with losing my savefile for future versions but this should be told in capital letters in the pathnotes.

 

[Sukuna Tempest]

I disagree.

Why do you disagree?

I´m fine with losing my savefile for future versions but this should be told in capital letters in the pathnotes.

I'm talking about this, if they do something like this why not?

 

[TengriBless]

I don't care for technical issues in EA games so long as they don't impede development. Just make the game into what it's supposed to be and then you can think about making it work smoothly. That's just common sense.

Although I may be biased in saying this as I was probably touched by Bug Jesus as a child and therefore have suffered little to no crashes or glitches in my games.

But unfortunately all this points to them considering the game pretty much finished and that's why they're "polishing" it to the best of their subpar ability instead of actually making any meaningful additions.

 

[Tryvenyal]

Why do you disagree?

Because you argument that they should just ignore chrashes. Chrashes that occurs and can easely be recreated must be solved! Continuing building on code that easely craches makes it alot harder to solve the issue in the future. If it takes an extra week do test and QA top 20 scenarios of a new piece of code, then it takes a month to solve it half a year later and probably with a less good solution!

On the same time, "Chrashes that occurs and can easely be recreated" is a huge QA issue when happening in the frequence it does! if 90% were found by the TW QA prior to release, so much time would be saved!

 

[Grank]

Why wouldn't you care about crash? It's the absolute worst kind of bug. Ignoring app-crashing errors will bring you a lot of pain down the road, because a crash indicates that something is horribly wrong. Sure you can just make the application throw an exception and let the application keep running, but it will lead to a bogged down log and make debugging anything difficult and frustrating.

As it happens, early this year I took over a ****ty app made by absolute imbeciles because they ran off from the job. So for your perspective, it took me 2 months just fixing explicit errors, caused me to overhaul a main component of the system for 3 months before any useful feature could be developed, and lags the entire development process by around 2 months. Now imagine this. A real time video game is way more complicated than this system I'm working on.

 

[Sukuna Tempest]

@Grank @Tryvenyal
I'm not aware of programming, thanks for explaining.
I think I was more talking about compatibility with saves, but yeah crashes need to be fixed.

 

[Grank]

I think I was more talking about compatibility with saves

On that matter, think about it this way. Pumping out a lot of versions quickly means your players will play various versions within the same period. Let's say within a month they released 5 patches. Some players play the latest update, but some still remain in the older updates because they're still playing their campaigns. Then they all see bugs and report them. It's going to be hectic keeping track of 5 versions at the same time.

Bug A is reported on Latest-3 patch. Is it already fixed on Latest-2 patch? How about Latest itself? Then say Bug A is fixed. Since it was reported on Latest-3 patch, where should be put that patch on? Okay put it on Latest+1 because of chronological order. Latest+1 will be released next week. One week later people are still reporting Bug A because they're playing, say, patch Latest-1.

So it's better to pump things out not so quickly. You give time for players to test that version, and give the devs time to analyze that version properly.

 

[Kentucky 『 ＨＥＩＧＵＩ 』 James]

why TW does not seem to do even multi/several-scenario unittests to cover top 10-20 potential issues with what they do and catches exceptions they can easely handle another way.

Unit tests in the gaming industry? ho ho ho

I've heard from people who work on games that the standards are far far worse than any other type of tech job. Basic stuff you would expect from a large project like a similar coding paradigm or even just tests in general are often absent from video game projects, especially the big budget ones. Part of this is because nobody is going to sue you or lose millions of dollars if a game crashes, but also because the origin of a lot of these companies is small informal college projects between random nerds.

Having looked at some of Armagan's earliest work (back in almost 2001), he is a weird coder. He likes coding small pet applications to reduce his workload, but ignoring crashes or widespread errors deep in the code so long as the game runs 90% of the time. To be honest this is how most big gaming companies work nowadays, but in Bannerlord it is accentuated because of how many mechanics they have added.

So it's better to pump things out not so quickly. You give time for players to test that version, and give the devs time to analyze that version properly.

I feel like they should do the opposite actually. Funnelling into a branch hole where the game doesn't even compile for 3 months is like how I used to code. I guess it's too late now, but I would almost like there to be a continuous integration type deal where you can choose to load code binaries directly from a github and the whole project is made mostly functional in the main branch on a weekly or even daily basis (but I don't know how much branching they're doing internally)

The problem I feel now is that people are reporting bugs for versions of the game that no longer exist. If the last patch was say 3 months ago, it's not like the developers are just sitting on their asses waiting for bug reports to roll in, they've probably already started on other things, making it even harder for them to revert all that to find the bug report made back in july. The bigger the gap between patches the more extreme this will become, to the point where the bug reports are functionally useless.

 

[Tryvenyal]

Unit tests in the gaming industry? ho ho ho

I've heard from people who work on games that the standards are far far worse than any other type of tech job. Basic stuff you would expect from a large project like a similar coding paradigm or even just tests in general are often absent from video game projects, especially the big budget ones. Part of this is because nobody is going to sue you or lose millions of dollars if a game crashes, but also because the origin of a lot of these companies is small informal college projects between random nerds.

I have realized this is the case

I'm a developer, workingexp from telecom and public service sectors mainly where testing is 3-6 layered(Unit-,system-,intigration-,performance-, acceptance- and smoke- test. Intigration, performance and smoke removed when small independent systems or small fixes).
To not even unittest most common scenarios is so unthinkable for me!

I understund there are not 6 levels or even 3!! But to not have even UT and ST is biting yourself!

Whitout even concidering production impact(legal, data cleanup, badwill, downtime etc), these effects is very bad for any dev-team:
- To never move forward. Iteration after iteration, you work on the same piece of code. Fixing the fix for for the fix for the fix for the error raised because a fix....
- 2 days QA today is a month in half a year. Probable with a worse result
- Niether as an indiviudal or as a team, you learn or grow without closing your work
- Expensive. Tested code is cheap code.
- With a good level of QA comes both refactoring and performance. At least to a degree.