Unraveling some myths regarding the battle engine

[DeletedUser]

it dosen't make much sense for a programmer to make an if/else condition that gives back randomized results ,it usually is used to narrow the entries and give you one solid result out of them.
and the issue here is under similar consequences results vary. so either there is a factor that we dont see or there is a huge percentage of luck involved in the formula for nobleman.

Why not? They use a modifier already called "Luck", so nobles (which i know survive after 50% based on a luck number based on how many troops are dead, more dead troops = more likely to die) and paladin (which i think does as well, not sure though)


If it didn't work this way think how battles would unfold, if half your infantry died, you noble would round up and die with them every time, or it won't die unless they all died.

 

[DeletedUser1323]

3 more reports that show what I was saying.
On the first two luck -1 and -6 the noble gets killed and on the last one with luck -13 the noble gets through. All other factors are constant. same wall, same faith, and so on.

I'm not saying you're wrong jehzir. Because there is a mathematical equation at play here and a chance factor. You might be right on your "if/else" on the equation part. But whenever this equation gives you a value that goes beyond 50% for the noble to get killed I think it triggers a chance factor, where sometimes the noble gets through when it shouldn't. And the higher the likeness of the noble getting killed, the lower the chances of this chance factor to take effect. Like hawk.eye described:


Regarding your "if/else" formulas. It's hard to test them fully when I believe that the results we see whenever a noble survives, are behind a chance factor. But this is my opinion based on the tests I've done.

Removed extra for readability sake...

Okay, it appears that report 2 and 3 followed the logic of the else statement, but number 1 did not, it has negative luck and has the lowest remaining attack score left. So, they changed the way it works again based on the "surviving noble, when the noble should die condition" mentioned in the bug fixes. I know there is an if calculation for the wall in there because it is a basic defence that needs to be accounted for. Now is it correct in structure? probably not, since we are thinking about this forward (from the attack side), time to go backwards and see what the total defence damage is based on the round and check to see if there is enough 'damage' by morale or other factor that can contribute to this.

Since these tests are done on wall == 0 and DPIM == 0 its really only testing the last else, since the first two are false. That will take me a bit of work to type all of those formulas out, some are scrawled on a notepad, I will have to look at it on the weekend. If you solve it before I get to it no sweat off my back and we can cheer as everyone involved helped to noodle through this problem.

 

[DeletedUser]

I can't find it now, I know a CM said before noble death was on chance after 50% of the troops die. It clearly a chance system that is more and more likely to kill the noble the more troops died, but still, a chance.

Sadly B/c of this, the i am unsure a battle sim will ever be 100% in regard to it.

 

[DeletedUser1323]

I can't find it now, I know a CM said before noble death was on chance after 50% of the troops die. It clearly a chance system that is more and more likely to kill the noble the more troops died, but still, a chance.

Sadly B/c of this, the i am unsure a battle sim will ever be 100% in regard to it.

Even if this statement is 100% true, a programmer has to have a set of parameters to pass the variable through the equation to get the desired result. So with that in mind you can closely simulate that
IF OffensiveTroopsSurvive <= 49.49 && Noble >= 1 then NobelSurvival == 0
IF OffensiveTroopsSurvive > 49.49 && OffensiveTroopSurvive < 54.51 && Nobel >=1 Than NobleSurvival(chance)
IF OffensiveTroopSurvive >=54.51 && Nobel >=1 Than Nobel(survival)

Chance routine
Is based on paladin chance of survival routine, based on three criteria 1) wall (present or not) 2) survival during a battle group 3) RNG based on the prior two conditions weighted by the OffensiveTroopsSurvive percent, as some are calling it the "luck" factor.
Survival routine
Is the action of the noble being escorted in properly, calls the chance routine, testing true to all three conditions, thus lowering loyalty

 

[Hawk.eye]

Why not? They use a modifier already called "Luck", so nobles (which i know survive after 50% based on a luck number based on how many troops are dead, more dead troops = more likely to die) and paladin (which i think does as well, not sure though)


