A realistic Zone of Control is actually very easy to implement without increasing complexity

[Death2Tyrants]

Personally I believe that a general design goal is to produce simple and elegant game mechanics. Complex models need serious justifications in how they add to gameplay and fun. They also tend to fail in more unforeseen ways and then need to be patched up with the design equivalent of duct tape.
There are a minority of players who like complex models and are hypnotized by the complexity, not the resulting gameplay benefits. But most players are not interested in watching clockworks, they want interesting and fun gameplay regardless of the degree of modelling behind it.
The best designs are simple illusions of complex mechanisms, virtual Potemkin villages.

+1

 

[Death2Tyrants]

Yeah this is true. Adding zones of control would be a huge undertaking beyond the original scope of the game. Also they are missing literally tons of much more easily to add features that they apparently don't intend to add so there isn't a chance in hell of something like zones of control being added. I am also not sure even a modder could make the game work well with this type of mod either because I just don't feel the basic gameplay mechanics required for this are even part of the game.

Yea that's why I'm not talking about creating artificial zones of control. What I'm proposing is organic. A ZoC will naturally arise once armies cannot survive without first neutralizing it.

 

[Terco_Viejo]

In fact, a great mod of Warband called Custom Commander already has this function.

Yes, there are some mods for Warband that implemented that idea; I was referring to this one in particular. Unfriendly Territory has taken Custom Commander's idea for sure.

 

[darksoulshin]

There's no evidence that developers would ever read your blobs of text or that they are helpful to them in some way

my suggestions are directed not only to TW developers but also to modders who want to exploit these ideas to make mods.
The usefulness of my suggestion cannot be proved until it is applied, but if in addition to the suggestion I put some examples related to the application of the suggestion with a statistical forecast where it can be done, I would say that I have done more than I owed to to justify the usefulness of my suggestion, or not?

For example, you go on about your hurtboxes, but that line of thinking is unhelpful as adding more would significantly affect performance

I have already replied to another user regarding the "performance" issue.
The CPU load should not increase because the recordings of the hit hurtboxes do not multiply as the hurtboxes multiply, because whether you have 3 hurtboxes or 30, in the end, by an attack, only 1 hurtbox is hit and that hit is recorded.
The CPU load is always a function of the number of soldiers and not of the hurtboxes.

In addition, you aim for increased complexity

Calling it "complexity" is misleading.
It is a different and more realistic system and being more realistic you can act more intuitively to balance it.
The problems of the game due to the lack of balance between fighters of different tiers or between factions is related to the armor system.
If in the system present in the game you do not allow room for a POORLY EQUIPPED unit to defeat a WELL EQUIPPED only through the combat skill, then the system is less balanced.
You will find yourself being able to change only the armor value and the capacity of the AI which is certainly a much more complex and volatile variable than the simple change of the equipment of the units, which involves only the replacement of a part of armor that covers a few hurtbox with one that protects more for the same armor value.
Then you can act on the localized damage or on the armor value, but at least you have 3 levers to act on.

You can't pretend your style of posting is superior to theirs, it is arguably worse.

I am not saying that my style is superior to theirs, I am saying that many limit themselves to suggesting "variations of parameters" while I tend to propose "new mechanics".
This is because I believe that having more levers available involves less effort in balancing AND at the same time increases the depth of the gameplay.
The single lever is born with the aim of acting mainly on one factor or a problem and will certainly have consequences on something else as well, but to an extent that depends on how well you have built that lever.
In the case under consideration in our comments, the armor system that I propose tends not only to maintain the purpose of the previous one, but to make it more precise in all cases.
So it is not a new lever but an improvement of the old one.

Personally I believe that a general design goal is to produce simple and elegant game mechanics. Complex models need serious justifications in how they add to gameplay and fun.

My mechanics, in implementation, are extremely simple, and the fact that it solves practically all the defects of the current system gives the required reasonableness.
The fact that it balances the relationship between ranged units and shielded melee units and makes SPAM unsuitable for attacks I would say adds to the elegance you speak of.
It also increases the technicality of the fight without making it "more complex" because the only thing it does is warn you that "if you hit the enemy's armor you don't hurt him, instead if you take his bare skin you hurt him, so aim well instead to move the blade at random ".

