Nomads and NONE settlers

[solo]

It is possible that whenever huts are tipped, the program keeps track of the last series of results, storing this information even when the game is saved. Then for the following huts, the most recent results are given more weight than they usually get in the table of possible outcomes. Due to the random factor and because more individual weight just shifts the odds a bit, more weight does not necessarily mean a selection of the favored item every tip, but could result in more bunches of similar results than might be expected due to chance alone.

Another possibility, which is my personal guess, is that after a certain amount of time has elapsed (say, perhaps 2 or 3 minutes), the weights given to the possible hut outcomes are altered before making the final selection in a random way. Under such a system, techs, for example, may be given a substantial weight in their favor for awhile, causing them to appear in bunches. After a few minutes the weights are altered again and another kind of hut result is favored. Interspersed may be periods where none of the possible results are favored.

Both explanations above could explain why this phenomena occurs whether or not reloads are used in between tips.

[ramses II.]

I play the original Civ II with pacth 2.4.2, map 125x80, deity, raging, other parameters medium.
Maybe this phenomenon depends on the civ version.
I often get a nomad or an advanced tribe before founding my 3rd city. I've never found one before founding my 2nd city (that means, I never found a nomad in OCC-games).

[DrFell]

Originally posted by Scouse Gits


Agreed! Though about a week ago I recorded a first! A nomad from a Plains tile! (2.42 Standard Large Map)

I've seen this too, in MP. Nomads from both grassland and plains. It's very rare indeed, but does happen. I've also seen the capital-from-hut happen at least three times, it pops up with it's own palace. It must be said though, that I've played hundreds of 2x2x duels and these events are very rare.

[rah]

Originally posted by solo
It is possible that whenever huts are tipped, the program keeps track of the last series of results, storing this information even when the game is saved. Then for the following huts, the most recent results are given more weight than they usually get in the table of possible outcomes. Due to the random factor and because more individual weight just shifts the odds a bit, more weight does not necessarily mean a selection of the favored item every tip, but could result in more bunches of similar results than might be expected due to chance alone.

Another possibility, which is my personal guess, is that after a certain amount of time has elapsed (say, perhaps 2 or 3 minutes), the weights given to the possible hut outcomes are altered before making the final selection in a random way. Under such a system, techs, for example, may be given a substantial weight in their favor for awhile, causing them to appear in bunches. After a few minutes the weights are altered again and another kind of hut result is favored. Interspersed may be periods where none of the possible results are favored.

Both explanations above could explain why this phenomena occurs whether or not reloads are used in between tips.

I highly doubt either one of these is the case for a few reasons.

