I come from CS background so I do know about how the machine works(though not familiar with game design major). And from what I know, this kind of crash does not look like induced by incapability of computing resulted from complexity/structure issues, as explained above.I think it's fantastic you're interesting in how this works, but I unfortunately can't put more time into explaining it out. I'd recommend looking up gaming architecture and what goes into a game engine and how it works with your computers resources
Simply put increasing this limit is much farther reaching and complicated than it sounds. Like Kentucky said it has to do with how the software uses memory and processing directly
I'm extremely cynical of TaleWorlds, but I don't judge them at all for not trying to work on this even as much as I'd like to see larger battles
I do not understand what you mean by "engineering perspective". But as a video game, from player perspective, it did affects gaming experience. Reinforcement issue has been discussed above. Another example I can come up with is tactics. With a small battlesize like 500 each side(which is the current cap), tactics and commanding troops won't affact battle much(players can barely have reserved/mobile forces that is effective enough to do something by themselves, so most battles are just one-wave rush and that's it, choice of tactics has been narrowed down)Why? It's really not important from an engineering perspective. What benefit will a higher number of troops at a battlefield at once give you? You will feel pretty much the same thrill with 2048 troops at once. Those troops are not even real players. The only one experiencing the battle is you. There's no importance to that number like it would in an MMORPG or a vcon app.
The power of 2 cap suggests that kind of guess, and that's also what I have originally thought. But a year has passed and still no official interpretation released, regardless of so many similar forum posts.It's probably neither. The fact that it's a power of two suggests that it's due to a limitation of how the code uses hardware and memory directly.
Normally not linear, but normally gradual. I don't quite understand what you are saying in the second sentence, do you mean "slower" instead of "faster"?Performance usually isn't linear or gradual, for example in warband a texture of size 2048 would load and be rendered about 10 times faster than a texture of size 2047.
Picture attached. The CPU and GPU occupation drops suddenly when I tried to load the battle scenes, which suggests the game has even not at least tried to do the job when the point has been passed.The crash is not due to increased amount of computation. The crash is because you've surpassed the game engines limitation.
Use a mod which allows you to increase this cap and watch your CPU when the game crashes. I doubt it'll be maxing out
It may not be able to go much higher than 2048, but then the performance is supposed to drop differently for differnent machines. Not like now, it suddenly crashed after passed an identical point for all machines no matter how the game perform before the point. In Warband, if you keep increasing battlesize, performance will drop gradually to some point you can not actually play the game (for example, super-low FPS)before crash. But in Bannerlord, the machine may perform normally before the break point and suddenly crash after the point has been passed. Most video games works in the Warband way.The game engine is the same for everyone regardless of machine and it's an entity cap. More than likely because going up another power of 2 would have been too intensive for even the most powerful machines.
Wait, did you say it's not hardcoded? Now you are saying it is hardcoded.The crash is not due to increased amount of computation. The crash is because you've surpassed the game engines limitation.
Use a mod which allows you to increase this cap and watch your CPU when the game crashes. I doubt it'll be maxing out
I know what you mean, that's why I focus on pathfinding part. Current AI do not support complex commandng, during field battle, most time we only have several big clusters of units before final charge(and fight normally end fast after that, or number of units on field reduced greatly after that, and during the fight we do not need complex pathfinding but simply find the closest enemy), so if pathfinding for units of a single cluster is computed as a whole, computational burden would be reduced greatly.Yes, each troop in Bannerlord has it's own independent AI. Total War Games may look impressive, but there's a reason they don't let you actually fight, and that's because it's all visual simulation to make it look like a massive battle when infact there's not a whole lot actually happening behind the scenes. It looks great for sure, but you wouldn't actually be able to interact with those soldiers if you was down there with them.
AI in Bannerlord need to be able to fight dynamically, having freedom of movement, selecting the closest target, accessing that targets blocking direction, choosing it's own, predicting it's movement to correctly throw javelins or fire projectiles at. None of this would work with the Total War Style of AI implementation and all of these calculations can add up to be very intensive with a large amount of troops.
We are talking about PC, not console, common sense: select game setting with respect to your machine when playing on PC, the game can support something does not mean your machine can also support the same thing. Simple examples: DLSS/4k. Why can people understand that common sense when talking about graphical issues but cant understand when talking about battlesize? Recall Warband when we do not have such upper cap, will you further increase battlesize when you have already been suffering from significant performance loss? Your logic is really weird. DO NOT TREAT PLAYERS AS IGNORANT MONKEYS.The reason they limit the troops is so the product they release is stable, if they increased the cap to 10,000, and advertised it as such, there would be a lot of backlash when people realise their machine can't handle it. There may also be some engine limitation in there, so they decided to cap it at what they thought was the highest acceptable value.
Then at least allow players do the choice themselves. Not like hard-coded this way.It's just more efficient to hardcode a number than to do various calculations related to your settings, size of the modules, available resources, etc every time the game runs.
That may be an explanation, but it is still weird since the limitation you described also need to be manually implemented(since this is not the upper cap of binary number machine can accept and understand). And if it were simply an allocation space issue, then it is suppsoed to be simple to alternate.(As far as i can image, like simply increase to a much larger number that no machine can actually reach, then game will crash with respect to capability of corresponding machine)Maybe because every trooper might be described in the code with a number which will be translated as a binary symbol combination of I and 0 which seems to be 10 bits big so: 0000000001 is Trooper #1 for the engine and 1111111111 is trooper #2048. For another one you would need to make the engine understand that there are numbers greater than "10 binary digits". Might be engine-related. But it is indeed a power of 2 which might make one guess this could be an allocation thing or something hard-coded. I mean, you must explain to the program what to do with the input it gets and if it is like "there are 2048 troopers possible" because it only accepts a 10-digit number as denominator we cannot simply make it 4096 by adding another digit because then the program will be confused. Maybe something like that. Maybe they thought when making the game years ago "well, we cannot imagine that PCs will be able to handle a larger number than roughly 2000, so we use the 10-digit solution as denominator. I do not know. Maybe I just had a bad coffee and am seeing things.
That might be the case, algorithm complexity may increase exponentially. But still, at least allow players to alternate the setting themselves, at least through mod. Common sense: modify product, which is Bannerlord under this context, at your own risk. DO NOT TREAT PLAYERS AS IGNORANT MONKEYS.My guess is that doubling the hardcoded maximum from 2048 to 4096 (i.e. adding a bit, the smallest possible increase) would cause a significant performance drop that would make *all* battles run worse on *all* systems, raising the minimum and recommended requirements on the CPU side.
They probably already took a hit from going for 2048 instead of 1024, but did it because they didn't want to lock themselves out of offering sizes over 1000 in the future without a refactor.
That's what I'm trying to ask: why and how is such cap implemented in the lower level code?Anyway, with a mod you can increase the battle size to whatever you want (in the .NET code) but the underlaying (low level/rendering) module crashes above 2k when it gets this number, suggesting that there is a hardcoded buffer/list with that maximum size, and if you give a bigger number, it overrides and corrupts memory - and crashes the whole game.
Then it's very weired why this cap is exactly the same for everyone and every machine. Normally if crash is induced by engine, through memory leak or something like that(since this crash is related to increased amount of computation required), the break point is supposed to be higher for better machine.It's an engine limitation, not some hardcode that can be removed.
Not sure why there is a 2048 cap on battlesize. If it were hard-coded like thisYeah it would be great. I don't think a game engine upgrade will ever happen though. I don't know if that's even possible without rebuilding the game, I hope it is.
if battlesize>2048: raiseerror and exit
TBH, this just like typical TW comments on discarding features. Looks like it is talking about something at the first glance, but after a closer and careful inversitgation, it does not give any actual information, but only the result: discarded.Ambushing was a planned feature, however, after implementing it, we found that it didn't really work well with the way our sandbox plays out, and ultimately, it wasn't much fun for the player.
This sounds like something resembles multiplier effect of simple short-run model in macroeconomics, so it is supposed to be easy to accomodate this problem by manipulating numbers.Real problem here is :
we have 2 effects and each feed each other
prosperity -> construction (construction is calculated from prosperity directly)
construction -> prosperity (by default project housing)
So this creates a loop. prosperity -> construction -> more prosperity -> more construction
Not sure why, though after I installed improved garrison, bandits are cleared out, but Clear Bandit quest become more, just weird.I've been using the Improved Garrisons mod lately and I LOVE it.
I hate late-game bandit patrols nuking all my villagers parties and stifling growth. I also hate having a single enemy party of like 50 dudes pillage a town.
Now, I can make a patrol of 50 battanian heros and 50 legos that decimate everyone in sim battles. lol
Is that so? I can't remember if there is such devblog, may you provide a link to that?Dude, they planned and explicitly axed just that "ambush" feature because they couldn't design it right and found their design annoying to their short attention span stress tester Callum. It was in one of them devblogs.
I can remeber they have talked about that, but can't remember if it is out of consideration forever or only temporarily due to priorityHaven´t they already said that they won´t add a patrol feature?