 |
|
Helium Pond
|
|
Los Anheles, California, Good Ole U S of A
Nov 1999
time: 05:13
|
|
Hi all. The bureaucracy formula just drives me nuts. I know a lot of you experienced types have it down, so I'd like your help. I'm trying to make a more accurate version of the datalinks, and I want to make the whole bureaucracy thing simpler. I want to just list the base limits before bureacracy penalties come into play. So I need a list of when, for each difficulty level and each planet size, the bureaucracy formula comes into play. Or, failing that, if someone could just tell me what the value of MAPROOT is for each of the default planet sizes, I could work the rest out. Anyone?
|
|
| |
|
|
|
Helium Pond
|
|
Los Anheles, California, Good Ole U S of A
Nov 1999
time: 05:13
|
|
Wait, so if you change you EFF rating, does the number of drones caused by your # of bases also change? I mean, does it change retroactively, so that you can get rid of those drones you already have? I thought that bureaucracy drones were permanent. But that doesn't make much sense, now that I think about it. Hm. Well, okay, cool.
Okay, so, here's the Datalinks formula for bureaucracy. Simpson II, this is what you were referring to, I think:
BaseLimit = (8 - Difficulty) * (4 + Efficiency) * MapRoot / 2
Where:
Difficulty = Player's difficulty level (0 - 5)
Efficiency = Social Engineering Efficiency rating.
MapRoot = Sq. Root of # Map Squares / Sq. Root of 3200.
First off, let me just say: sqare root of 3200??? What the f*&#@!%!??? Where the heck do they come up with these things? What could possibly be gained by using the SQUARE ROOT OF 3200 that makes it a better number to use than, say, 57?
So, from alpha.txt, this info on map sizes:
Tiny planet|(early conflict), 24, 48
Small planet, 32, 64
Standard planet, 40, 80
Large planet, 44, 90
Huge planet|(late conflict), 64, 128
Which means their total # of squares is:
Tiny planet: 1152
Small planet : 2048
Standard planet : 3200
Large planet : 3960
Huge planet : 8192
Which makes MAPROOT, lemme see here...
Tiny planet: 0.6
Small planet : 0.8
Standard planet : 1
Large planet : 1.11242blah blah blah
Huge planet: 1.6
Hmmm, odd that all the numbers work out nicely except for the Large planet. I was beginning to think MAPROOT actually made some sense, but of course not.
So, then, MAPROOT/2, the number we really need, is:
Tiny planet: 0.3
Small planet : 0.4
Standard planet : 0.5
Large planet : 0.55621blah blah blah
Huge planet : 0.8
So, okay. This means that, for someone playing on Transcend with no Efficiency modifiers, (8 - Difficulty) * (4 + Efficiency) works out to 3 * 4, which is 12, right, so for each planet size, that's:
Tiny planet: 3.6
Small planet : 4.8
Standard planet : 6
Large planet : 6.67457blah blah blah
Huge planet: 9.6
So, huh. Can you really only have 4 bases on a Tiny planet before you get a Bureaucracy warning? Hmm. Have to take a little trip into the Scenario Editor to see how those numbers round, no time for that just now. But for comparison, let's look at those numbers with a +1 Efficiency. That means that the non-maproot numbers work out to 15. This gives us:
Tiny planet: 4.5
Small planet : 6
Standard planet : 7.5
Large planet : 8.34322blah blah blah
Huge planet: 12
Hm. Maybe making this fit into a nice little chart isn't going to be easy. Maybe the most helpful thing I could do is eliminate the friggin' MAPROOT thing, by presenting what it works out to for the standard planet sizes.
Oh---and what about the SECOND bureaucracy warning? I've heard that there's another one that comes at another threshhold. Does anyone know anything about that?
[This message has been edited by Helium Pond (edited December 18, 2000).]
|
|
| |
|
|
|
DilithiumDad
|
|
Efficincey definitely has immediate effects. Anytime after the first warning, you can consider your efficinecy setting to be a component of your psych. Green is an excellent SE choice for controlling those dratted drones.
|
|
| |
|
|
|
Helium Pond
|
|
Los Anheles, California, Good Ole U S of A
Nov 1999
time: 05:13
|
|
But but but, what's the *effect* of the second threshhold? Does every base over that limit now cause *two* drones? And and and, if that's the case, then does every base over the third limit cause *three* drones, or does it cause *four* drones? Help help help (and does it say this anywhere, or is it just learned from playing?)
Goog:
Yeah, I got that. But so what? So, it makes a *couple* of the calculations come out to nice, round numbers. But most of the others are still messy, ooky numbers. So why not just use a simple number, is all I'm saying. It's not like using 57 instead of 56.5685424949238019520675489683879(etc) would throw the universe off its (fir)axis. What it is, is dumb over-smartness. (Mind you, I say that as a person with a masters degree in smart over-dumbness.)
[This message has been edited by Helium Pond (edited December 19, 2000).]
|
|
| |
|
|
|
MariOne
|
 |