The best designs are simple illusions of complex mechanisms

The fact that you see the system as complex or that reading it deems it so does not imply that it is, perhaps you are deluding yourself that it is.
What I propose is always INTUITIVE and never counterintuitive and this choice is due to the fact that everything that can be intuited is easy to understand.

If you saw a guy in plate armor would it seem stranger to do him the same damage in both the open and covered areas, or a different damage based on the different cover?
If the games tend towards the second choice, then it is evident that we are trying to devise systems that are not counterintuitive.
Currently what I propose is more intuitive than the one present in the game.
It follows that once in the game you understand it on the fly.
But understanding it on the fly does not mean that the system is not "deep" because what I propose, it seems clear to me, has much more depth than the current one.

 

[Mad Vader]

I'll focus on a single issue, since I'll just repeat myself with the others.

have already replied to another user regarding the "performance" issue.
The CPU load should not increase because the recordings of the hit hurtboxes do not multiply as the hurtboxes multiply, because whether you have 3 hurtboxes or 30, in the end, by an attack, only 1 hurtbox is hit and that hit is recorded.
The CPU load is always a function of the number of soldiers and not of the hurtboxes.

The number of collision checks is generally = #hitboxes * #hurtboxes. I'm sure games like Bannerlord optimize and eliminate some of the checks with fancy algorithms, but you can clearly see at least a linear effect on performance. And there goes your strange argument that the performance is the same - the whole proposal is impractical.

 

[RecursiveHarmony]

The number of collision checks is generally = #hitboxes * #hurtboxes. I'm sure games like Bannerlord optimize and eliminate some of the checks with fancy algorithms, but you can clearly see at least a linear effect on performance. And there goes your strange argument that the performance is the same - the whole proposal is impractical.

Those things also move around when the model is animating or changed its position in the scene.

I have already replied to another user regarding the "performance" issue.
The CPU load should not increase because the recordings of the hit hurtboxes do not multiply as the hurtboxes multiply, because whether you have 3 hurtboxes or 30, in the end, by an attack, only 1 hurtbox is hit and that hit is recorded.
The CPU load is always a function of the number of soldiers and not of the hurtboxes.

I think these kind of thoughts are related to people thinking computer code works like themselves.
When you look at the scene you can see a sword hitting an arm, but, for the code, it's just looping through collision objects to check two of them shares some space partially.

 

[Midnitewolf]

I'll focus on a single issue, since I'll just repeat myself with the others.

The number of collision checks is generally = #hitboxes * #hurtboxes. I'm sure games like Bannerlord optimize and eliminate some of the checks with fancy algorithms, but you can clearly see at least a linear effect on performance. And there goes your strange argument that the performance is the same - the whole proposal is impractical.

I am not an expert but I am pretty sure it doesn't work that way. The CPU actually has to track both the position of the hit boxes and the object being used to hit the hit box. Basically you up the hitboxes to 30 instead of 6, you have the CPU monitoring the possible collision of a object on 30 different interlocked hitboxes per unit instead of 6. Also you would have to track the armor values on those 30 different hitboxes and the different velocities of each of this hit boxes because the forearm might be moving faster than the upper arm which is moving slower than the torso which might also be moving at a different speed then the upper and lower legs. Oh and then you have to track collision with the environments on those hitboxes too. All those calculations times 6 requires much less overhead than times 30.

 

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

The CPU load should not increase because the recordings of the hit hurtboxes do not multiply as the hurtboxes multiply, because whether you have 3 hurtboxes or 30, in the end, by an attack, only 1 hurtbox is hit and that hit is recorded.
The CPU load is always a function of the number of soldiers and not of the hurtboxes.

