Turn block and priorities: how it works

I wanted to write this down somewhere, so here it goes: as Ivan stated back in 2015, there's really no %. There's no concept of "priority" in the code, just "order and random rolls".

We manage a list of Turn Actions for every player, and they're processed as follows. Let's assume player A attacked player B, while player B tried to run away:

1. Pick a random player.
2. Pick his next action (if any, if no more moves just pick another player). Let's assume player A's action is selected.
3. See where the stack wants to go (e.g attacking another city or unit, or just moving away). If he's not being attacked, complete the move successfully. Mark his target as "attacked".
4. Finish the action, and go again from step 1. Let's assume we now pick player B's Turn Action. He wants to move his units away.
5. Now, we check that this stack is being attacked and it is in defense position. We will calculate the chances of this stack being intercepted: we will roll a random number between 0 and 1. If the number is higher than (AttackerArmyCount / (DefenderArmyCount * 2)) [EDIT: the actual formula is AttackerArmyCount / DefenderArmyCount * 2, which is processed as (AttackerArmyCount / DefenderArmyCount) * 2. then the stack escapes.

This system has been in place for more than 3 years. Updates like this one from 2012 are either outdated or weren't implemented as-is. This explanation reveals lots of unintended behaviors, especially when you consider what a Turn Action really is. I hope it sheds some light for those interested in this system.

EDIT: please also check Dave's explanation for more details about this mechanic.

Skrevet av clovis1122, 13.05.2020 at 13:53

There's no concept of "priority" in the code

Skrevet av clovis1122, 13.05.2020 at 13:53

2. Pick his next action

This is priority.

Skrevet av clovis1122, 13.05.2020 at 13:53

AttackerArmyCount / DefenderArmyCount * 2

(AttackerArmyCount / DefenderArmyCount) * 2
or
AttackerArmyCount / (DefenderArmyCount * 2)

Skrevet av SuperiorCacaocow, 13.05.2020 at 13:57

Skrevet av clovis1122, 13.05.2020 at 13:53

There's no concept of "priority" in the code

Skrevet av clovis1122, 13.05.2020 at 13:53

2. Pick his next action

This is priority.

Sorry, we coders don't understand this userland jargon . All we know is that we receive a list of actions and we process them in order.

So it's a lot about just getting lucky?

I can feel all my past frustration of trying to explain turn blocking to players finally being at ease. Trying to tell people there isn't a set percentages and priority has been one of the most painful experiences in my life. The answer of it being down to luck was just never good enough for all these smart kids.

If player A attacks B on move #1 and player B moves the stack on move #27 we get the same interaction?

According to this AttackerArmyCount / (DefenderArmyCount * 2)
If the attacker has two times the size of the defender = attack is inescapable? Is that true tho?

Skrevet av blargh, 13.05.2020 at 14:05

If player A attacks B on move #1 and player B moves the stack on move #27 we get the same interaction?

So does the 1st move actually matter?

Skrevet av blargh, 13.05.2020 at 14:05

If player A attacks B on move #1 and player B moves the stack on move #27 we get the same interaction?

Yep. In this case, player A's attack is likely to be processed first, so player B will most likely reach step #5.

Skrevet av NegTheEskimo, 13.05.2020 at 14:06

According to this AttackerArmyCount / (DefenderArmyCount * 2)
If the attacker has two times the size of the defender = attack is inescapable? Is that true tho?

Yes, this is true for step #5. Assuming Player A with 20 units attack Player B with 10 units, the only chance for B escape is by having his move processed first and skip step #5 (both 1st move and with 2 players only, this is about 50%).

Skrevet av Muellertyme., 13.05.2020 at 14:09

Skrevet av blargh, 13.05.2020 at 14:05

If player A attacks B on move #1 and player B moves the stack on move #27 we get the same interaction?

So does the 1st move actually matter?

Yes, this allows 5 units to escape against 100 units just by being processed first.

What

Skrevet av clovis1122, 13.05.2020 at 13:53

I wanted to write this down somewhere, so here it goes: as Ivan stated back in 2015, there's really no %. There's no concept of "priority" in the code, just "order and random rolls".

We manage a list of Turn Actions for every player, and they're processed as follows. Let's assume player A attacked player B, while player B tried to run away:

1. Pick a random player.
2. Pick his next action (if any, if no more moves just pick another player). Let's assume player A's action is selected.
3. See where the stack wants to go (e.g attacking another city or unit, or just moving away). If he's not being attacked, complete the move successfully. Mark his target as "attacked".
4. Finish the action, and go again from step 1. Let's assume we now pick player B's Turn Action. He wants to move his units away.
5. Now, we check that this stack is being attacked and it is in defense position. We will calculate the chances of this stack being intercepted: we will roll a random number between 0 and 1. If the number is higher than (AttackerArmyCount / (DefenderArmyCount * 2)), then the stack escapes.

This system has been in place for more than 3 years. Updates like this one from 2012 are either outdated or weren't implemented as-is. This explanation reveals lots of unintended behaviors, especially when you consider what a Turn Action really is. I hope it sheds some light for those interested in this system.

are you sure?
i assumed any move a player makes is put on a queue
then the queue is dequeued for every player in the game in random order

for everyplayer
if queue length > 0
dequeue pick action
else
skip

this is why priority exists without being explicitly stated no?

It would be easier if the turn block function was removed, I understand the reliance we've developed over the years on this element of the game, but it is time to cut loose and try new things... if we keep the turn blocks then they will confusing

Skrevet av boywind2, 13.05.2020 at 14:42

-
this is why priority exists without being explicitly stated no?

You're right in the sense that you could say the 'priority' is the moment in which you make your moves. I don't really mind the terminology if it helps people understand TBs, I just wanted to make it clear that this is not explicit in the code (e.g, there's no code that says "if this player move was done before the other, double his TBs chances").

It's not a queue btw. That could be a more efficient way to implement it. What we have right now is a sorted array.

I am in no way an expert in programming and program languages... however, what I do understand here is that the game simply picks movements in whatever order luck wants it to be. Therefor, "priority" is just a matter of whichever code is first processed and not dependant on the player's movement priority decision?

Fk sake, I gotta go back to programming classes...

Could this mean that the biggest illustrative chance of tb you can ever get is 50%?

West pls

Skrevet av clovis1122, 13.05.2020 at 15:54

Skrevet av boywind2, 13.05.2020 at 14:42

-
this is why priority exists without being explicitly stated no?

You're right in the sense that you could say the 'priority' is the moment in which you make your moves. I don't really mind the terminology if it helps people understand TBs, I just wanted to make it clear that this is not explicit in the code (e.g, there's no code that says "if this player move was done before the other, double his TBs chances").

It's not a queue btw. That could be a more efficient way to implement it. What we have right now is a sorted array.

how does the game determine which player's turn action is processed

Skrevet av boywind2, 13.05.2020 at 23:32

Skrevet av clovis1122, 13.05.2020 at 15:54

Skrevet av boywind2, 13.05.2020 at 14:42

-
this is why priority exists without being explicitly stated no?

You're right in the sense that you could say the 'priority' is the moment in which you make your moves. I don't really mind the terminology if it helps people understand TBs, I just wanted to make it clear that this is not explicit in the code (e.g, there's no code that says "if this player move was done before the other, double his TBs chances").

It's not a queue btw. That could be a more efficient way to implement it. What we have right now is a sorted array.

how does the game determine which player's turn action is processed

Here, with comments

I have a question. Assuming that player moved troops from Izmair to Istanbul and from Istanbul to Kiev. Assuming that his opponent attacked Izmair how is it determined whether the battle would take placr in Izmair Istanbul or Kiev?

I assume it is determined by the location of the troops at the step of the battle player B ordained an attack. If so the priorities of order does matter to the location of the battle and chances of success. Because turnblocking 8 troops in Izmair at early stage of the turn is way more probable than turnblocking 80 troops in Istanbul at later stage. I am sure 99% of the players will swear that priorities so make a diffrence.

I always thought it was something more like this.

If [player1 attack with 1 unit] = correct
If [player2 has 20+ units] = correct
tb = yes

Skrevet av clovis1122, 14.05.2020 at 03:07

Programming RNJESUS game

Bro, I know I'm late to the party, but this system is retarded, can we perhaps just remove the entire concept of tb vodoo and replace it with a systemwhere all moves just go through before any combat starts?

Alternatively make it less randomized and have more to do with the amount of troops attacking. like only 1/4th of the troops to be tb'ed can tb

Skrevet av Tirpitz406, 11.12.2020 at 08:33

Skrevet av clovis1122, 14.05.2020 at 03:07

Programming RNJESUS game

Bro, I know I'm late to the party, but this system is retarded, can we perhaps just remove the entire concept of tb vodoo and replace it with a systemwhere all moves just go through before any combat starts?

Terrible, there's no longer any disadvantage to spamming pure offensive units because you can never be tbbed and punished for it.

Skrevet av Witch-Doctor, 11.12.2020 at 11:10

Terrible, there's no longer any disadvantage to spamming pure offensive units because you can never be tbbed and punished for it.

Then make offensive units weaker, should be anyways.

So, here's my practicum for those of you who are totally confused by all this theory (like me):

1. Do all your attack moves first and yes, size does matter. And remember if you attack a city or resource, it doesn't really matter whether the unit you are attacking defends or runs. You still get the city.
2. Do all your non-attack moves second. Obviously you want to move large stacks before moving smaller or single unit stacks.
3. Build new units. Yes, there will be cases where you need to build the units so that they are available for an attack (step #1) or move (step #2).
4. Fortify (wall if you prefer) cities and resources.

Commodus

Skrevet av clovis1122, 13.05.2020 at 13:53

I wanted to write this down somewhere, so here it goes: as Ivan stated back in 2015, there's really no %. There's no concept of "priority" in the code, just "order and random rolls".

We manage a list of Turn Actions for every player, and they're processed as follows. Let's assume player A attacked player B, while player B tried to run away:

1. Pick a random player.
2. Pick his next action (if any, if no more moves just pick another player). Let's assume player A's action is selected.
3. See where the stack wants to go (e.g attacking another city or unit, or just moving away). If he's not being attacked, complete the move successfully. Mark his target as "attacked".
4. Finish the action, and go again from step 1. Let's assume we now pick player B's Turn Action. He wants to move his units away.
5. Now, we check that this stack is being attacked and it is in defense position. We will calculate the chances of this stack being intercepted: we will roll a random number between 0 and 1. If the number is higher than (AttackerArmyCount / (DefenderArmyCount * 2)), then the stack escapes.

This system has been in place for more than 3 years. Updates like this one from 2012 are either outdated or weren't implemented as-is. This explanation reveals lots of unintended behaviors, especially when you consider what a Turn Action really is. I hope it sheds some light for those interested in this system.

Sooo basically the more troops u have the higher the chance to turnblock?

Skrevet av taomerde, 13.01.2021 at 08:12

Sooo basically the more troops u have the higher the chance to turnblock?

Basically, yes.

Skrevet av Dave, 13.01.2021 at 20:57

Skrevet av taomerde, 13.01.2021 at 08:12

Sooo basically the more troops u have the higher the chance to turnblock?

Basically, yes.

i thought it capped out at 50% though?

Skrevet av PleaseMe, 13.01.2021 at 21:03

Skrevet av Dave, 13.01.2021 at 20:57

Skrevet av taomerde, 13.01.2021 at 08:12

Sooo basically the more troops u have the higher the chance to turnblock?

Basically, yes.

i thought it capped out at 50% though?

Yes that's true. The more troops you have the higher the chance to turnblock... upto a max chance of 50%.

Skrevet av Dave, 13.01.2021 at 21:05

Skrevet av PleaseMe, 13.01.2021 at 21:03

Skrevet av Dave, 13.01.2021 at 20:57

Skrevet av taomerde, 13.01.2021 at 08:12

Sooo basically the more troops u have the higher the chance to turnblock?

Basically, yes.

i thought it capped out at 50% though?

Yes that's true. The more troops you have the higher the chance to turnblock... upto a max chance of 50%.

can we delete turn blocks. no more luck all skill now

Skrevet av PleaseMe, 13.01.2021 at 21:10

can we delete turn blocks. no more luck all skill now

Tempting.... I'm afraid to touch it at the moment tho