1. As a programmer for over 30 years, you don't overcomplicate something. There's no need to do it. And what we discovered in the rest of the games, Revolution years, barbs, techs offered, were pretty straight forward in design. Even the supply and demand is falling into a pattern, (with a few flukes that could be bugs, or just unanticipated results from the code.

2. The game was designed when PCs didn't have a lot of memory or hard drive space. The older programmers learned to program quite effeciently in terms of memory use. Holding previous results would be a hog. Much simpler to pick a random number and consult a chart that is simply modified by game events or year in the game. How the rest of the game is designed seems to support this.

3. When I started playing originally, I did reload quite a bit before I learned the game. It never took many resets to get the desired results (unless you wanted a specific tech out of many available) Patterns can happen when you use a mathmatical algorithm to generate random numbers. I'm sure what you've experienced is well within the range of probability.
In Vegas, black sometimes comes up 10 times in a row.


RAH

And Dr. Fell. AHHHHH a player I can trust when he says the cap thing happened to him (nice to hear it was extremely rare)

1. Were you guys playing with a modded text file?
2. Was it happening before 2500 b.c. ?(or were you wandering hut gathering.)
3. Is it possible another civ (human or AI) had dropped both or one city and had triggered a city from a hut already?
4. Was it deity? (since 99% of my games are deity and that might have an impact) Two settlers or one each or a combo.

[Scouse Gits]

Another random empirical observation ...

I am convinced that the game save has a time flag in it.
The reason: when a bad combat result happens and you try the reload and try again trick - the result if anything seems to get worse! I feel that the programmers used this trick to try and circumvent reloading as a tactic and some time (I have no idea, but I would guess about 5 mins) is needed before a reload will have a 'true' outcome -- does this apply to huts?

SG[1]

[DrFell]

Originally posted by rah
1. Were you guys playing with a modded text file?
2. Was it happening before 2500 b.c. ?(or were you wandering hut gathering.)
3. Is it possible another civ (human or AI) had dropped both or one city and had triggered a city from a hut already?
4. Was it deity? (since 99% of my games are deity and that might have an impact) Two settlers or one each or a combo.

Standard rules, king 2x2x on a small map on all occasions, very early in the game (the first few turns, before 3500BC). Almost certain I had one settler too, we usually disband if we get 2 on king. Not sure if the other player had already got a hut city/settler yet, but I'm pretty sure they already got their city down.

IIRC, it happens sometimes when you get a unit from a hut, then send out the unit and tip another hut before moving the settlers (I always do this, to try and get more hut units before founding first city). Of course this happens much more often on double moves, especially on a river system. Was nice to get a city so early on, but the location sucked for a capital.

[solo]

ramses,

I have had an advanced tribe before founding my second city, but come to think of it, do not ever recall getting a nomad in the many OCC games that I have played.

rah,

Sure, I am aware that streaks are common, but after tipping enough huts in a row for 1000 tech results, the bunches were coming in such a predictable and periodic way, I began to suspect more than just pure chance was at work here. There are seemed to be bunches of units or gold results interspersed with the ones favoring techs, too. I suggest you try a test, and judge for yourself whether hut results are just following the rules of probability.

Though I only programmed for 15 years, I am aware that not much memory is required to store a value representing a certain time, though I do agree with you that storing a series of previous hut results would be quite inefficient, and must agree that idea was a bit far-fetched. I now regret suggesting it as a serious possibility.

Another way of blocking off a series of hut results so that they favor one item or another, would be to keep a simple counter starting with a value such as 16, 10, 8 or whatever number is wanted for "similarly weighted" results, and decrementing this counter each time aother hut is tipped. When the counter reaches zero, the table of probablities is recalculated again. Such a system would be quite simple and consistent with the other countdown cycles found in the game, such as "oedo years" or 16 turn cycle events.

All I am meaning to point out with this example and the previous two, is that there are ways to purposely implement this phenomena, while attaining enough randomness to make individual hut results impossible to predict.

[rah]

I want some of what you're smoking
From the old days of reloading, if I lost one, i.e. battleship vs warrior, it never took more than one or two reloads to get the more realistic result. I could do (consevatively) 15 reloads a minutes. It Never took more than 5 or six to change the outcome of normal battles. Granted if I was attacking the battleship with that warrior, it would take a few minutes. But that's to be expected probablility wise.

Just think about the extra effort you're attributing to the programmer just to pimp someone. Not realistic. Look at CIVIII where they were intentionally trying to pimp the user. All they did was save the initial seed. A very simple and easy to program thing. Which was only done after people bragging for YEARS about reloading.

Rich
Just can't buy it.

RAH

[atawa]

Originally posted by DrFell


I've seen this too, in MP. Nomads from both grassland and plains. It's very rare indeed, but does happen. I've also seen the capital-from-hut happen at least three times, it pops up with it's own palace. It must be said though, that I've played hundreds of 2x2x duels and these events are very rare.

It happened to me 3 or 4 times too, all games were with normal MGE rules.txt and in each case other players had allready build their cap.

[samson]

I have had an advanced tribe before founding my second city, but come to think of it, do not ever recall getting a nomad in the many OCC games that I have played.

I have. I regularly use my second settler to increase the pop of my OCC city from 2 to 3, and then tip some hill and forest huts to get a nomad for terrain improvements.

[rah]

Originally posted by solo
Another way of blocking off a series of hut results so that they favor one item or another, would be to keep a simple counter starting with a value such as 16, 10, 8 or whatever number is wanted for "similarly weighted" results, and decrementing this counter each time aother hut is tipped. When the counter reaches zero, the table of probablities is recalculated again. Such a system would be quite simple and consistent with the other countdown cycles found in the game, such as "oedo years" or 16 turn cycle events.

Glad to hear you're an experienced prog too. It always makes these conversations simpler. Oedo year is tagged against something that is already stored (the game year) so nothing new need be created. I doubt they would create and additional field just for the hut counter. But on the same note, as you point out, I can't discount that they used an existing field as a modifier. If it does exist it would be nice to know what it is.

And to your other point. Depending on the algorithm used for creating random numbers, some are more likely to produce patterns when used repeatedly. But I assume you were reloading for your tests and the initial seed number had something to do with it.

Atawa and Fell. I rarely play 2x movement and at lower levels, so I wonder if that's the difference.

When using 2x production or 2x movement certain things are introduced into the game that the original programers may not have programmed for.
(like instant fortifying in 2x production) and a few others.

But, 4 years later, we still have questions

RAH

[rah]

One Last note.
Everything that I have written in this thread is SPECULATION. And will more than likely be proved wrong in the future. But lacking verified truth. (like looking at the code) I've tried to base my assumptions on my experiences, so I hope no one takes offense. That is not my goal.

[solo]

No offense at all, here, rah. Just sharing my own theories based from my own experiences, too.

Funny how this thread ended up generated so much interest and activity when there was nothing to discuss!

samson, I've almost always held onto my second OCC settler to begin roads, etc., right away. Having one NON settler around explains not getting others in my OCC games.

[Straybow]

"…in each case other players had allready build their cap." It would not be surprising that MP would have rules for specific situations unique to MP games. As you said, having a hut become you capital is a mixed blessing because the location usually sucks.

"I regularly use my second settler to increase the pop of my OCC city from 2 to 3, and then tip some hill and forest huts to get a nomad for terrain improvements." I think somebody else mentioned that in the Paul's Deity OCC Competitions, after a kick-ass early date achieved by using the 2nd Settler to grow and finding a Nomad later.

Thing is, it only seems to apply to that original "spare" Settler. If I get an Adv Tribe in a rotten location (too far from me, too close to hostiles) I usually disband it into a NON Settler, and then use my "spare" to found a city. The only early Nomads I can recall, from my home continent, were following that situation.

Does anybody else ever make NON Settlers/Engrs by building a city near an opponent and rushing to disband? I do it regularly in SP after Engrs appear because I rarely race for Leo.

[rah]

I've done it in SP but can't ever remember doing it in MP. I have disbanded a conquered city or a city from a hut to make a settler to move the city or just disband it, but not with the express purpose of just making a non-unit.