Erewhon in Neverland
May 1999
time: 06:13
|
|
HP, the SQRT thing is not made to introduce some frigging decimals into the calculation, but to decide which kind (type, order, whichever) of influence a parameter has on a formula.
Indeed, you did a very good job there.
You could also write that factor as
SQRT (#tiles your Map / #tiles Standard Map)
The basic parameter is "Current/Standard Planetsize", do you agree.
You can see the way of expressing Planetsize with #tiles incidental (otoh practically, what would you use better, considering that width/height ratio may vary?)
How MUCH, should that parameter influence your bureaucracy?
AND should that relation be constant, linear, proportional?
Or should some boosting/dumpening effect better put into action?
These could have been the questions the designers posed themselves.
And indeed using SQRT is a typical way to progressively reduce the increase due to size at grater sizes.
Now, a Standard Planet is 40x80 cells.
To keep the globe-to-cylinder projection proportions, you know that usually the width of the maps is double their height.
When you refer to a planet's size, you ususally first think at its linear dimensions. You might then calcultate its total tiles, but most don't.
So, when you think to a planetsize "double than standard", what would you think to? I'd bet that the average joe would think to a 80x160 map. That is, doubling BOTH dimensions.
You know tho that, calculating areas, squares are involved. Thus a 80x160 map has FOUR times the tiles of a Standard one.
The SQRT of the #tiles ratio probably came out of that, to keep the bureaucracy linearly proportional to the linear dimensions of the map, while not linking it to a fixed width/height ratio.
If you look at them, all the game-proposed sizes respect the 2:1 width/height ratio!
And if you notice, standard height is 40=5x8
Tiny is 3x8
Small is 4x8
Huge is 8x8
No wonder that the Size parameter for those planets come out nicely, 3/5, 4/5, 8/5!!!
Had the Large planet been of 48x96, its size parameter would have been 1.2
And a "Big" 56x112 one would have been 1.4
Finally, the average Joe's "Double to Standard" 80x160 planet, would have a bureaucracy Size Parameter of TWO.
Don't you think it comes out perfectly?
And you call this dumb over-smartness? 
Now, this post demonstrates that in the end I begun to think like Firaxian developers.
All my resistance against their endless bugs was futile. There is a sense of accomplishment and fulfillment being asssimilated into one great distributed consciousness.
---
Edit: the "odd" parameter for Large planets comes indeed from the fact that its Width does NOT respect the ration to Height!!! Had a Large planet been of 44x88 instead of 44x90, its parameter would have been a nicely cut 1.1...
[This message has been edited by MariOne (edited December 26, 2000).]
|
|
| |
|
|
|
Fitz
|
 |
& Anarchist
Mar 2000
time: 21:13
|
|
ARRRRGGGGGHHH. I'm so sick of how confused people get by this. It's pretty simple once you memorize the maproot values.
MAPROOTS
Tiny planet: 0.6
Small planet : 0.8
Standard planet : 1
Large planet : 1.1 (close enough)
Huge planet: 1.6
Now, don't do the /2 part yet, because it tends to cancel.
INT((8-diff)*(4-eff)*MAPROOT/2) = base limit
INT means ROUND DOWN
defaults to memorize:
librarian, 0 eff., standard planet: 10 bases
transcend, 0 eff., standard planet: 6 bases
librarian, 0 eff., huge planet: 16 bases (10*1.6)
transcend, o eff., huge planet: 9 bases (INT(6*1.6))
effect is immediate, heres how it works:
Rank all bases by fouding date (including captured bases). Using that order, count bases from the earliest to the newest. If you want to see this order, hit F4, and the base screen shows them IN THIS ORDER.
Every base after you reach your base limit gets ONE extra drone. Every base after two times the limit (21st base on Lib Stand) gets TWO extra drones. Every base after you reach three times the limit gets THREE extra drones and so on. Bases below this limit get NO extra drones, even after you have more bases than the limit total.
Important things to remember:
1) If you calculate the limit for your normal diff/eff, you can get the numbers for any planet size by multiplying it by maproot value.
2) When you capture bases, it reorganizes the order for determining which bases get drones if it has an earlier founding date. This is especially noticable when you capture an enemies HQ.
3) Edit: Removed due to faulty info. That's what I get for observing instead of testing.
4) You only get the warning when you plant a base that breaks the limitation. If you shoved yourself above by capturing a base, you will not get it when you build a new base. If you later go and change your eff. to raise the limit by several bases, you may get it if you haven't exceeded the new limit.
That's it. Simple, see?
Last edited by Fitz on 11-06-2001 at 20:59
|
|
| |
|
| |
|
|
|
Ned
|
 |