If it didn't work this way think how battles would unfold, if half your infantry died, you noble would round up and die with them every time, or it won't die unless they all died.

well i think you didn't quite get my view point. i'm not saying if else is not used in battle engine or shouldn't be used i say you can't use it to randomize stuff. perhaps its irrelevant since i read last few posts again and i dont really recall why i said that... thats me. i already forgot what i had for breakfast and its 9:30 morning.

 

[DeletedUser2754]

Since these tests are done on wall == 0 and DPIM == 0 its really only testing the last else, since the first two are false. That will take me a bit of work to type all of those formulas out, some are scrawled on a notepad, I will have to look at it on the weekend. If you solve it before I get to it no sweat off my back and we can cheer as everyone involved helped to noodle through this problem.

The last 3 reports I added here have wall at level 20. And the ones I described here have it as well:

I have 6 different reports of 15LC+1NOBLE. Faith 110% and weapon mastery against faith 110% and wall 20. Only thing that varies is the luck: 13%=-6LC; 11%=-6LC; 5%=7LC; 2%=-7LC; -10%=-8LC; -14%=-9LC. On all the noble always survived. According to your proposed method I should need at least 11LC surviving to get past the wall. In none of the circumstances that happens, yet the noble always survives. Was I lucky 6 times in a row?

 

[DeletedUser1323]

The last 3 reports I added here have wall at level 20. And the ones I described here have it as well:

I missed that, I was tired, but the premise of my last post remains, which mixes the paladin survival routine with the noble to determine by remaining combat strength, note that I included the RNG as part 3 of the routine, which is a part of the paladin routine. The RNG is a -15 to +15 luck role that we never see, but we can be close. The RNG is either add/subtracted based on the overall total as described in the above post. I think the goal is to not predict 100% of the time that the noble will survive or not, but give fair warning that the player is risking it by sending nobles with questionable troops combinations.

What could have changed is instead of survival like it was done in the past, it could be done on the overall total, which allows for the variance to take place like you just did. Remember, we just had a version change and noble abilities were modified, so we could be seeing the very first reports with these conditions in play.

 

[DeletedUser]

Even if this statement is 100% true, a programmer has to have a set of parameters to pass the variable through the equation to get the desired result. So with that in mind you can closely simulate that
IF OffensiveTroopsSurvive <= 49.49 && Noble >= 1 then NobelSurvival == 0
IF OffensiveTroopsSurvive > 49.49 && OffensiveTroopSurvive < 54.51 && Nobel >=1 Than NobleSurvival(chance)
IF OffensiveTroopSurvive >=54.51 && Nobel >=1 Than Nobel(survival)

Chance routine
Is based on paladin chance of survival routine, based on three criteria 1) wall (present or not) 2) survival during a battle group 3) RNG based on the prior two conditions weighted by the OffensiveTroopsSurvive percent, as some are calling it the "luck" factor.
Survival routine
Is the action of the noble being escorted in properly, calls the chance routine, testing true to all three conditions, thus lowering loyalty

OR possibly, more simple

if(RNG between 1 and 50 + (Troops Killed % - 50%)*100) > 50
Kill noble
Else
Not kill noble.

 

[DeletedUser1323]

OR possibly, more simple

if(RNG between 1 and 50 + (Troops Killed % - 50%)*100) > 50
Kill noble
Else
Not kill noble.

If it was that simple, it would have already been done. This is more elaborate and has other elements taken from other places in the code. With the way this JS code is written they call routines from within nested routines so you cannot follow it very well.

 

[DeletedUser]

JS? I thought it was php XD

 

[DeletedUser3016]

JS? I thought it was php XD

Even with PHP, you still need another language to interact with the client side. PHP only commits to do commands on the server itself, and updates the databases with the information on villages and players etc. It is the Javascript that does the front end stuff that you see as a user. When talking about the maths behind the game and attacks themselves, it can be done on either side, though I would have thought with my limited experience on the matter, it would be much easier to do it in the Javascript side?

 

[DeletedUser3586]

