An Open Letter to TaleWorlds from the Kingdoms of Arda team, and the Total-Conversion Mod Community about our concerns and frustrations with Bannerlor

Users who are viewing this thread

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 :smile: 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? :razz:
first time I've heard someone mentioned both context from computer science and civil engineering. Are you also a transferred SDE from CE?
 
first time I've heard someone mentioned both context from computer science and civil engineering. Are you also a transferred SDE from CE?
No, just CS/SE for me. I like reading about Architecture and Civil Engineering, though. I even like to follow various projects as if I am a stakeholder... But that's just me being autistic :smile:

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. :party:
Sorry but you don't understand anything about Software Engineering and it is so obvious... Yet, what gets to me is that you still have "ideas" about how Software Development should happen... You talk too much on this topic for a person who cannot tell Debugging from Testing.
 
Sorry but you don't understand anything about Software Engineering and it is so obvious... Yet, what gets to me is that you still have "ideas" about how Software Development should happen... You talk too much on this topic for a person who cannot tell Debugging from Testing.
My bad, looking forward for more. Big fan.
 
Please refrain from double posts, edit your old posts instead

Sorry but you don't understand anything about forum posting and it is so obvious... Yet, what gets to me is that you still have "ideas" about how forum posting should happen... You talk too much on this topic for a person who cannot tell double posting from replying with inspirational new ideas to multiple posters.
 
Sorry but you don't understand anything about forum posting and it is so obvious... Yet, what gets to me is that you still have "ideas" about how forum posting should happen... You talk too much on this topic for a person who cannot tell double posting from replying with inspirational new ideas to multiple posters.

tenor.gif
 
Sorry but you don't understand anything about forum posting and it is so obvious... Yet, what gets to me is that you still have "ideas" about how forum posting should happen... You talk too much on this topic for a person who cannot tell double posting from replying with inspirational new ideas to multiple posters.
I don't have any ideas about how forum posting should happen, and I cannot care less. If, on the other hand you catch me telling other people how they should post on the forum; that should perhaps piss you off... Do you get the difference? :smile:
 
Your lack of self awareness is truly gold.

I'm sorry mr. IQ. Please do not let this stop you from posting on the forums, your copy pasta material is of excellent quality and this forum badly needs some new stuff.
 
Your lack of self awareness is truly gold.

I'm sorry mr. IQ. Please do not let this stop you from posting on the forums, your copy pasta material is of excellent quality and this forum badly needs some new stuff.
Copy paste material? Did I accidentally post the same message twice? I don't even know what went wrong, tbh.

By the way I have very low social intelligence, and am on the Autism Spectrum. I understand most things only literally, (cannot read poems, do not get them) and miss the attached social cues. Therefore; when you make fun of how stupid I am; you actually are making fun of how stupid I am. Like, making fun of a blind person for not being able to see. Don't get me wrong, I enjoy a good joke (when I actually get it.) But I am not sure if this should be socially acceptable.
 
Last edited:
Copy paste material? Did I accidentally post the same message twice? I don't even know what went wrong, thb.