of Aptos, CA
Oct 1999
time: 21:13
|
|
Fitz, I'm not so sure.
Have you verified everyting you say in your post? The reason I ask is that when I am in the "two-extra-drones-per-new-base" or higher level, I seem to get one or more drones in somewhat random other bases. Certainly, the new base I found gets an extra drone or two. But not always. However, other bases which were just fine before the founding of the new base now have an extra drone and are in riot.
I think I remember the same think from CIV and CIV II, but there I do not believe they had a bureaucracy warning.
I also suspect that captured bases do not count at all against bureaucracy warnings. The reason I say this is that I had a game where I got a warning that going over 39 bases would increase inefficiency. However, at the time of this warning, I had 60+ bases, more than 20 captured.
If captured bases counted, capturing a base above a bureacracy limit should cause drone problems elsewhere in the faction, but it does not, does it?
What I think is going on is that there is a counter that increases by one each time you found a new base. This counter is not incremented when you capture a base, or decreased when you give a base away. When this counter reaches the next threashold, you get the warning and if you continue to found the base, drones are then assigned to the founded base or to others in the faction. These drones are "permanent," and are not erased if you give the base away to a faction that has fewer bases than the limit.
Ned
|
|
| |
|
|
|
Fitz
|
|
& Anarchist
Mar 2000
time: 21:13
|
|
Ned, since I wrote this post, I recieved info that my statement about the drones only appearing in new bases is false, and that they appear randomly. My own (new) observations from games confirms this, so I've editted the above post.
I'm still not sure I'm willing to go along with your statement on captured bases yet, but don't have the time to test it for at least two weeks. Feel free to test it yourself. Go up to the limit, count you unmodified drones in every base, capture a single base, and see if your drones increase in any of your old bases.
Of course, if the random drone appears in your newly captured base, you'll never be able to tell. 
Incidentally, I have had drone riots the turn after capturing a base plenty of times, but that could easily be due to pop growth or some other factor I overlooked.
Incidentally, IIRC from another thread, negative efficiency counts as 0 for this formula.
Mis, you're talking about a three axis table.
1) efficiency
2) world size
3) difficulty
That means you need a set of tables. Either one table per efficieny, one per world size, or one per difficulty. If I get really bored, maybe I'll do them for you.
|
|
| |
|
|
|
Ned
|
|
of Aptos, CA
Oct 1999
time: 21:13
|
|
Fitz, Yes. I created size one bases from start using the SE, adding pods and just pressing B. As bases were founded, typically, but not always, the new base beyond the limit would have a drone; and zero, one, or two additional drones would randomly appear elsewhere, even in the home base.
Give those same bases to a different faction, the drones disappear. Switching to that faction changes nothing. The base still has no drones. (I did this to test whether there was a difference between whether the AI or a human owned the base in question.)
I tried coming up with a formula to explain the pattern, but gave up in favor of a random number generator that would average two extra drones. Ned
|
|
| |
|
|
|
Ned
|
|
of Aptos, CA
Oct 1999
time: 21:13
|
|
I would just like to update this thread with recent data from a current game. The map was larger, so Transcend B/W was 12 at zero efficiency.
I had founded 24 bases and had captured 42. Each base, at zero efficiency, had at least 3 B drones. As well, it appeared that each captured base had two additional "captured-base" drones.
This data is highly consistent with the SE data. It indicates that on the average, one gets two B drones per base over the b/w. These b-drones also spread evenly, that is, if a base has a b-drone, it will not get another one until all other bases get one too. Etc., for the second b-drone.
I was also very surprised by the two, not one, extra drones in captured bases. This is also not consistent with the Datalinks.
Ned
|
|
| |
|
|
|
Ned
|
|
of Aptos, CA
Oct 1999
time: 21:13
|
|
WE, et al., You may want to clip the following an paste it on the wall. The drone pattern is highly repeateable. The following is the pattern for a standard planet.
What apparently is happening is that as you reach the end of the first b/w, all bases have one b-drone. At the end of the second, all have two. At the end of the third, three. And so on.
Here is the data:
code:
Transcend, Standard, 0 Efficiency. B/W after 6 bases.
Bases start with two content workers, third is a drone
Bases Drones Location
0-6 0 0
7 1 2
8 3 2, 7-8
9 4 2, 6-8
10 5 2, 5-8
11 8 2, 4-8, 10-11
12 12 1-12
13 15 1-13, 2, 8
14 19 1-14, 2. 7-8. 14-15
15 22 1-15, 2, 6-8, 12-14
16 25 1-16, 2. 5-8, 11-14
17 30 1-17, 2, 4-8, 10-14, 16-17
18 36 1-18 (2)
19 41 1-19(2), 2, 8, 14
20 47 1-20(2), 2, 7-8, 13-14, 19-20
21 52 1-21(2), 2, 6-8, 12-14, 18-20
22 57 1-22(2), 2, 5-8, 11-14, 17-20
23 64 1-23(2), 2, 4-8, 10-14, 16-20, 22-23
24 72 1-24(3)
|
|
| |
|
|
|
Basil
|
 |