When you determine if one object will hit a group of objects, you generally have to check all of them. If you have some system for example with 100,000 hurtboxes and 1 sphere which you want to collide with them, all 100,000 hurtboxes with all their polygons (or functions if it's a capsule or whatever) will have to be checked. Most games have some sort of quadtree or heuristic to cut this down and only trace the objects in the vague path of the line, but generally speaking there is no way for the CPU to know if two objects will collide without actually testing them.

Once the right hurtbox is determined then the CPU can do all the movement / velocity calculations, but those are quite literally hundreds of times less taxing than polygon / triangle / capsule traces that get used to find the right hitbox. I've actually coded a similar system myself and it's without doubt the most complicated a slowest thing in my game. You can do thousands of them a second, but they're still fairly slow compared to velocity caluclations which are highly optimised on modern CPUs and typically only take a few CPU instructions.

 

[darksoulshin]

I'll focus on a single issue, since I'll just repeat myself with the others.

The number of collision checks is generally = #hitboxes * #hurtboxes. I'm sure games like Bannerlord optimize and eliminate some of the checks with fancy algorithms, but you can clearly see at least a linear effect on performance. And there goes your strange argument that the performance is the same - the whole proposal is impractical.

Those things also move around when the model is animating or changed its position in the scene.

I think these kind of thoughts are related to people thinking computer code works like themselves.
When you look at the scene you can see a sword hitting an arm, but, for the code, it's just looping through collision objects to check two of them shares some space partially.

When you determine if one object will hit a group of objects, you generally have to check all of them. If you have some system for example with 100,000 hurtboxes and 1 sphere which you want to collide with them, all 100,000 hurtboxes with all their polygons (or functions if it's a capsule or whatever) will have to be checked. Most games have some sort of quadtree or heuristic to cut this down and only trace the objects in the vague path of the line, but generally speaking there is no way for the CPU to know if two objects will collide without actually testing them.

Once the right hurtbox is determined then the CPU can do all the movement / velocity calculations, but those are quite literally hundreds of times less taxing than polygon / triangle / capsule traces that get used to find the right hitbox. I've actually coded a similar system myself and it's without doubt the most complicated a slowest thing in my game. You can do thousands of them a second, but they're still fairly slow compared to velocity caluclations which are highly optimised on modern CPUs and typically only take a few CPU instructions.

I understand, so consider pairs of hitbox and hurtbox.
Considering that the weapon's hitboxes are generally 2-3, it would go from 12-18 checks per shot to 50-75 (I count 25 hurtboxes per model in order to guarantee good combat realism).
I thought worse, instead it is linear.
If it comes to linearity then the choice is between having 2000 models in the field with 6 hurtboxes for each of them, or having 700 with 25 hurtboxes.

In the first case there would be a gameplay that favors the spam of the attacks and a relationship between the units and the bullets that is difficult to balance without altering the armor values, but this would lead to an imbalance between the melee units.

In the second case there is a greater depth of the gameplay which makes the spam of the attacks inconvenient, a greater balance (between units and units and between factions and factions) and balancing of the game and the cost of which turns out to be the one written above, or so I understood from what I read, tell me if I'm wrong.

 

[Mad Vader]

I think you got that right. In another type of game with smaller scale combat (or Bannerlord MP) you could go crazy with modeling parts of the body (and corresponding armor) to achieve better realism and deeper combat gameplay.
For mass combat games though, performance seems to be the top priority. Taleworlds wants low-end PCs and consoles to be able to run its mass battles and, judging by the dev blogs, they really care about engine optimization.

 

[Death2Tyrants]

and consoles

Hey no foul language around here!

 

[Midnitewolf]

I think you got that right. In another type of game with smaller scale combat (or Bannerlord MP) you could go crazy with modeling parts of the body (and corresponding armor) to achieve better realism and deeper combat gameplay.
For mass combat games though, performance seems to be the top priority. Taleworlds wants low-end PCs and consoles to be able to run its mass battles and, judging by the dev blogs, they really care about engine optimization.

Yep. Everything works on a slider and resources are finite. If you want A to happen you have to give ground with B. The more detailed and realistic the simulation, the more processing power it is going to take to make it work. In Bannerlord's case you can have more realistic combat or you can have more units and it comes down to what you prefer. Then when you think Medieval Warfare, you think of two big armies in mass formations facing each other which means you have to move the slider toward unit counter and less toward realistic combat. You just move the slider to you get the compromise feel gives the best experience.