By the way I have very low social intelligence, and am on the Autism Spectrum. I understand most things only literally, (cannot read poems, do not get them) and miss the attached social cues. Therefore; when you make fun of how stupid I am; you actually are making fun of how stupid I am. Like, making fun of a blind person for not being able to see. Don't get me wrong, I enjoy a good joke (when I actually get it.) But I am not sure if this should be socially acceptable.
You were just being salty by calling people randomly 'You don't understand anything about Software Engineering'.
You don't know which background they have on this field and even though you have fair points, you don't need to be salty about that. I don't think anyone disagreeing with you directly anyway.

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.
The thing is, you don't have to follow SE/SD principles if you are doing something as a black-box. Only reason why we are able to criticize TW is that we are able to see it's source code right now ( somewhat part of it's source at least ). Do you think other games have flawless codebases? I highly doubt. But of course, this doesn't justify the bad practices and bad codebase TW has. I'm just saying this because it's highly unrealistic to expect clean code and super planned architecture from mid-sized projects that were under development for many years. Even if you are developing a simple REST API, things can go out of hand super quickly if you are switching teams every now and then and if your codebase is 8 years old. And REST API's are usually basic CRUD operations. That's why I used that example. As you may guess, making a game is more challenging since you have to think about "fun" aspect of the product as well as it's an optimization and you also have to catch up with trends in terms of graphics if you are not specificly developing a product that is outside of the graphics pop-culture (i.e. Minecraft is an example, shined without having fancy graphics - kids play or not, it's a success story )
In real-life, especially in Game Development, you may not always have the best circumstances. You may have to do something as quickly as possible. Since this discussion is still ongoing, I will give you a code snippet. Don't read below, just try to understand it first - I'm even giving it with its comments-
C:
float someFunction( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the ****?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//    y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}
Assuming that you already knew this or now had a chance to look at it: this is a code piece from Quake III Arena. It's Fast Inverse Square Root function. Does it look like a Fast InvSqr? Hell no. But it's doing the job. And it's doing that job flawlessly for that particular game and function. Now you can say "This is unreadable,thats bad practice, even naming is bad" etc all day long. But this is actually ingenious. And there are bunch of things like this from Carmack and his team. They didn't always follow up mainstream SD/SE principles. They shaped the situation based on their needs. I'm, obviously, not comparing TW's mess with genius designs in Quake or Doom but you can guess where I'm getting at. Lower your expectation in terms of clean code while looking at the game's code.
Also, you have to consider the position TW was and still in. Turkey isn't the rising star of Game Development. Especially if you consider first M&B's Turkey back in those days, you can clearly see why "being a game developer" was equivalent to being a garbage collector or similar. It was disrespected and didn't considered as a real job. And TW was one of the first companies in there to create it's own know-how - which is the reason why we are seeing so many strange pattern around the codebase. But again, that's okay - as long as it works properly and as long as it doesn't generate weird excuses like "Oh we can't do that". That being said, TW is already at the point of no return. So they cannot create a new architecture for the game now. So you might ask, whats the point of this letter? Point is, TW can get their **** together now and at least change some minor stuff so that it can support mods and the modding community.
 
Look, being on the spectrum doesn't magically shield you from criticism in a public forum, we can discuss why games might not fall in the same category as the programs you have worked on before without name-calling or self-important drivel. At this point we're asking for the bare minimum to make modding fair and fun in Mount&Blade 2, we want to get stable tools and modular components that we can take away and remodel freely to a certain degree without everything failing apart. Games like this one don't have unit tests as you know them, maybe they all suck or maybe there's a reason. Who knows? I think the problems in the sequel don't stem from code quality, they should start by listening to the playerbase.

Respect and trying to understand other people's perspectives and experiences goes first. So please, try to avoid telling people with other views that they suck, because it looks like troll bait.

Let's keep it civil and interesting, in a good way.
 
You were just being salty by calling people randomly 'You don't understand anything about Software Engineering'.
I am pretty sure I did it arbitrarily. I react poorly to people who try to argue with professionals, about their profession. Whenever someone starts argueing with me about SE, I immediately assume they are also engineers and try to discuss the issue accordingly. But when it becomes obvious that they are trying to teach me about engineering without an engineering background, well... That's when I react poorly. And if you wonder how I can be sure if someone has (at least proper) engineering background, please keep reading...
The thing is, you don't have to follow SE/SD principles if you are doing something as a black-box.
I want to unsee this :smile: It is wrong for a multitude of reasons. I hope you rethink it some other time. But I will only correct "black-box" -> "closed source." The former only has meaning in the context of Testing.
Only reason why we are able to criticize TW is that we are able to see it's source code right now ( somewhat part of it's source at least ).
This might be true for some. But if you look at my post from pretty much a year ago (soon after the game released, without seeing a single line of code), you will find that I had already complained about Testing and QA issues, and had inferred that TW does not follow SE principles adequately. I also mentioned there that it is quite unlikely for TW to deliver the game within a year, and how they are likely caught up in the infamous 20:80 trap. As SE consultant and having led multiple SE teams (and depts.) in the past; being able to see these things comes with the territory.
Do you think other games have flawless codebases?
No, I think I already mentioned on this thread that these issues affect most gaming studios.
Even if you are developing a simple REST API, things can go out of hand super quickly if you are switching teams every now and then and if your codebase is 8 years old. And REST API's are usually basic CRUD operations.
I swear I am not trying to be an *******, but I just have to correct something out of topic here. What you mean to say by "REST API" here is actually "HTTP API." RESTfulness is a property of a system, not an API. I know lots of people misuse the term this way, but you can do a quick Google search to see what I mean.
They shaped the situation based on their needs. I'm, obviously, not comparing TW's mess with genius designs in Quake or Doom but you can guess where I'm getting at. Lower your expectation in terms of clean code while looking at the game's code.
Let us not confuse genius coding solutions with adherence to engineering principles. Being a coding star does not absolve anyone's work from being principled and well-tested. Indeed, the opposite is true; i.e. principled and well-tested work makes a coding star.
Also, you have to consider the position TW was and still in. Turkey isn't the rising star of Game Development. Especially if you consider first M&B's Turkey back in those days, you can clearly see why "being a game developer" was equivalent to being a garbage collector or similar.
I have to somewhat disagree. I remember my first job was located at ODTU Technokent, right next to (you guessed it) TW studios; and how we envied people working there for doing something so much fun and awesome. Back in those days you would not get a place at Technokent without some promising project. So, I don't really think it was seen as "garbage" work.

Apart from the nitpicking, I think we both see similar problems. Where we diverge is our idea about how strictly and under which circumstances engineering principles should be followed. I say it applies everywhere, under any circumstance, regardless of whether your source is open or not (this last point should have been obvious.) To be perfectly honest with you, I would not hire an engineer who said "testing can be optional" during an interview. My advice to you is to never say such a thing if you interview with European or American companies.