Vancouver, B.C., Canada
Apr 2000
time: 21:13
|
|
My understanding of how drones in captured bases work (and this is only something I read somewhere, not something I've tested, so take it with a pinch of salt) is this: it depends on the difficulty rating of the game and the number of years since the base was captured.
- At most 5 - ceiling(years_since_capture/10) citizens are drones
- At most 7-difficulty_setting citizens are drones (difficulty_setting = 6 for transcend, 5 for thinker, etc.)
So at Transcend you get one extra drone until 50 years are up. However, at Citizen you get 5 extra drones for the first 9 years, 4 extra drones for years 10-19, etc. At Thinker you would get 2 extra drones for the first 39 years then 1 extra drone for years 40-49.
Like I said, this is just something I read somewhere I can't find now, so feel free to shoot it down  !
|
|
| |
|
|
|
Ned
|
|
of Aptos, CA
Oct 1999
time: 21:13
|
|
Basil, Interesting that the captured-base drone problem would be more severe the easier the game!
However, the table I posted pertains only to bureaucracy drones, b-drones for short. I stopped the test after the third bureaucracy warning, so I have no I idea whether there is a cap at some point.
As I mentioned in an earlier post, it seems, and I want to double-check this, that your b-drones are not reduced in your remaining bases if you give a captured base away. This factor really complicates you life if you are capturing bases and giving them to a submissive with the partial intention of minimizing your b-drone problem so that, for example, your main bases can stay in GA.
Assume that you do not want to go over the third b/w - which apparently gives 3 b-drones per base. If you religiously give bases away as you capture them and approach the warning, you could theorectically do this and minimize your GA problems. But, as I said, it seems that the computer still counts bases given away as your bases regardless, so this is not possible.
As I said, I will double-check this.
|
|
| |
|
|
|
johndmuller
|
 |
Capitol Hill, Colony of DC
Feb 2001
time: 00:13
|
|
quote:
Originally posted by Ned
What apparently is happening is that as you reach the end of the first b/w, all bases have one b-drone. At the end of the second, all have two. At the end of the third, three. And so on. |
Ned, this sounds like an elegant and perfectly logical approach to your b-drones , for each (complete) level of the b-warnings, you get another drone in each of your bases. Even if it turns out not to be the way they do it, it should have been the way they did it. It is reasonably simple to calculate, and it maintains the handicapping over the various skill levels and efficiency ratings and whatever else the b-warnings key off of. The bunching effect probably is another artifact of the integer arithmatic or some such thing.
It looks like you are saying that the particular affected bases are also predictable - I gather by base age. (It would have been a nicer trouch, IMhO, to make the distribution random, though.) Does this mean that a captured base would reshuffle the b-drones insofar as the captured base's age appeared in the middle of the existing bases' age spectrum?
Basil, I can see why you distanced yourself from those formulas, the reverse handicap for max drones does look a little counter-intuitive.
The formulas would make more sense to me if the second line (7-diff) fed into the first as in:
#c-drones = 5 - ((7 - Diff) * (years_since_capture/10))
I have no idea whether or not this is true, but it is a reasonable interpretation of those equations and it looks like the handicapping would be consistent with usual practice.
|
|
| |
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
top of page
|
| archivepost |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
18-12-2000 02:30
) so I'll put the full and correct info into that.
but despite being an A maths student I find it *bloody irritating* to have to do this kind of stuff just to work out how many bases I can place given different map sizes, eff ratings and the rest of it (for goodness sake!!).
|