HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Feature #767126
Barbarian's uprise factor is almost always 1 or 2
0%
Description
If barbarian's target nation has 10 to 111 cities, uprise
factor is 2. (if target has 112 to 1253 cities, factor is 3)
It is ok?
I think this code:city_max *= 1.2 + UPRISE_CIV_SIZE;
iscity_max = city_max * 6 / 5 + UPRISE_CIV_SIZE;
(server/barbarian.c try_summon_barbarians)
(Actually, if civ has 111 cities, uprise
factor seems 3...maybe floating point arithmetic error?)
e.g. If barbarians = hordes and you have 110 cities, barbarian comes with 8 to 10 units + leader.
If you have 111 cities, barbarian comes with 12 to 14 units + leader.
History
#1
Updated by Jacob Nevins over 2 years ago
- Sprint/Milestone changed from 2.6.1 to 2.6.2
#2
Updated by Marko Lindqvist over 2 years ago
Akechi . wrote:
If barbarian's target nation has 10 to 111 cities,
uprise
factor is 2. (if target has 112 to 1253 cities, factor is 3)
It is ok?
I think this code:city_max *= 1.2 + UPRISE_CIV_SIZE;
iscity_max = city_max * 6 / 5 + UPRISE_CIV_SIZE;
(server/barbarian.c try_summon_barbarians)
No, it'scity_max = city_max * ( 6 / 5 + UPRISE_CIV_SIZE );
#3
Updated by Akechi . over 2 years ago
Marko Lindqvist wrote:
No, it's
city_max = city_max * ( 6 / 5 + UPRISE_CIV_SIZE );
That means uprise
factor is intended to set 1 or 2 in general, not 3 or higher?
#4
Updated by Jacob Nevins over 2 years ago
- Subject changed from Barbarian's uprise factor is almost 1 or 2 to Barbarian's uprise factor is almost always 1 or 2
Previous comments hinge on C semantics of *=
. Just to confirm, C90 6.3.16.2 says:
A compound assignment of the form
E1 op= E2
differs from the simple assignment expressionE1 = E1 op (E2)
only in that the lvalueE1
is evaluated only once.
So behaviour is as cazfi describes.
Behaviour more like akechi describes would be given by city_max = city_max * 1.2 + UPRISE_CIV_SIZE
.
Here's a comparison of what I think the results are (not sure why they don't quite match akechi's figures):
uprise current akechi 1 <10 cities <10 cities 2 <110 cities <22 cities 3 <1210 cities <36 cities 4 <13310 cities <53 cities ...
This code was written relatively recently, by cazfi in 2015 (gna patch #5909 ); and the preceding code was too mad to discern intent. So we can hope to learn the original intent of this code. cazfi, do you remember? (Ticket says "This patch makes barbarian gang size to steadily grow as player gets bigger", hinting that current behaviour is not what was intended.)
If the current behaviour isn't what was intended, it seems a bit late to change on a stable branch (the current behaviour reportedly had lots of playtesting even before commit). Maybe fix for 3.0?
#5
Updated by Marko Lindqvist over 2 years ago
I'm guessing my commit message is what's wrong. Logarithmic scale sounds correct, as individual cities (that barbarians will attack) are not going stronger as fast as number of cities in the nation grows. We don't want to punish fast expansion too much.
However, while the shape of the curve is right, maybe the numbers are a bit high. Should we adjust UPRISE_CIV_SIZE a bit?
#6
Updated by Jacob Nevins over 2 years ago
- Sprint/Milestone changed from 2.6.2 to 2.6.3
#7
Updated by Akechi . about 2 years ago
Marko Lindqvist wrote:
I'm guessing my commit message is what's wrong. Logarithmic scale sounds correct, as individual cities (that barbarians will attack) are not going stronger as fast as number of cities in the nation grows. We don't want to punish fast expansion too much.
However, while the shape of the curve is right, maybe the numbers are a bit high. Should we adjust UPRISE_CIV_SIZE a bit?
I tried making some formulas... how about these?
#define UPRISE_CIV_SIZE 8 and next city_max += uprise * 4 + 2;
or
#define UPRISE_CIV_SIZE 6 and next city_max += uprise * 3 + 2 - (uprise % 2);
or
#define UPRISE_CIV_SIZE 4 and next city_max += uprise * 2 + 1;
number of victim player's city needed uprise *11.2 *1.2+10 +uprise*4+2 +uprise*3+2-(uprise%2) +uprise*2+1 1 0+ 0+ 0+ 0+ 0+ 2 10+ 10+ 8+ 6+ 4+ (UPRISE_CIV_SIZE) 3 112+ 22+ 18+ 14+ 9+ 4 1254+ 36+ 32+ 24+ 16+ 5 14044+ 53+ 50+ 38+ 25+ 6 157292+ 73+ 72+ 54+ 36+ 7 can't reach 97+ 98+ 74+ 49+ 8 can't reach 126+ 128+ 96+ 64+ 9 can't reach 161+ 162+ 122+ 81+ 10 can't reach 203+ 200+ 150+ 100+ 11 can't reach 253+ 242+ 182+ 121+ 12 can't reach 313+ 288+ 216+ 144+ ...
#8
Updated by Marko Lindqvist over 1 year ago
- Sprint/Milestone changed from 2.6.3 to 2.6.4
#9
Updated by Marko Lindqvist over 1 year ago
- File 0033-Adjust-formula-for-barbarian-band-size.patch 0033-Adjust-formula-for-barbarian-band-size.patch added
- Status changed from New to Resolved
How about this patch?
It should produce
Player cities -> band size factor:
...10 -> 1
11...31 -> 2
32...80 -> 3
81...186 -> 4
#10
Updated by Marko Lindqvist over 1 year ago
- Status changed from Resolved to Closed
- Assignee set to Marko Lindqvist