Even with PHP, you still need another language to interact with the client side. PHP only commits to do commands on the server itself, and updates the databases with the information on villages and players etc. It is the Javascript that does the front end stuff that you see as a user. When talking about the maths behind the game and attacks themselves, it can be done on either side, though I would have thought with my limited experience on the matter, it would be much easier to do it in the Javascript side?

I don't think these calculations are processed in client side. If it was processed in client side, the game will no longer be able to play.Since the battle decisions are done on client's side, the result can be altered or at least try to alter and sent it to the server. Or better yet, send a lot of other stuff and server will never figure it out how the battle end.

And PVP battles happened in two client side. Attacker side doesn't know the numbers of defenders and defenders side doesn't know the numbers of attackers. So it is easier to process in server side which knows both numbers.

 

[DeletedUser1323]

JS? I thought it was php XD

I don't think these calculations are processed in client side. If it was processed in client side, the game will no longer be able to play.Since the battle decisions are done on client's side, the result can be altered or at least try to alter and sent it to the server. Or better yet, send a lot of other stuff and server will never figure it out how the battle end.

And PVP battles happened in two client side. Attacker side doesn't know the numbers of defenders and defenders side doesn't know the numbers of attackers. So it is easier to process in server side which knows both numbers.

Technically it uses a bootstrap style of AngularJS to do the decoupled DOM calls since each world has up to 6 .twx running for a single world. These decoupled worlds can be processed in parallel thus reducing the overall commit to the server, this does have a cycle draw down as the computations increase. Since they are using ng-class style of interpreted calls it makes it a pain to follow.

 

[DeletedUser]

Technically it uses a bootstrap style of AngularJS to do the decoupled DOM calls since each world has up to 6 .twx running for a single world. These decoupled worlds can be processed in parallel thus reducing the overall commit to the server, this does have a cycle draw down as the computations increase. Since they are using ng-class style of interpreted calls it makes it a pain to follow.

So... they have 6 servers running the battles at any given second?

I don't think these calculations are processed in client side. If it was processed in client side, the game will no longer be able to play.Since the battle decisions are done on client's side, the result can be altered or at least try to alter and sent it to the server. Or better yet, send a lot of other stuff and server will never figure it out how the battle end.

And PVP battles happened in two client side. Attacker side doesn't know the numbers of defenders and defenders side doesn't know the numbers of attackers. So it is easier to process in server side which knows both numbers.

Have to agree there

Even with PHP, you still need another language to interact with the client side. PHP only commits to do commands on the server itself, and updates the databases with the information on villages and players etc. It is the Javascript that does the front end stuff that you see as a user. When talking about the maths behind the game and attacks themselves, it can be done on either side, though I would have thought with my limited experience on the matter, it would be much easier to do it in the Javascript side?

I was surpised the co-op no coining thing is handled server sided XD

 

[DeletedUser1323]

So... they have 6 servers running the battles at any given second?

Yes, there are 6 separate instances .twx files that are all disassociated from the control server. This allows for the data transactions to be handled either client or server side with parallel processing. This is why you will see reports with different times but since you do not know which TWX you are on, unless you know where to look, times will be different due to them not being exactly in sync with each other and each instance can have different loads. This is an effective load balancer but it does not handle severe spikes very well when the .twx are at or near capacity.

 

[DeletedUser2084]

but since you do not know which TWX you are on, unless you know where to look,

Isn't it just the white text in the bottom right corner lol

 

[DeletedUser2185]

Isn't it just the white text in the bottom right corner lol

She knows our secrets! Quick, change the layout!

 

[DeletedUser3586]

She knows our secrets! Quick, change the layout!

Is that a secret? I thought we all know which server we are connecting. It showed in the loading screen something like "en0w5.twx"

 

[DeletedUser2185]

Is that a secret? I thought we all know which server we are connecting. It showed in the loading screen something like "en0w5.twx"

Hehe; that is public knowledge; Just kidding

 

[DeletedUser3586]

Hehe; that is public knowledge; Just kidding

You got me there lol. XD