I know how Ipek and Armagan created this out of thin air with nothing but sheer will and hard-f*ing-work, and we cheered them on all the way. For us, they were the pioneers we looked up to; and M&B was something to be proud of. I loved past M&B games, I love Bannerlord and I am sure I will love next thing that they produce. But none of these matter as engineering is not subject to sentiment. If TW employed some principled approach from the very beginning, we would already have a much better game released by now.
 
I want to unsee this :smile: It is wrong for a multitude of reasons. I hope you rethink it some other time. But I will only correct "black-box" -> "closed source." The former only has meaning in the context of Testing.
I'm talking about the code and practices. I explained to you why this is not the case in real life by giving you a real example. You are claiming that you are a Software Engineer but it appears that you never worked on a project that is tightly time-bounded. Do what works - make it pretty later is always the main approach whether it's a military project or game. As long as the deadline is close and you are outnumbered, you don't care about patterns and go full-on waterfall most of the time.
I also mentioned there that it is quite unlikely for TW to deliver the game within a year
That's hardly a skill - foresee that TW won't be able to deliver a game within a year. I'm a Software Engineer but even non-engineers were able to guess that. It's not rocket science.
I swear I am not trying to be an *******, but I just have to correct something out of topic here. What you mean to say by "REST API" here is actually "HTTP API." RESTfulness is a property of a system, not an API. I know lots of people misuse the term this way, but you can do a quick Google search to see what I mean.
No? I know the difference and I used REST API as a general description. You are again assuming what I'm trying to say. Don't do that.
Let us not confuse genius coding solutions with adherence to engineering principles. Being a coding star does not absolve anyone's work from being principled and well-tested. Indeed, the opposite is true; i.e. principled and well-tested work makes a coding star.
Genius coding solutions have nothing to do with following engineering principles. For example, you can have a really robust and functional codebase that is not following Liskov substitution principle and greening all the test cases. You can also have something that fulfils the latter but then you have to spend more time on the project because designing and decision making also takes time.
I have to somewhat disagree. I remember my first job was located at ODTU Technokent, right next to (you guessed it) TW studios; and how we envied people working there for doing something so much fun and awesome. Back in those days you would not get a place at Technokent without some promising project. So, I don't really think it was seen as "garbage" work.
Feel free to disagree but I'm not talking about the times of Teknokent - I'm not talking about 2010-to our date. Last 10-11 years, they were already popular and the game was selling quite good. I'm talking about the times when Armagan first decided to go for it. We are from the same University and I had chat with his thesis supervisor professor. Apart from other stuff, he said "He was quite clever and knew what he was doing. I told him that he shouldn't waste his time with games and should join to military simulation companies or should stay here and work with me on SIGGRAPH papers. But he wanted to make games and his business took off very rapidly" - so at that time, even "educated" people looked down upon Game development and dismissed the idea. Now you can think about how average joe thought about games back in those days. And even in Teknokent times, whether you envied or not, TW employees were getting less salary than what their peers were getting in other companies. I'm not tracking their salary or any salary bracket in Turkey anymore, but I'm pretty sure they are still not getting a fancy salary - compared to Ubisoft Montreal vs Montreal based company.
My advice to you is to never say such a thing if you interview with European or American companies.
Tbh, You are not in a position to advise me anything actually since you have no idea about my experience or whatsoever. Still, to explain what exactly is going on, I never said: "testing can be optional". Again, you falsely assumed that I said this.

You are keep saying what they should have and I'm telling you what they have right now and converting this to that is not possible in any near future. That ship is sailed long ago. Unless you are not aiming to become their consultant or whatever in the next game, I think there is no point in discussing this. You should go back to the topic and provide direct suggestions to TW about how they can make this game more moddable. But don't suggest things like "Architecture change" since you are not Ken and this is not a Barbie World. Be realistic and do your suggestions based on that. You may be saying "Why? I don't care about modding" then you can just drop it. No need to discuss further that.
 
I want to unsee this :smile: It is wrong for a multitude of reasons. I hope you rethink it some other time. But I will only correct "black-box" -> "closed source." The former only has meaning in the context of Testing.
I agree with all your wonderful thoughts on this matter and your opponent is inadequate.
Poorly written but optimized code is very rarely needed. I've seen some hotshot coders do this just because they like to write obscure, barely readable code.
 
Most of the games you like don't have super pretty codebases, they go from I'll-need-to-ask-whoever-made-this to alright. Maybe you should work on some or read on how some of the best games ever made were developed before preaching dogmatically about things you haven't experienced. Idealism is cool, but it falls flat when there are other constraints.

If someone is rushing to ship by Christmas or E3 they are not going to make it pretty, the technical requirements are laid down at the start when the project is greenlit and are roughly followed and changed when they don't make sense anymore.

I'd like to see you change the industry by berating some senior dev for not following your precepts during crunch week, but I have seen way better games with worse code, and they are probably more fun to mod.
 
Back
Top Bottom