Yeah, they probably had their reasons (and it's easy to criticize in retrospective) but I would have just expanded Warband by seeing and taking advantage of what popular mods do. They had a clear direction and a good base. Now they are playing catch up with older modded versions and their own game. We'll see how that plays out.
-
If you are reporting a bug, please head over to our Technical Support section for Bannerlord.
An Open Letter to TaleWorlds from the Kingdoms of Arda team, and the Total-Conversion Mod Community about our concerns and frustrations with Bannerlor
- Thread starter Gandamula
- Start date
Users who are viewing this thread
Just my own opinion that the head developer really sees the new combat system as the flagship feature of this next gen iteration and seriously underestimated peoples love of strategic/rpg/kingdom immersion. Possibly believing they could either do it all after the fact or worse, relying on modders to fufill all the rest
I don't think they are playing catch up with Warband and its mods at all, they are not a reference point for the people in charge.
They appear to be focused on the current state of their game and the most broken systems in some kind of a permanent crisis mode that doesn't care about the history of the game. Curiously, they also occasionally come up with completely new ideas like regional battle maps that no one asked for, nor are they easy to do. It's hard to tell why.
They appear to be focused on the current state of their game and the most broken systems in some kind of a permanent crisis mode that doesn't care about the history of the game. Curiously, they also occasionally come up with completely new ideas like regional battle maps that no one asked for, nor are they easy to do. It's hard to tell why.
Which to me is extremely misguided since the new combat system is worse than the old one from Warband (although I guess there's some degree of subjectivity involved in that evaluation).
This is just my personal experience, and I have absolutely no idea about how things are in Taleworlds, but about 70% of programmers in my company are incompetent coffee-posting imbeciles, and it's not like it's the company's fault for hiring them. Those people know how to make themselves look impressive to get the job, and there's no feasible way to test their actual coding abilities before hiring them, as it would take too much time. Usually you find the mess they've made well into the development process (the client's complaints will make sure you do), and by that point it's too late to do anything about it, other than patching over them of course.
The people "on top" are usually not skilled in programming either. It's usually just some tard with a bunch of certificates who only know about theories. You're lucky if they have the sense to consult a senior programmer before implementing things, but most of the time they're just pushing this new modern paradigm they read a few times on their Medium Digest feed.
Again, I have no idea how things are in Taleworlds. They might not have any of these problems, but I'd feel sorry if they did.
The people "on top" are usually not skilled in programming either. It's usually just some tard with a bunch of certificates who only know about theories. You're lucky if they have the sense to consult a senior programmer before implementing things, but most of the time they're just pushing this new modern paradigm they read a few times on their Medium Digest feed.
Again, I have no idea how things are in Taleworlds. They might not have any of these problems, but I'd feel sorry if they did.
Companies whose core competence is not software development (many IT companies) are like that - someone has to employ all the mediocre programmers. 
Taleworlds should be different. The problems they have with staffing are probably typical of development hell problems - the most experienced staff left (because they have better things to do then spend a decade on a three-year project), the mediocre ones stayed and the new hires don't have the same level of competence and experience as the veterans. The code base was worked on by all kinds of people with different skill levels - from hotshots to interns, and the work of the interns is why modders complain about poor coding and Taleworlds occasionally needs to rewrite components. So, it's a mixed bag. That's my speculation based onwhat God told me bits and pieces of info.
Taleworlds should be different. The problems they have with staffing are probably typical of development hell problems - the most experienced staff left (because they have better things to do then spend a decade on a three-year project), the mediocre ones stayed and the new hires don't have the same level of competence and experience as the veterans. The code base was worked on by all kinds of people with different skill levels - from hotshots to interns, and the work of the interns is why modders complain about poor coding and Taleworlds occasionally needs to rewrite components. So, it's a mixed bag. That's my speculation based on
Well, the company I'm in is a software development company, but it's not a game dev company. Maybe the game dev world takes it more seriously? Or maybe programmers in Turkey are way better than here? I wouldn't know. Though I wouldn't be surprised if it turned out they have the same problem. This is why modders usually do a better job. Because they care, and are skilled enough to do it as a hobby.
While I do agree nobody asked for it, I think we can all agree that regional battle maps is a great addition to the game.
Not quite - me, and several other people that I know, asked for it. We asked for procedural maps but we also offered this as a solution in-case if procedural maps will be an issue for them to implement. And I think any sane person can agree that random battle map throwing is a huge step back from Warband's more predictable UX friendly maps. I'm not saying that Warband's procedural maps were good - but consistency is the key for games and randomness only frustrates players and this is a golden rule in game design that TW forgets continuously in Bannerlord for some reason.
Hello. Please find the reply to the open letter in the original topic that was created in the modding section:
I harshly criticise TW development methodology, and this thread kind of proved my point for me. That said, I find your criticism unfair. TW is putting a lot of effort into their product; it is just that they do not follow even the simplest of Software Engineering principles. I have seen some code that is simply outrageous. Magic values, code duplication, etc... Why an engineer writes such code and others allow it is beyond me. But this epidemic of malpractice is quite widespread in the world of Software, especially across gaming studios.
Sorry, but it sounds like you do not have much experience in Software Validation.
First of all, one has to create testable code and if your design or implementation does not allow testing for any reason, you need to revisit your design or implementation accordingly. This is analogous to the testability requirement of any scientific argument. If it cannot be tested, how do we know it is correct, right?
Unit testing involves taking units of programming (whatever it may refer to in your paradigm) and testing them in isolation. So unless "a combat based 3d sandbox RPG" is written as a single unit (cannot be done anyway,) then unit testing this software is no different than unit testing any other software. The statement "there are so many possibilities that it's impossible to test them all" also has no place in unit testing (or any other form of white-box test) unless, again, there is a magical unit that does everything.
When testing "a combat based 3d sandbox RPG," the tricky part would be your integration tests where you test the interplay of your units; and system tests (end-to-end, performance, stress, etc.) which should still take "combat," "sandbox" and "RPG" modules (or packages, etc) separately as they can be considered separete games within a composite game. Indeed, they actually are.
What you describe as "Live testing" is not a valid test strategy. One of the major requirements of testing is determinism; i.e. the same test suite should always produce exactly the same results for the same source code. This requirement also rules out "Beta testing" from being a formal test. By the way, before you object: there are ways of writing non-deterministic code that can be tested deterministically.
Also, in all my life as a Software Engineer, I have never heard of "launching some program to see if it can load older files" as a method for testing. Seriously, wtf? What kind of test is this? What is the scope of this test; as in, when this test fails, what do you say failed? The whole product? How do you automate this? In which company, university, institution do they accept this as a valid approach for Software Validation?
Finally, modern games are NOT marvels of engineering; they are often buggy as hell and unoptimised... There is some Software out there, particularly AI software like Google that can be considered a marvel. When it comes to games, it is pretty much just the hardware that does the magic; they have become so amazingly fast that nowadays they can run even some badly optimised sloppy code smoothly at 1080p. For a guy whose first computer had a state-of-the-art 2 MB RAM, hardware today is f*ing unbelievable
lol
Unit testing isn't as common in video game development because the individual low level in-out systems are usually very simple, but the majority of the issues in games (and simulations like bannerlord in particular) are the high level scripts that access tonnes of data at once. You can't really unit test something when it relies on data that's been mutated by 100 other scripts.
What is applicable to corporate software (which is usually about security and usability) isn't always applicable to video games (which are about spectacle and fun)
Finally, modern games are NOT marvels of engineering; they are often buggy as hell and unoptimised... There is some Software out there, particularly AI software like Google that can be considered a marvel. When it comes to games, it is pretty much just the hardware that does the magic; they have become so amazingly fast that nowadays they can run even some badly optimised sloppy code smoothly at 1080p. For a guy whose first computer had a state-of-the-art 2 MB RAM, hardware today is f*ing unbelievable
Id disagree here and say that Mount and Blade 1 is a software marvel -that being its doing (done) something none of its peers have come close to -that is determining physics based combat - by that i mean physics relative to its time -not Hellish Quart level. Physics meaning and being determined by each actual swing needed to hit an accurate hit box with angle, speed direction and blocks of both attacker and target all being accounted for in real time not only for a melee soldier but horse and archer on a grand scale -from the hundreds to possibly thousands of bots. Doing that without melting a CPU -especially in M&B 1's heyday was indeed a feat and ive yet to seen it replicated by anyone else (total war is not unit based but dice rolls) even with todays flagship hardware.
What does "individual low level in-out systems" even mean? Since when "very simple" an excuse for not testing??
What do you mean by "corporate software"?
The statement "You can't really unit test something when it relies on data that's been mutated by 100 other scripts." by itself shows that you do not understand what unit testing is and how it is carried out.
Seriously, it is obvious that you are not a Software Engineer; why do you discuss a topic you do not understand?
Not even Armagan would accept that Mount and Blade is a software marvel. This has to be hyperbole. Yes, M&B was innovative, entertaining, etc; but a marvel?? No... I mean if you consider Mount and Blade a marvel, how would you categorise AlphaGo?
Last edited:
Your speaking for the Company leader but accusing me of hyperbole? How about sticking to the facts --name me any game coming close to the above mentioned anywhere near that era
I'd say a company which doesn't hire QA professionals. In my experience, the testing is always done by people in the company who have nothing better to do, as the programmers are busy doing the coding. If your programmers happen to be unskilled scums (and the degree can be utterly astonishing as I'm sure you're aware), they won't even make sure if their own code works properly at all. As long as it doesn't fail to compile and it shows stuff appearing, it's usually okay for them. The worst I've seen in recent memory was this idiot who couldn't even do string comparison properly, and didn't even check it.
Then the testers are just told about a feature and see if it works. If it gives result, they will put a check on it. They wouldn't check the code, the thing that's related to modding, because they're not programmers. Then have a senior programmer do it then. Well, senior programmers usually wouldn't want to, as it is painful to see other people's code. They're usually too busy doing other tasks anyway.
Black Magic
Anyway, you missed the point in there. You cannot test 3D Sandbox RPG game with unit tests only. You cannot do that for any software. Isolated or not, individual units can work flawlessly in an isolated environment and after integration, they can work like crap. Based on your perspective all software can be tested via Unit testing since it's "isolating" them enough. That's not the case and that's a thing that eliminates you instantly if you say in your interview.
Unlike mainstream software, games also need Scenario and Exploratory Testing as well. But what he meant by "live testing" is actually end-to-end testing. So yes, the game does need "live" testing. I think they do have basic E2E tests but coverage is low. Most of the individual fixes are manually tested.
A game like Bannerlord requires a lot of testing. Unit tests, Integration tests, end-to-end tests, Scenario tests, Exploratory tests even good-old playtest etc. You can indeed do all of them. If you have the manpower, time and know-how. TW had the time. They didn't have the manpower or know-how. And pouring resource into this would have dire consequences. Yes, it's good for the future and should have been decided at the start of the project so that right now they wouldn't have this mushy code but it's too late to turn back to the whiteboard. They have to live with what they have.
Also, it makes zero sense to compare AlphaGo/AI software to normal games. They serve to a different audience and offers different purpose. They are not following the same or even similar SE pattern. Also, AlphaGo's aim is not to make the games' fun or visually appealing.
Of course you cannot test this game, or any other piece of Software only with unit tests, as those only test units. You also need integration tests and finally various system tests, including end-to-end tests. However, I think "live testing" as he described involves running the entire software manually.
Besides, an end-to-end test should never test the entire system (even though they are black-box system tests), they should only test relevant functionality. I.e. an end-to-end test should fail if and only if a component directly related to that functionality fails. Therefore, unless your software only has a single functionality; you should not be running your entire software for any end-to-end test.
Outside some small points we pretty much agree on everything, including why and how TW failed to deliver a better game. I am not sure about the manpower bit because I do not know how many they are; but they had so many years. I believe the biggest issue, however, is know-how. Fundamental principles of SE have not been followed for this project. It is clear as day to me.
By the way, the comparison between AlphaGo and M&B came from the argument that "M&B is a marvel of Software Engineering", which led me to give an example for an actual marvel there. Otherwise, of course I know they are not comparable by any means
I mean imagine I dig a hole in my backyard and call it a marvel of Civil Engineering, and then you sarcastically ask "how about Eiffel Tower?" and I respond "sorry but it doesn't make sense to compare a ditch to a tower." Would you admit that the hole is actually a marvel? I hate to hear that such companies exist, but I also do not wish TW to be one of them. In SD teams I led, I never accepted code that is not properly tested. But I also worked in industries where an error in production can be extremely damaging. Anyhow, regardless of whether you are building a two-storey house or a hundred-storey tower; you should build it properly.
I agree with trying to make decoupled components that are clean and easy to understand. But from their point of view most of it won't get reused in the next project, nobody is going to look at it again after the gold disc has been burned, and people are overworked enough that making it work at all feels like a victory. There are no hard specifications here, most of game development is an iterative process of scrapped plans, assets and code that didn't go anywhere. You can't see what it's going to stick until you try it.
The more I learn about how games, game engines and their ancillary tooling works the more I appreciate the amount of painstaking optimization and tricks that go into them. Modern programs or your typical web app aren't even in the same league of shaving milliseconds, counting cache misses or exploiting idle time in the GPU. The amount of profiling and niche knowledge that goes into your average AA game is pretty insane. I'm not even qualified to talk about it. But safety isn't even a top five priority here, anything that may slow it down gets thrown away like in a race car.
You can talk about armchair theory and test coverage all you want. The fact that whole teams of qualified humans replaying the game for months are needed here and nowhere else should tell you enough. Good luck covering all the states of a multi-threaded and long-running state machine spanning more than one million lines of changing code.
Single-stepping through a single frame in a debugger can take you weeks, and no one knows how the whole thing really-really works.
The more I learn about how games, game engines and their ancillary tooling works the more I appreciate the amount of painstaking optimization and tricks that go into them. Modern programs or your typical web app aren't even in the same league of shaving milliseconds, counting cache misses or exploiting idle time in the GPU. The amount of profiling and niche knowledge that goes into your average AA game is pretty insane. I'm not even qualified to talk about it. But safety isn't even a top five priority here, anything that may slow it down gets thrown away like in a race car.
You can talk about armchair theory and test coverage all you want. The fact that whole teams of qualified humans replaying the game for months are needed here and nowhere else should tell you enough. Good luck covering all the states of a multi-threaded and long-running state machine spanning more than one million lines of changing code.
Single-stepping through a single frame in a debugger can take you weeks, and no one knows how the whole thing really-really works.
Last edited:
Similar threads
