Project

Profile

Help

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...
Send by e-mail

Feature #767126

Barbarian's uprise factor is almost always 1 or 2

Added by Akechi . about 3 years ago. Updated 7 months ago.

Status:
Closed
Priority:
Low
Assignee:
Marko Lindqvist
Category:
Server
Sprint/Milestone:
2.6.4
Start date:
Due date:
% Done:

0%

Estimated time:

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;
is
city_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.

0033-Adjust-formula-for-barbarian-band-size.patch (1016 Bytes) 0033-Adjust-formula-for-barbarian-band-size.patch Marko Lindqvist, 2021-01-03 10:12 PM

History

#1 Updated by Jacob Nevins over 1 year ago

  • Sprint/Milestone changed from 2.6.1 to 2.6.2

#2 Updated by Marko Lindqvist over 1 year 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;
is
city_max = city_max * 6 / 5 + UPRISE_CIV_SIZE;
(server/barbarian.c try_summon_barbarians)

No, it's
city_max = city_max * ( 6 / 5 + UPRISE_CIV_SIZE );

#3 Updated by Akechi . over 1 year 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 1 year 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 expression E1 = E1 op (E2) only in that the lvalue E1 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 1 year 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 1 year ago

  • Sprint/Milestone changed from 2.6.2 to 2.6.3

#7 Updated by Akechi . over 1 year 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 7 months ago

  • Sprint/Milestone changed from 2.6.3 to 2.6.4

#9 Updated by Marko Lindqvist 7 months ago

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 7 months ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist
Send by e-mail

Also available in: Atom PDF